Help locating some features of the accessibility mapping

[domenic]

Hi all,

I'm working with @alice and @tkent-google on allowing custom elements to specify their own default roles/states/properties. We think we have a rough plan, but need help in one regard. I will use role as the example, but the same reasoning should hold for states/properties, I think.

Right now, to our understanding, implementation behavior for an element's role is:

1. If the role="" attribute is set, use that, then map to native platforms using https://w3c.github.io/core-aam/.
2. Otherwise, map to native platforms using https://w3c.github.io/html-aam/#html-element-role-mappings

(side note: I can't find how to apply step 2 for custom elements; that is, I wasn't able to find a part of HTML-AAM that states how unknown tags map.)

We want to modify this to be something like:

1. If the role="" attribute is set, use that, then map to native platforms using https://w3c.github.io/core-aam/.
2. If the element is a custom element, and the custom element author has set a default ARIA role, then use that, mapping to native platforms using core-aam.
3. Otherwise, map to native platforms using https://w3c.github.io/html-aam/#html-element-role-mappings

However, I can't find where this 2-step algorithm might be defined today in specifications, so that we can properly insert this new step in the middle. Could folks help use locate that?

Thanks!

[carmacleod]

I'm not completely sure if this answers your question, but HTML-AAM section 4.3 Exposing HTML Features That Do Not Directly Map to Accessibility APIs might be what you are looking for. It says:

When HTML roles, states and properties do not directly map to an accessibility API, and there is a method in the API to expose a text string, user agents MUST expose the undefined role, states and properties via that method.

There are examples of this (I think?) in 4.3.1:

For example, Firefox returns the element's tag name as a BSTR for the following: abbr, address, aside, blockquote, canvas, caption, dd, div, figcaption, footer, form, h1–h6, header, iframe, input type="file", main, menu, nav, output, p, pre, q, section, time.

Similarly, Chrome returns the element's tag name for: blockquote, div, dl, figcaption, form, h1-h6, menu, meter, p, pre.

The current ARIA 1.2 role parity work may reduce the need for some of those.

So, I have a question. Why would a custom element author assign a default role instead of just setting the role? For example, a <custom-listbox> really ought to have role="listbox". A <custom-thing> should have the closest possible ARIA role assigned, not as a default, but as its actual role. Maybe I am missing something here.

[domenic]

I'm not completely sure if this answers your question,

Hmm, this doesn't seem to help that much, sadly. For example, I'm looking for what text normatively requires that <select role="button"> be exposed to UIA as Button, whereas <select> be exposed to UIA as Combobox.

So, I have a question.

Let's open a separate issue to discuss this, so this one can stay focused on finding out how UAs are required to implement accessibility mappings.

[jnurthen]

@domenic
https://w3c.github.io/core-aam/#mapping has this info I believe.

[domenic]

Thank you! I think you are referring to this text:

Except for the cases outlined below, user agents MUST always use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, rather than using the host language semantics.

Host languages can have features that have implicit WAI-ARIA semantics corresponding to roles. When a WAI-ARIA role is provided that has a corresponding role in the accessibility API, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. [...] When a WAI-ARIA role is provided that does not have a corresponding role in the accessibility API, user agents MAY expose the native semantic in addition to the WAI-ARIA role.

This seems to fit, if I am correct that:

• The role="" attribute "provides a WAI-ARIA role". (I think this is defined by http://w3c.github.io/aria/#host_general_role)
• The "native semantic" (= "host language semantics"?) is that given by https://w3c.github.io/html-aam/#html-element-role-mappings

I think that answers the question, and also gives the right extensibility point: for custom elements, HTML needs to define that it's no longer just the role="" attribute that "provides a WAI-ARIA role", but instead the combination of the role="" attribute plus, if the role="" attribute is absent, the default custom element role.

[jnurthen]

@joanmarie this was not as easy to find as I would have liked (also hidden in a block with a non-obvious heading). I think this might be a candidate for an editorial re-write.

[jnurthen]

Moving to 1.3 - this will not make 1.2