Web components + A11y

I have a few questions about web components and Accessibility, I read some articles but I never see any examples or case histories that I can test by myself. I did some tests but I'm not sure they were exhaustive.

My questions are:

1. Web components are completely compatible with a11y tools?
2. Are some limitations if there are many web components encapsulations?
3. Are some guidelines or references?
4. there are any tools (es. wave.webaim) than understand web components correctly?

In late 2022, I did a comprehensive analysis of web components for possible use in my enterprise organization. I conducted testing using my own custom web-components as well as a number of pre-built frameworks available.

Here's my take on the issue. Others will probably disagree with me.

Are Web-Components Compatible with A11y Tools?

Kind of. Web-components are somewhat compatible with existing a11y tools, to the extent that the tool knows what it's looking for.

Because web-components utilize custom element names, it can be more difficult for a tool to identify relationships between elements (e.g. parent-child relationships) and find issues when compared to using generic HTML elements like <p> or <li>.

In my testing, all of the tools that I used were able to detect the custom web-components and identify simple issues like color-contrast without a problem. These tools included Lighthouse, Axe, and Wave.

Accessibility Limitations of Web-Components

One major issue is cross-shadow aria delegation, which basically means that browsers can't correctly associate elements inside the shadow DOM with elements in the light DOM, especially when it comes to things like aria- attributes, input and label elements.

I am currently using custom elements in new projects, but for this reason and others, I'm not using shadow DOM just yet.

Another accessibility-related limitation that I encountered was that accessibility wasn't often baked into what I was doing the way it would be if I were using something like Bootstrap or even SvelteKit.

With interactive components like mobile navigation menus, tooltips, modals, or anything similar, you really have to know what you're doing. You'll likely have to implement all the correct aria- attributes yourself and you'll probably need to write some JS to ensure accessible keyboard behavior for things like tabs or multi-level menus.

If you have any parent-child relationships between elements (e.g input and label that are custom elements), the browser won't have the benefit of semantic HTML or content models. Everything is essentially a generic element. It's almost like the early days of ARIA where everything was a div.

There are also a number of CSS-based issues that don't work in DevTools due to the encapsulation. This leads to tools like the Accessibility Tree panel or the Computed Properties panel not displaying correctly.

Guidelines or References

You should be able to read and understand the WCAG and ARIA specs without relying on automated tools to tell you what is and isn't okay. The tools should be there as a semi-automated time saver rather than a source of knowledge.

You should be able to read HTML and JS specifications and understand what they say.

You should be able to do your own manual accessibility testing on the application, page, and component levels using a screen reader with your monitor turned off.

Any Tools that Understand Web-Components

The Accessibility Object Model is an experimental JavaScript API being incubated at the W3C by Google, Apple, and Mozilla. It proposes several new features intended to solve existing accessibility use cases. This is probably still a few years away from being useable though.

Caveats

I suppose it matters how you create your components. You can either extend an existing HTML element that's part of the spec (e.g. class extends HTMLParagraphElement) or you can create a fully custom element (e.g. class extends HTMLElement). All of my testing that didn't involve frameworks utilized the latter approach.

Everything that I read seemed to indicate that extending native HTML elements was a bad idea and could lead to problems down the road if the spec changes in ways that people didn't anticipate.

Generally speaking, it's bad practice to extend objects that you don't own.

Synopsis

My determination after the evaluation was that there's a lot of potential in web-components, but the current state of the technology makes practical use quite difficult. Using Chrome DevTools to de-bug components was extremely frustrating.

I think that it's probably more trouble than it's worth for right now -- at least until some better tooling becomes more ubiquitous. The encapsulation is pretty cool, and I like the idea that web components are very close to being React that just runs natively in a browser.

In the meantime, Svelte is remarkably similar to web-components, but has better developer tooling and accessibility. If it's a fit for your use-case, I'd recommend that as a short-term solution for the next few years.