[a11y]: An exhaustive look at support for using HTMLInputElement with Web Components

[clshortfuse]

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 outside of a minor issue with Firefox improperly concatenating nodes for text content, a single element that passes down styles to content, and is accessible, is still very much possible.

[Westbrook]

It's been a while here, sorry. But, would you be interested in updating your results for the intervening browser versions that have hit the market?

[clshortfuse]

Sure, I can take another look. I believe Safari is still bugged but I'll have to double check v18.0

https://bugs.webkit.org/show_bug.cgi?id=260772

Firefox should be better now:

https://bugzilla.mozilla.org/show_bug.cgi?id=1826194