Core API
feature detection
Progressive enhancement starts with usable HTML and adds JavaScript as an improvement.
<a href="/account/settings">Account settings</a>
if ("customElements" in window) {
customElements.define("settings-link", SettingsLink);
}
Web Components & Accessibility
Progressive enhancement starts with usable HTML and adds JavaScript as an improvement.
A component should hide repetition without hiding meaning. Start with semantic HTML, then add the browser feature that solves the real problem.
The professional version is not only that the component works. It must remain accessible, testable, maintainable and understandable in production.
feature detection
Use the right HTML before adding custom behavior.
Keyboard, focus and assistive technology need deliberate support.
Clean up listeners and keep component boundaries clear.
Examples
<a href="/account/settings">Account settings</a>
if ("customElements" in window) {
customElements.define("settings-link", SettingsLink);
}
<button data-route="/account/settings">Settings</button> // Without JavaScript the navigation no longer works.
Code patterns
Use these examples as a quick reference when building reusable browser UI.
A compact example of the feature in context.
<a href="/account/settings">Account settings</a>
if ("customElements" in window) {
customElements.define("settings-link", SettingsLink);
}
A common shortcut that creates maintenance or accessibility problems.
<button data-route="/account/settings">Settings</button> // Without JavaScript the navigation no longer works.
Check support before depending on advanced browser features.
if ("customElements" in window) {
// Register or enhance the component.
}
Dynamic UI should communicate state changes clearly.
const status = document.querySelector("[aria-live]");
status.textContent = "Interface updated.";
Rules that matter
Web Components can be powerful, but the browser does not automatically make custom UI accessible.
The page should have meaning before JavaScript upgrades it.
Buttons, links and form controls already handle many accessibility details.
Dynamic interfaces should not trap or lose keyboard users.
Remove listeners and timers when components leave the page.
Shadow DOM can help, but it should not make the UI impossible to theme.
Keyboard testing catches real usability problems quickly.
Production thinking
Component code often gets reused everywhere. If the foundation is inaccessible, the problem spreads everywhere too.
This chapter is accessibility-heavy on purpose: reusable UI has to work for keyboard users, screen readers and dynamic content updates.
Production components need documented APIs, predictable lifecycle behavior, cleanup and browser-support decisions.
Important content should not be locked inside client-only behavior that search engines or no-JavaScript users cannot reach.
Live code lab
The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.
Mini assignment
Practice assignment
Try it yourself
Self-check
Answer these before moving to the next component lesson.
Senior audit upgrade
Web Components are valuable, but they are not required for every website. Learn them after DOM, events, forms and accessibility basics are stable.