---
name: accessible-components
description: Review and, when requested, repair web component accessibility, including keyboard interaction, focus, semantics and state announcements in comboboxes, menus and dialogs. Use for component behavior audits and targeted accessibility fixes.
---

# Accessible components

Review the component's complete interaction contract, not just its ARIA attributes. Use source inspection and a running browser where available. These instructions require the host agent's tools; they do not include an automated accessibility scanner.

## Establish the pattern

Read repository instructions and identify the user's expected behavior, framework, existing primitives and affected states. Prefer native controls when they satisfy the design. Do not replace a mature accessible primitive without evidence that it causes the problem. Consult the relevant current [WAI-ARIA APG pattern](https://www.w3.org/WAI/ARIA/apg/patterns/) and [references/interaction-review.md](references/interaction-review.md); avoid imposing menu semantics on ordinary site navigation.

Map the component's initial, open, selected, empty, loading, disabled and error states where they exist. Distinguish highlighted suggestions from committed values. In a tags input, adding multiple values does not automatically make its suggestion popup a multi-select listbox; choose the interaction model before choosing roles.

## Exercise behavior

Navigate from the preceding control using only the keyboard. Check opening, movement, activation, dismissal and continuation to the following control, including Shift+Tab. Inspect the accessible name, role, state and relationships in the DOM/accessibility tree. Verify that the active descendant exists when referenced and is visible. Check pointer behavior as well.

Exercise focus after closing overlays, deleting selected chips, filtering away the active suggestion and reaching empty/disabled results. Test validation and asynchronous changes without erasing user input. Avoid intercepting standard text-editing keys in an editable combobox. Ensure visible focus and that a sticky header or popup does not obscure the current control.

Use an existing automated checker when available and relevant. Investigate each result and include the tested open states. Automated results do not establish screen-reader behavior. If an actual screen-reader session is available, record the browser, reader and observed announcements; otherwise mark that verification pending. Do not infer WCAG conformance from using ARIA or from a zero-violation scan.

## Deliver and verify

For an audit, return reproducible findings with affected action, severity, observed versus expected behavior, evidence and the relevant pattern/reference. For a requested fix, preserve the component's public API and styling where possible, repair the interaction, and add focused tests for the behavior that failed. Retest mouse, keyboard and relevant states.

Report implemented behavior separately from unverified behavior. End with the checked matrix and any remaining manual validation. Do not add an accessibility certification or claim all assistive technologies are supported.