[ROLE PARITY] Determine which of these elements with existing ARIA role mappings require a new role

[joanmarie]

N.B. All of the "Role Parity" issues are intended to gather feedback from stakeholders who need role parity from us including, but not limited to, groups working on Web Components and AOM. Comments on matters other than determining "which of these elements with existing ARIA role mappings require a new role" should be raised in another GitHub issue. Thank you for your understanding!

The following elements are already mapped in the HTML AAM to an ARIA role. In addition, the HTML AAM platform mapping for all platforms is "Use WAI-ARIA mapping." HOWEVER, unlike the elements listed in #694, there is not a unique correspondence between the element and the ARIA role. For instance, both dfn and dt map to the ARIA term role.

Assumption: Some of these elements may need a dedicated role; others may not. For instance, what makes it clear that an ol is a list which is ordered is the presence of the indexed children. Thus those elements might already have sufficient "parity."

We need to determine which of the items below belong in the group of elements in #694, which do not need a new role but might benefit from a new attribute (e.g. the type of button to distinguish submit from reset), and which definitely need a new role.

• a (represents a hyperlink): link - OK
• a (represents a hyperlink and parent is a menu): menuitem - Patches welcome
• area (represents a hyperlink): link - OK
• body: document (has issue) - no parity will be attempted
• datalist (represents pre-defined options for input element): listbox - OK
• dd: definition - OK
• dfn: term - generic inline with TBD attribute
• dt: term - no new role, but if in definition list role will support aria-posinset and aria-setsize
• img (empty alt value): none (A.K.A. presentation) - OK
• input (type=button, parent is menu): menuitem Patches welcome
• input (type=checkboxstate, parent is menu): menuitemcheckbox - Patches welcome
• input (type=email, no suggestions source element): textbox - OK, but TBD attribute
• input (type=email,search,telephone,text,url, suggestion source element): combobox - OK, but TBD attribute
• input (type=image): button - OK
• input (type=image, parent is menu): menuitem Patches welcome
• input (type=radio, parent is menu) : menuitemradio - Patches welcome
• input (type=reset): button - OK
• input (type=submit): button - OK
• input (type=telephone, no suggestions source element): textbox - OK, but TBD attribute
• input (type=text, no suggestions source element): textbox - OK, but TBD attribute
• input (type=url, no suggestions source element): textbox - OK, but TBD attribute
• keygen: listbox - OK (keygen is deprecated)
• ol: list - single role, but TBD attribute
• optgroup: group - OK
• section (with accessible name): region - OK
• select (with multiple attribute or size > 1): listbox
• select (no multiple attribute, size <= 1): combobox - change HTML-AAM mapping to listbox with aria-expanded set to false (needs to be added to listbox) and add aria-valuetext as a supported property of listbox
• tbody: rowgroup
• textarea: textbox, with mapping for aria-multiline=true
• thead: rowgroup - OK, but possibly attribute
• tfoot: rowgroup - OK, but possibly attribute
• ul: list - single role, but TBD attribute - OK, but possibly attribute

[cookiecrook]

FWIW, it's good to reference the presentation role as the newer synonym none wherever possible for clarity. I made one minor edit to your issue summary above.

[domenic]

For web components purposes, what we are interested in is being able to create custom elements which present themselves to AT in the same way as these native elements. So for our purposes, the question is, e.g.: do ATs expose the difference between dfn and dt?

If they do, then we also need a way to do so in web components (whether it be a new attribute or new role).

If they do not distinguish, then we do not need any new roles or attributes.

Similarly, e.g. do ATs announce "ordered list" vs. "unordered list" or similar? If so, we need to be able to induce that behavior for <custom-ordered-list> and <custom-unordered-list> web components. But if they just announce "list", then the existing list role seems fine.

I'm unclear from the OP's summary which is the case, and am hopeful that those with domain expertise can weigh in to clarify.

[cookiecrook]

For web components purposes, what we are interested in is being able to create custom elements which present themselves to AT in the same way as these native elements.

Have you considered how you'd you make a custom element be operable like the HTML <video> element? In other words, could a custom element opt into exposing APIs like play(), pause(), etc?

[domenic]

That seems unrelated to this thread, perhaps best filed on the web components repo? But yes, my understanding is that AOM was meant to help with that.

[joanmarie]

@domenic: A given AT can do whatever it sees fit, of course. Something I'll come back to momentarily. But to hopefully clarify things regarding questions like:

So for our purposes, the question is, e.g.: do ATs expose the difference between dfn and dt?

And:

Similarly, e.g. do ATs announce "ordered list" vs. "unordered list" or similar?

TL;DR: Maybe.

Long version:

If you look at the mappings in the HTML AAM (for which links have just been added above), you'll notice that the mappings are almost entirely "Use WAI-ARIA mapping." That means see what the Core AAM says by following the link on the right. In the case of dfn and dt, each of which map to term, you'll find in the Core AAM:

MSAA + IAccessible2	Role: IA2_ROLE_TEXT_FRAME Object Attribute: xml-roles:term
UIA	Control Type: Text Localized Control Type: term
ATK/AT-SPI	Role: ROLE_DESCRIPTION_TERM
AX API	AXRole: AXGroup AXSubrole: AXTerm AXRoleDescription: 'term'

What the Core AAM mappings are is what user agents expose to assistive technologies via platform accessibility APIs for ARIA roles. As you will see in the table above, there is nothing in the stated mapping that lets an AT determine (and present to the AT user) whether the element is a dfn or dt. You'll find the same scenario for ol and ul with list.

That said, there might be ways for ATs to still make that distinction. For instance, Gecko exposes the tag via ATK and IAccessible2. So an AT on those platforms could present a distinction should their developers be so motivated. My guess is that all platforms and user agents have little things like that.... And, yes, of course that leads to inconsistent user experiences.... That's another matter.

Getting back to your questions, I suspect my answer is more information than you were really wanting... 🤷‍♀️ BUT, your answers suggest to me what the next step is, namely for the ARIA Working Group to get input from the AT developers regarding where they want/need the ability to distinguish elements. See for instance what I said here regarding sub and sup.

Thanks again very much for helping us understand what you need -- and for helping us see what else we need to do. 😄

[joanmarie]

Please note that the three deleted comments were copied and pasted in their entirety in w3c/aria-practices#575.

[annevk]

And, yes, of course that leads to inconsistent user experiences.... That's another matter.

Flushing that out more would be good though. E.g., is tag (sic) something everyone should expose or is it something that perhaps should go away? If it's important, is it okay for custom elements to "spoof" the value or does it need to be the custom element name, even if that leads to a different experience than intended?

[joanmarie]

This is a meta issue. The 1.3 TODO's can be found on https://github.com/w3c/aria/wiki/Plans-regarding-role-parity