-
Notifications
You must be signed in to change notification settings - Fork 12
Description
Accessibility is an easy nit to pick when discussing the potential usage of web components, and particularly shadow DOM, in a project. While shadow DOM is certainly not a requirement when working with custom elements, its benefits (functional and style encapsulation, the slots API, etc.) make it quite enticing. In this way, advancing the specification and implementation of the AOM across browser seems like a great place for this group to spend effort.
In the fall of 2020 there was an accessibility and WCs face to face to discuss Design questions about IDREF/Element attribute reflection, Element reflection and shadow roots, Allow setting default accessibility semantics for custom elements, and Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? . Read the meetings notes here. The general energy was that everyone was excited about moving forward these concepts, specifications, and APIs.
With this in mind, I wanted to open the conversation around how we could support/prepare for/inform these APIs at the community level.
@calebdwilliams has done some interesting work around polyfilling attachInternals() in support of form association that might be worth discussing as a basis for further work in this area: https://github.com/calebdwilliams/element-internals-polyfill @kevinpschaaf has the Polymer team made any concerted efforts in this area? Could this be a great way to continue the larger conversation of separating the https://github.com/webcomponents/polyfills story from its Google centric upbringing?
Having a formal place for this story to live will also go a long way to dispel the certainty that can be had in developers that shadow DOM "cannot be accessible". What sort of canonical reference can this community group offer as a sign post of the realities that have actualized over recent years and will develop over the next few years? Lower investment options could be building out the wiki and/or markdown structure of this repo. Higher investment could including deploying that markdown as part of this repos GitHub pages or possibly expanding into a more "known" property like webcomponents.org, etc.
Of particular interest as we begin to document practices is discussing how we might go about documenting what is possible now (by browser even) and clarifying the upcoming capabilities both spec'd and proposed in a way that can empower this community and its followers to lean into the specification development process enabling even better capabilities over the long term.