Question should aria-roledescription be prohibited on additional roles?

[scottaohara]

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?

[stes-acc]

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]

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]

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]

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 like note. Unbeknownst to them, they'd break heading navigation in the process.

[JAWS-test]

@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:

• The specification prohibits the use of aria-roledescription on these elements or
• The specification specifies that even for roles that do not cause AT to output the role, aria-roledescription causes the role to be output.

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]

@JAWS-test wrote:

The specification specifies that even for roles that do not cause AT to output the role, aria-roledescription causes the role to be output.

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]

@JAWS-test wrote:

The specification specifies that even for roles that do not cause AT to output the role, aria-roledescription causes the role to be output.

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.

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]

Thanks all and @cookiecrook. I definitely was more concerned about the idea of authors using aria-roledescription on 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"

[JAWS-test]

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]

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