Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for AOM implementation at the browser level with polyfill and documentation of current capabilities #3

Open
Westbrook opened this issue Jan 8, 2021 · 5 comments

Comments

@Westbrook
Copy link
Collaborator

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.

@LeaVerou
Copy link
Member

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.

@Westbrook
Copy link
Collaborator Author

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.

@ConradSollitt
Copy link

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.

@LeaVerou
Copy link
Member

I'm fine either way. The wiki is actually a repo, see the bottom right of e.g. this one

@Westbrook
Copy link
Collaborator Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants