[ROLE PARITY] Determine if any of these mostly unmapped elements require a specific 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 "if any of these mostly unmapped elements require a specific role" should be raised in another GitHub issue. Thank you for your understanding!

The following elements are not mapped to an ARIA role. And they have a mapping on some or all platforms of "no accessible object" (i.e. the information is exposed in a fashion other than a role) or "not mapped". In cases where a platform does map them, the mapping is generic.

Assumption: If one or more platforms maps these elements to a role, an ARIA role is probably in order. Also, if for some reason an author made these focusable, they would need an accessible object. But in both instances, the to-be-created generic role(s) should suffice.

We need to determine if any of these roles require we create a specific role.

• area (no href) - map to img and update HTML-AAM
• b - generic inline with TBD attribute (when exposed)
• bdi - generic inline with TBD attribute (when exposed)
• bdo - generic inline with TBD attribute (when exposed)
• cite - specific role (similar to address)
• code - specific role
• colgroup - investigate if it really should be mapped at all in HTML-AAM (Melanie will investigate; user agents are not exposing it for MSAA)
• del - specific role
• em generic inline with TBD attribute (when exposed)
• i generic inline with TBD attribute (when exposed)
• ins - specific role
• kbd generic inline with TBD attribute (when exposed)
• map (when not used as an image map) - not mapped, file bug against HTML-AAM
• rp (more discussion, check with i18n)
• rt (more discussion, check with i18n)
• s generic inline with TBD attribute (when exposed)
• samp - generic inline with TBD attribute (when exposed)
• small - generic inline with TBD attribute (when exposed)
• span generic inline (when exposed)
• strong generic inline with TBD attribute (when exposed)
• sub - specific (but remember discussion about attribute -> role at API level)
• sup - specific (but remember discussion about attribute -> role at API level)
• u generic inline with TBD attribute (when exposed)
• var generic inline with TBD attribute (when exposed)
• wbr - tentatively not mapped, check with HTML-AAM and Apple about why it's mapped

If you agree with the above, please explicitly indicate so (e.g. with a +1/thumbs-up "reaction"). If you disagree, please comment with the element(s) for which you feel a new, non-generic role is needed. Thanks!

[domenic]

Where can I learn more about this generic role, or the way in which "in cases where a platform does map them, the mapping is generic"?

[joanmarie]

@domenic, regarding this:

Where can I learn more about this generic role, or the way in which "in cases where a platform does map them, the mapping is generic"?

Good question. Apologies that you had to ask it. I have just edited the opening report with links to the current mappings in the HTML-AAM. (I'll add doing so for the other issues to my TODO list.)

To save you some clicking, the sorts of things you'll find are:

• If it's exposed in macOS, odds are the role is AXGroup with no subrole and an AXRoleDescription of "group"
• Exposure in ATK and/or IAccessible2 are often to a generic role (e.g. ATK_ROLE_STATIC and IA2_ROLE_TEXT_FRAME respectively). Or there is not a dedicated accessible for the object; instead the text is folded into the parent accessible object and associated formatting is accessed through the accessible text interface for that parent object.
• Exposure in UIA is similar

In other words, for the most part, it doesn't matter which of those elements in the opening report you use, it's going to be exposed on each platform as formatted text.

That said: It's worth keeping in mind that these HTML AAM mappings are not final. For instance, in answering your question, I noticed and filed w3c/html-aam#121.

HTH. Thank you for the question as well as for your feedback here and on the other issues. Please let us know if we can help clarify anything else.

[domenic]

Thanks, I think I get it now. From perusing those tables, it seems like there's at least a couple generic roles that would canvas this space:

• A role indicating no accessible object: useful for cases like del, em, etc. MSAA/IA2/UIA/ATK: no accessible object; AX: AXGroup
• A role indicating text: useful for cases like abbr ([ROLE PARITY] Determine which of these mapped elements require a specific role, versus a generic role #697), a-with-no-href. MSAA/IA2: ROLE_SYSTEM_TEXT/IA2_ROLE_TEXT_FRAME; UIA: Text; ATK: ATK_ROLE_STATIC; AX: AXGroup

This said, I'm basing these two categories on just pattern-matching over the available mappings. I'm not sure why, e.g., it's a good idea to map abbr in a different way from del. If that difference is an important one, then it'd be great to have guidance for authors on when to use which pattern, for when they create their own web components.

Another interesting case is how span doesn't fit into either of the above two generic roles. Is it a third category? Is it important to allow the creation of web components that behave like span, in addition to ones that behave like abbr, and ones that behave like del?

Oh, and one more question that would be helpful: what mappings exist today for elements like <asdf> or <custom-foo>? I'd always assumed they were mapped like <span>, but I realized I never asked anyone explicitly.

[aleventhal]

We might want to put ins/del back on the list.
It's a role in IA2 and a Subrole on Mac. It already has implementation in NVDA and JAWS.
IA2: https://github.com/LinuxA11y/IAccessible2/blob/master/api/AccessibleRole.idl#L307
Mac: AXInsertStyleGroup and AXDeleteStyleGroup

[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