Intent to Ship: Default Accessibility Semantics for Custom Elements (without relationship properties)

[Rakina Zata Amni]

Contact emails

abox...@chromium.org, mere...@chromium.org, dom...@chromium.org, tk...@chromium.org, rak...@chromium.org 

Explainer

https://github.com/alice/aom/blob/gh-pages/explainer.md#default-semantics-for-custom-elements-via-the-elementinternals-object

Spec

Specification: https://github.com/whatwg/html/pull/4658

TAG review: https://github.com/w3ctag/design-reviews/issues/401 

Summary

With this feature, custom element authors can use ElementInternals to set a custom element's default accessibility role, states, and properties, much like the default accessibility semantics for native elements. 

See also Intent to Ship for ARIA Attribute Reflection for Elements.

Note that we aren’t shipping relationship properties (ariaActiveDescendantElement, ariaLabelledByElements, etc.) because the spec for those properties on Element is not finalized yet (as explained in the Intent to Ship for ARIA Attribute Reflection for Elements), and we don't want to add capabilities to ElementInternals before adding them to Element. Instead, we will separately ship the relationship properties on both Element (for built-in elements) and ElementInternals (for custom elements) later on.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/b-cGz9c67pM/0zvBzjhrAAAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Risks

Interoperability and Compatibility

In past discussions at web components F2F meetings, other browser vendors have been supportive of the general idea. Several representatives from other browsers are also present on the pull request thread. However, none of them have given clear signals about this specific API proposal.

In general, the feature is quite small and should be easily implementable in other browsers.

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: Some positive response to the I2I

Ergonomics

This feature is built on top of the ElementInternals API.

Activation

The API is the same as ARIA properties, but instead of modifying/getting the properties on the Element directly, the web developer would do it on ElementInternals.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, https://wpt.fyi/results/custom-elements/form-associated/ElementInternals-accessibility.html

Entry on the feature dashboard

https://chromestatus.com/feature/5962105603751936

[Daniel Bratell]

LGTM1

More attention from other vendors would have been nice so, but I see no objections and I imagine it's mostly just a question of time and resources.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r6OcPq1w6g3yE%3DBdKP9pc5xJvQuXcOzAZk_-Kv9%3D%2B7DOw%40mail.gmail.com.

[Alex Russell]

LGTM2. Excited to see this move forward!

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Chris Harrelson]

LGTM3, modulo a question about the spec: I see the PR is still open and not modified since September 25, is that because of outstanding feedback?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/918e9811-0eaa-4f21-a4d6-728bba09b0de%40chromium.org.

[Domenic Denicola]

From: Chris Harrelson <chri...@chromium.org>

> LGTM3, modulo a question about the spec: I see the PR is still open and not modified since September 25, is that because of outstanding feedback?

Not really. All feedback has been responded to. This was mostly just a matter of waiting for implementation to catch up (in particular, figuring out how we wanted to stage this with regard to the Element version and the relationship properties). Plus the usual rule that we don't merge things into WHATWG specs without multi-implementer interest (which, as noted in the I2S, there seems to be some of, but not any crystal-clear signal).

[Chris Harrelson]

Ok. File a Mozilla public standards position issue filed to get that indication from them?

LGTM3 in the meantime.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR13MB34327BB834A45E664F389E7CDF630%40CH2PR13MB3432.namprd13.prod.outlook.com.

[Domenic Denicola]

From: Chris Harrelson <chri...@chromium.org>

> Ok. File a Mozilla public standards position issue filed to get that indication from them?

Thanks for the reminder; we forgot to link to our previous attempts at outreach. https://github.com/mozilla/standards-positions/issues/201 was filed 2019-09-04, and does have +Anne saying "this is something we'd like to see happen", but it hasn't made its way onto the dashboard, so I'm unsure whether we should use "Positive signals".

[Anne van Kesteren]

On Thu, Oct 31, 2019 at 8:41 PM Domenic Denicola <d...@domenic.me> wrote:
> Thanks for the reminder; we forgot to link to our previous attempts at outreach. https://github.com/mozilla/standards-positions/issues/201 was filed 2019-09-04, and does have +Anne saying "this is something we'd like to see happen", but it hasn't made its way onto the dashboard, so I'm unsure whether we should use "Positive signals".

You can count that as support. There's a couple details around types
Jamie Teh pointed out that I missed, as you know, but happy with the
progress we're making on those.