Identify elements which support aria-roledescription without an explicit or implicit role

[joanmarie]

As described in w3c/aria#500, there is a need to prohibit the exposure of the value of aria-roledescription for certain HTML elements (e.g. div and span) when there is no explicit or implicit ARIA role. Alternatively, or in addition, this AAM could explicitly allow the exposure of the value of aria-roledescription on certain elements (an example from HTML would be meter used without an explicit role).

The purpose/motivation behind this request is that we want to strongly discourage authors from using aria-roledescription on elements which lack useful semantic meaning, and we want to strongly encourage (and perhaps insist) that user agents do not expose the value of aria-roledescription when it is used on an element which lacks useful semantic meaning and also lacks an implicit or explicit ARIA role. But there's no way we can come up with a host-language-agnostic, universally-agreed-upon definition of "useful semantic meaning" or "generic element." If such elements are explicitly identified in the host-language-specific AAMs, we (ARIA spec and/or Core AAM) should be able to point authors and user agents to those specs to get the implementation and user experience desired and intended for aria-roledescription.

Note: As @stevefaulkner suggested, I opened w3c/html-aria#77. But the HTML AAM already has a per-element mapping table with comments, so perhaps this information could be added there?? (Asking is, they say, free. 😉)

[stevefaulkner]

hey @joanmarie,

I have added the following to the spec via af1ba37 let me know if it does the job?

In the case where an element has the term "No corresponding role" listed in the WAI-ARIA column of the table, user agents must not expose the aria-role-description property value in the in the accessibility tree unless the element has an explicit conforming role attribute value.

[stevefaulkner]

ping @joanmarie

[joanmarie]

@stevefaulkner thanks for the ping. And thanks for making the change. I'm on vacation (post ARIA 1.1 and friends). But will try to take a look this week to very it indeed does the job.

[jasonkiss]

@joanmarie Thanks. Can you confirm that you're happy with this text?

[joanmarie]

Sorry and thanks for the re-ping.

I'm happy with the text for the main problem (i.e. generic elements). However, it doesn't solve the problem of things like meter. If that is going to be addressed in w3c/html-aria#77, great. But then I think we'll want to reference that to-be-written text here, e.g.

user agents MUST NOT expose the aria-roledescription property value in the accessibility tree unless the element has an explicit, conforming role attribute value or is identified in ARIA in HTML as supporting aria-roledescription without an explicit or implicit role value.

(emphasis added for hypothetical text)

The problem is that the text in the HTML AAM might make authors think they should do the following:

<meter role="group" aria-roledescription="my nifty meter">

Doing the above, of course, is NOT something we want authors to do because it changes the mapping exposed (ATK_ROLE_PANEL instead of ATK_ROLE_LEVEL_BAR). It also might cause the platform's value-related accessibility API to not be implemented (a group isn't a value-related role). And if the platform's value-related accessibility API is still implemented, ATs might not check (because the platform role isn't a value-related role).

Make sense?

Lastly, since we plan to tackle element-role parity in ARIA 1.2, the "meter problem" should go away eventually. Not sure what impact that has on plans for HTML AAM or ARIA in HTML.

[asurkov]

Sorry for arriving to the party late, but what's the point of forcing the browser to ignore aria-description? All enforcing goes at cost, and the browser probably shouldn't attempt to fix author errors.

I think it's reasonable to not create an accessible object for no semantics element having aria-roledescription attribute, but same time I would avoid filtering aria-roledescription attribute on accessible elements.

Would you please give me some backgrounds of such spec wording?

[stes-acc]

Another aspect: the aria-roledescription="" case. Which should be handled in the API mappings spec if declared but empty will have effect in browser mapping (which shouldn't). And obviously not for screen readers.
Don't laugh, we have seen alt="" declarations for images that are interpreted as "decorative" by AT. Way bad.

[scottaohara]

since this issue was filed, and since steve's initial spec change - the text now reads:

Where an element is indicated as having "No corresponding (WAI-ARIA) role", or is mapped to the generic role, user agents MUST NOT expose the aria-roledescription property value in the accessibility tree unless the element has an explicit, conforming role attribute value which [WAI-ARIA-1.2] does not prohibit the use of aria-roledescription.

I think this particular issue can be closed, and further clarity on author guidance/requirements can be made over in aria in html (with the companion issue to this that already exists over there)