> Markdown version of [/videos/648-accessibility-with-web-components?t=263](https://www.wearedevelopers.com/videos/648-accessibility-with-web-components?t=263). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Accessibility with Web Components

Are your custom web components invisible to screen readers? Learn how the ElementInternals API adds robust accessibility semantics without cluttering your DOM.

- **Speakers:** Manuel Mauky
- **Event:** World Congress 2023
- **Published:** August 11, 2023
- **Duration:** 25:33
- **URL:** https://www.wearedevelopers.com/videos/648-accessibility-with-web-components

## Summary

Web components provide powerful, framework-agnostic encapsulation for design systems, primarily leveraging custom elements and the shadow DOM. However, unlike standard HTML, custom web components lack built-in accessibility semantics and default keyboard interaction routing. As a result, custom UI controls are inherently hidden from assistive technologies like screen readers out of the box.

To bridge this accessibility gap, developers must manually construct component semantics. While applying ARIA attributes works for basic setups, programmatically overriding these states can clash with user-defined roles or modern declarative frameworks. A more robust solution lies in the emerging accessibility object model specification. By utilizing the ElementInternals API via attachInternals(), developers can define default, non-reflective accessibility properties internally without cluttering the external DOM or causing attribute synchronization issues.

Beyond semantic labeling, engineers must also manage interactive logic manually, wiring tabindex and event listeners to ensure predictable focus management and keyboard operability. Although the concept of extending built-in HTML elements offers a theoretical way to inherit native accessibility, restricted browser support—particularly explicit pushback from Safari—makes it an impractical production strategy. Ultimately, prioritizing standard HTML elements remains the best baseline, reserving custom component builds for specialized, heavily interactive requirements.

**Keywords:** web components accessibility, custom elements, shadow dom encapsulation, accessibility object model, elementinternals api, non-reflective accessibility properties, aria patterns, keyboard interaction routing, framework-agnostic ui, design systems component development, focus management, screen reader semantics, extending built-in elements, cross-browser compatibility

## Chapters

1. **Building a framework-agnostic design system with web components** (00:00) — Achieving a consistent user interface across diverse application teams requires a framework-agnostic web component library.
1. **Understanding standard technologies behind web component architecture** (04:23) — Utilizing browser standards like custom elements and shadow DOM prevents vendor lock-in across implementation frameworks.
1. **Resolving default accessibility limitations in custom web components** (09:19) — Unrecognized custom elements require explicit ARIA attributes and design patterns to function correctly with assistive technologies.
1. **Implementing the accessibility object model for web component internals** (14:06) — Upcoming browser APIs enable internal JavaScript definitions for default accessibility properties without awkwardly modifying the target DOM.
1. **Managing keyboard interaction and focus states across shadow boundaries** (17:25) — Emulating standard form behaviors demands manual event listeners and programmatic focus transitions across customized shadow boundaries.
1. **Evaluating the limitations when extending standard HTML elements** (20:42) — Inheriting built-in semantic structures by expanding native inputs faces severe cross-browser support and encapsulation challenges.
1. **Addressing audience inquiries on component styling and validation constraints** (22:37) — Applying external layout modifications and tracking internal form validation require specialized techniques to bypass default encapsulation architectures.

## Related Moments

- [Audience questions on accessibility and framework tradeoffs](https://www.wearedevelopers.com/videos/459-extending-html-with-web-components) (from "Extending HTML with Web Components")
- [Advocating for semantic HTML over complex framework component workarounds](https://www.wearedevelopers.com/videos/1753-wearedevelopers-live-spicy-vanilla-web-css-magic-more) (from "WeAreDevelopers LIVE – Spicy Vanilla Web, CSS Magic & More")
- [Introduction to building accessible web frontends](https://www.wearedevelopers.com/videos/403-the-what-why-who-and-how-of-accessibility-on-the-web) (from "The What, Why, Who and How of accessibility on the web")
- [Implementing low-hanging accessibility fixes in frontend web applications](https://www.wearedevelopers.com/videos/1847-secure-and-accessible-login-systems-ramona-schwering) (from "Secure and Accessible Login Systems - Ramona Schwering")
- [Why the developer community mistakenly rejects native HTML components](https://www.wearedevelopers.com/videos/1265-keith-cirkle-of-github-on-react-fatigue) (from "Keith Cirkle of GitHub on React Fatigue")
- [Overcoming challenges in building accessible interfaces](https://www.wearedevelopers.com/videos/1589-building-interactive-async-ui-with-react-19-and-ariakit) (from "Building Interactive Async UI with React 19 and Ariakit")

## Related Articles

- [How Developers Can Focus on Maintaining Satisfaction With Accessibility](https://www.wearedevelopers.com/magazine/109-how-developers-can-focus-on-maintaining-satisfaction-with-accessibility)
- [The HTML Elements That You’re Probably Over-Engineering](https://www.wearedevelopers.com/magazine/646-the-html-elements-that-you-re-probably-over-engineering)
- [Dev Digest 133 - Back to Front](https://www.wearedevelopers.com/magazine/474-dev-digest-133-back-to-front)
- [The Web We Broke (And Why AI Agents Are Paying the Price) - AgentCon Berlin](https://www.wearedevelopers.com/magazine/735-the-web-we-broke-and-why-ai-agents-are-paying-the-price-agentcon-berlin)

## Related Jobs

- [Working Student Frontend Development](https://www.wearedevelopers.com/jobs/ext/1185791-working-student-frontend-development) at **ZEISS Group**
- [Junior Frontend Engineer](https://www.wearedevelopers.com/jobs/ext/1532351-junior-frontend-engineer) at **Almedia**
- [Senior Web Designer, Growth](https://www.wearedevelopers.com/jobs/ext/102722-senior-web-designer-growth) at **Intercom, Inc.**
- [Senior Product UI Designer](https://www.wearedevelopers.com/jobs/ext/1998621-senior-product-ui-designer) at **Almedia**
- [Software Engineer Frontend (all genders welcome) in the field of Water Line Integrity Solutions](https://www.wearedevelopers.com/jobs/ext/127888-software-engineer-frontend-all-genders-welcome-in-the-field-of-water-line-integrity-solutions) at **Rosenxt Group**
- [Remote Senior Full-Stack Engineer](https://www.wearedevelopers.com/jobs/ext/645320-remote-senior-full-stack-engineer) at **Edge Impulse**