Core API
customElements.define()
Custom elements let you define your own HTML tags with JavaScript classes.
class UserBadge extends HTMLElement {
connectedCallback() {
this.textContent = this.getAttribute("name") ?? "Guest";
}
}
customElements.define("user-badge", UserBadge);
Web Components & Accessibility
Custom elements let you define your own HTML tags with JavaScript classes.
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.
customElements.define()
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
class UserBadge extends HTMLElement {
connectedCallback() {
this.textContent = this.getAttribute("name") ?? "Guest";
}
}
customElements.define("user-badge", UserBadge);
document.querySelectorAll(".user-badge").forEach(element => {
element.innerHTML = "<strong>Guest</strong>";
});
Code patterns
Use these examples as a quick reference when building reusable browser UI.
A compact example of the feature in context.
class UserBadge extends HTMLElement {
connectedCallback() {
this.textContent = this.getAttribute("name") ?? "Guest";
}
}
customElements.define("user-badge", UserBadge);
A common shortcut that creates maintenance or accessibility problems.
document.querySelectorAll(".user-badge").forEach(element => {
element.innerHTML = "<strong>Guest</strong>";
});
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.
Last reviewed: 11 June 2026. Custom elements are widely useful, but still test the exact browsers and rendering model your project supports.
Use these references when browser support, syntax details or proposal status matters.