webcomponents-cg
webcomponents-cg copied to clipboard
w3c
Support for AOM implementation at the browser level with polyfill and documentation of current capabilities
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.
Thank you for this detailed overview! Lots to dig into.
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.
I'd suggest starting from lower investment options and we can always move to higher investment ones as momentum builds.
Definitely, lower investment is better. In that I don't know of a way to get data out of the wiki for a repo, does it make sense to starts a "docs" directory in this repo with this sort of information?
If that works I can start bringing the more concrete concepts here into a PR, and we can go from there.
Docs makes sense to me as that would be easy for anyone to work with the data and/or docs through Git.
I haven't myself worked with the Github Wiki feature but if needed any info or data could be easily scrapped using Puppeteer https://pptr.dev/ or Playwritght https://playwright.dev/. I would be happy to help with that if needed.
@erikkroes you may be interested in being poked about this. I'd love to partner on some content in this area! There were some really great presentations of progress in this area at the WICG face to face this week, but getting into some "today you can/should do x" content would be great.