Component Accessibility

Component accessibility is the discipline of building individual user interface components so that they are fully operable and understandable by all users, including those who rely on assistive technologies. In modern web development, applications are typically composed of discrete, reusable components such as buttons, input fields, dropdown menus, modal dialogs, tabs, accordions, carousels, and data tables. Each of these components must independently meet accessibility standards. An accessible component fulfills several requirements simultaneously. It communicates its identity (what it is), its state (whether it is expanded, selected, disabled, or checked), and its behavior (what happens when the user interacts with it) through a combination of native HTML semantics and ARIA attributes. It is fully operable via keyboard without requiring a mouse. It manages focus correctly, placing the user's cursor where they expect it after interactions. And it meets visual standards for color contrast, text size, and target dimensions. The challenge is that many modern UI patterns, such as custom dropdowns, date pickers, or drag-and-drop interfaces, lack native HTML equivalents. Developers must construct these widgets from generic elements like `<div>` and `<span>`, which carry no inherent semantic meaning. Without deliberate accessibility work, these custom components are invisible or inoperable for assistive technology users.

Components are the building blocks of digital interfaces. If the building blocks are inaccessible, everything constructed from them will be inaccessible. This makes component-level accessibility the most leverage point in a development workflow. **Foundation of page-level accessibility.** A page is a composition of components. If each component is individually accessible, the page starts from a strong foundation. While page-level concerns like heading hierarchy and landmark structure also matter, they build upon component-level accessibility rather than replacing it. **Reuse amplifies impact.** In component-based architectures (React, Angular, Vue, Web Components), a single component may be instantiated hundreds or thousands of times across an application. Fixing accessibility at the component level propagates to every instance. Conversely, an accessibility defect in a component multiplies across every usage. **User expectations.** Assistive technology users rely on components behaving according to established conventions. A button should activate on Enter and Space. A tab interface should respond to arrow keys. A dialog should trap focus. When components follow these conventions, users can interact efficiently. When they deviate without reason, users encounter confusion and barriers. **Legal requirements.** WCAG success criteria directly address component-level concerns. Criterion 4.1.2 (Name, Role, Value) requires that all user interface components have accessible names, roles, and states communicated to assistive technologies. Criterion 2.1.1 (Keyboard) requires that all functionality be operable from a keyboard. These are fundamentally component-level requirements.

Accessible component development follows a consistent methodology: **Start with semantic HTML.** The first rule of ARIA is "do not use ARIA if you can use a native HTML element." Native elements like `<button>`, `<input>`, `<select>`, `<a>`, `<dialog>`, and `<details>` provide built-in semantics, keyboard support, and assistive technology communication. A `<button>` element is announced as a button, responds to Enter and Space, and is focusable by default. Recreating this behavior on a `<div>` requires extensive ARIA and JavaScript work. **Add ARIA when necessary.** For components that have no native HTML equivalent (tabs, comboboxes, tree views, carousels), use ARIA roles, states, and properties to communicate the component's semantics. Follow the WAI-ARIA Authoring Practices Guide for established patterns. Key ARIA considerations include `role` to identify the type of widget, `aria-label` or `aria-labelledby` to provide an accessible name, `aria-expanded` to indicate whether a collapsible section is open, `aria-selected` for selected items in a list or tab set, `aria-live` for dynamic content that updates without page reload, and `aria-describedby` for supplementary descriptions. **Implement keyboard interactions.** Every interactive component must be fully operable via keyboard. The expected keyboard behaviors for common widgets are documented in the WAI-ARIA Authoring Practices Guide. Standard patterns include Tab to move between components, Enter or Space to activate buttons and links, arrow keys to navigate within composite widgets like tabs and menus, Escape to close overlays like dialogs and dropdowns, and Home and End to jump to the first or last item in a list. **Manage focus.** Components that change the visible interface must manage focus explicitly. When a modal dialog opens, focus should move into the dialog. When it closes, focus should return to the element that triggered it. When an item is deleted from a list, focus should move to a logical adjacent element. Failure to manage focus leaves keyboard users stranded. **Provide visual feedback.** All interactive states must have sufficient visual distinction. Focus indicators must meet WCAG 2.2 Focus Appearance requirements. Disabled states must be conveyed both visually and programmatically. Selected, expanded, and error states should be clearly distinguishable. **Test thoroughly.** Test each component with keyboard only, with at least two screen readers (NVDA on Windows, VoiceOver on macOS/iOS), with automated tools like axe-core, and at various zoom levels and viewport sizes. Document the expected behavior for each test scenario.