Questions about Web Components + AccessibleNode

[caridy]

Custom elements and web components in general are a nightmare when it comes to accessibility, and we see this proposal as a possible solution. Still, we have questions:

1. focusablity

There is an example in the explainer on how to make a virtual node focusable (which is equivalent to set the tabindex attribute on a regular node), but that's all. Where can we find the specs for focusable? What about regular nodes? What if the owner of the element is already providing a tabIndex value via an attribute? Or is this something that is suppose to be resolved via tabIndex property on the node?

2. how to transition from aria being additive to being autonomous?

One of the biggest problem with WC is that in order to make something equivalent to a tr or button or an input, both authors of the component, and consumers of it has to be aware of it due to the semantics of HTML. The most basic example is an ordered list, and how can those elements be replaced with custom elements:

<ol>
   <li>1</li>
   <li>2</li>
</ol>

vs

<x-fancy-ol>
   <x-fancy-li>1</x-fancy-li>
   <x-fancy-li>2</x-fancy-li>
</x-fancy-ol>

As today, aria has been considered as additive, so adding aria role and aria attributes to ol and li will help you to produce something that screen readers can make sense of. But when replacing those things with a fancy custom element implemented by a web component, it implies that aria role and aria attributes must be sufficient to achieve the same semantics of the ol and li, unless that we go with the is attribute, which has its own problems (the coordination aspect that I mentioned above), e.g.:

<ol is="x-fancy-ol">
   <li is="x-fancy-li">1</li>
   <li is="x-fancy-li">2</li>
</ol>

The question is: will this proposal help to achieve autonomy in terms of accessibility? or the HTML semantics will still play an important role?

3. complex accessible widget guidelines

Assuming that we want to create a new WC, let's call it x-location-input, which is suppose to behave as an input element, but showing two input elements as part of its shadow DOM, for latitude and longitude respectably. For the consumer of the WC, this component is suppose to be focusable and fully accessible. Think of <input type="date"> as an equivalent component in terms of complexity, but it is implemented by the engine, how can we implement something similar in user-land? Will this proposal help to achieve such goal?

disclaimer: these are the top 3 questions that I gathered after talking to many folks from different companies about accessibility on WC, since I still have knowledge gaps, about accessibility and WC, I might got something very wrong, bear with me.

[joanmarie]

it implies that aria role and aria attributes must be sufficient to achieve the same semantics of the ol and li

Achieving role and attribute parity are planned for ARIA 1.2 (issue tracker). Beyond that, are there specific things you need from ARIA?

[littledan]

Based on what @joanmarie said, if there is role parity, would that remove the need for using is=?

@alice We've talked about accessibility web component guidelines in the past; has anything been published since then?

[alice]

@littledan Re is=: sadly, not really - it's more about behaviour than role. For example, <input type=text> has a lot of difficult or impossible to replicate behaviour.

Re guidelines - not that I'm aware of, but there is a very good chance I missed it.

[robdodson]

I'm working on accessibility web component guidelines with my teammate. Expect to see stuff start to roll out in Q4 probably.