[WICG/webcomponents] [a11y]: An exhaustive look at support for using HTMLInputElement with Web Components (Issue #996)

Hi everyone!

For the past few months I've been working with Web Components specifically targeting performance and accessibility.

I've recently sat down to compile all the ways we can (and cannot) use HTMLInputElement with Web Components while staying accessible and not sacrificing author customizability. Most of these things I've discovered myself, but never actually committed them to writing. So I've taking the time to list everything down in one big table and hopefully start filing the issues:

https://codepen.io/shortfuse/pen/PodMYBo

Chrome works very well with everything. Webkit and Firefox have issues.

Unfortunately, it seems wrapping native HTMLInputElement cannot safely be done in production with a one-size fits all solution. It will require JS to patch areas where browser are not properly parsing ARIA labels. From the top of my head, this will likely mean manually parsing and observing `<slot>` elements and applying their textContent as `aria-label`. It's not as dynamic as Web Components should be. This is probably standard for `FormAssociated` elements, but if the idea is for a Web Component to extend/wrap a native form element, we shouldn't have to rewire everything.

That said, light DOM has it's issues as well, but outsize of a minor issue with Firefox improperly concatenating nodes for text content, a single element that passes down styles to content and is accessibility is still very much possible.




-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/996
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/996@github.com>