Repository navigation
Question should aria-roledescription be prohibited on additional roles? #1651
Description
Should we be more prescriptive of what roles should be marked as being prohibited from using aria-roledescription? generic is the only role that presently prohibits this (note: would have also expected this on none/presentation - but actually i kinda expect all global attributes to be prohibited on those roles since they undo the role... but i digress).
For instance, role=paragraph or the <p> element. While it has an implicit / explicit ARIA role, what would the expectation here be? That screen readers, which generally don't announce a role like this, instead start announcing this modified role 'description'?
Upon a quick test, <p aria-roledescription="oh no">hi there</p> NVDA actually does announce "oh no" when i navigate to the paragraph. But is that a good idea? JAWS and Narrator don't do this when navigating by paragraph... people don't generally expect a "paragraph" role to be announced.
Thoughts?
Activity
stes-acc commentedon Nov 25, 2021
It is true that currently different screen readers handle verbosity of aria-roledescription differently. NVDA seems to anounce the roledescription always instead of base role whereas Jaws seems to have different per-role based heuristicts.
For instance, a link with roledescription is anounced in NVDA with the roledescription and not any more as link.
In JAWS it is still announced as a link but the roledescription is mapped on the braille display as additional string. Not so for some other "weaker" control roles, here the role description string also "wins" in speech output.
In both screen readers the link is still visible in the link lists.
In my opinion, there seems to be a need to clarify more what should be done all accross screen readers.
pkra commentedon Nov 25, 2021
Personally, I know only very few use cases where aria-roleDescription is truly useful for users (mostly, in educational settings). Anecdotally, I suspect many developers are not aware that they might "overwrite" something and they are actually looking for a way to add information, e.g., hint. Restricting aria-roleDescription sounds good to me but perhaps there's a separate use case for adding complementary information (see also my comment at #1643 (comment)).
cookiecrook commentedon Nov 30, 2021
I would argue against limiting it. It's a tool. Sometimes people misuse tools to their peril… or benefit.
If we over-specify when a tool should not work, authors will just work around it, presumably by using the wrong role on some element. Better to only add limits once there is a well-established anti-pattern that is causing Web-wide breakage.
cookiecrook commentedon Nov 30, 2021
As a contrived example, if we specified you could not use it on
heading, and an author wanted a "super heading" (for better or worse), they'd try using some other role likenote. Unbeknownst to them, they'd break heading navigation in the process.JAWS-test commentedon Nov 30, 2021
@cookiecrook
I agree with you that not every possible abuse should be countered by severely restricting the use of ARIA attributes. However, @scottaohara's request refers to a specific case, namely that a semantic element (
<p>) is usually output by assistive technology without a role. Now what should happen if this element has a roledescription? I think there are two possibilities:I would be in favor of the second option, and would report a bug for AT that do not do this so far (like JAWS).
cookiecrook commentedon Nov 30, 2021
@JAWS-test wrote:
At low verbosity, most role descriptions (custom or otherwise) should not be spoken at all. I don’t think an author specifying a role description should override the AT user’s verbosity settings.
I’d suggest a 3rd possibility. The spec can have a note that indicates AT may or may not convey the role description due to defaults, user settings, or other factors.
IMO, no restriction is needed on paragraph, list items, etc.
stes-acc commentedon Nov 30, 2021
I would also agree that all AT should treat roledescription as part of their verbosity settings, if technically possible on a per-site approach (since some sites may rely on them for more clarity and others don't).
scottaohara commentedon Nov 30, 2021
Thanks all and @cookiecrook. I definitely was more concerned about the idea of authors using
aria-roledescriptionon paragraphs, or other text-semantic elements that are not generic. Since those roles would generally not be announced, I like the idea of, if not saying "don't use this here", a note indicating "this is allowed, but may not actually expose any meaningful info and/or could add unwanted noise to your otherwise straightforward content"add note to aria-roledescription
JAWS-test commentedon Mar 25, 2022
Regardless of the discussion here, aria-roledescription should not be allowed on presentation/none, because it makes no sense for an element to have no role but roledescription.
scottaohara commentedon Mar 25, 2022
arguably all inherited states and properties should be marked as prohibited on a role=none|presentation element since they all result in an instance where the browser has to ignore the role and expose the implicit or fallback one instead.
but that's a different issue to file
add note to aria-roledescription (#1666)
add note to aria-roledescription (#1666)
add note to aria-roledescription (#1666)