# Accessibility verification

Verify a composition through its state transitions and its rendered behavior, not only its markup. Automated checks cover useful regressions, but do not certify accessibility or replace real browser and assistive-technology review. Keep the existing typography until a concrete comparison demonstrates a necessary change.

## Rendered check

Inspect every affected route in a real browser on desktop and at about 390px, in both themes: frame junctions, overflow of long text and code, the first Tab and `SkipLink`, navigation, keyboard interaction, reduced motion, theme persistence after reload, the error route and the state transitions you changed. A successful build alone does not verify rendered behavior.

## Automated coverage

The compatibility scenarios run on Chromium, Firefox and WebKit at desktop and narrow widths. They exercise native groups, field errors, pending and completed states, translated labels, modal dismissal and focus restoration, reduced motion, long content and enlarged root text. Root text enlargement is not browser zoom. WebKit automation is not proof that every released Safari or iOS version behaves identically.

At 320 CSS pixels, content should reflow without loss of information or function. Contain necessary code and table scrolling within their own region. Check individual cards, not only the page's total scroll width: clipping can conceal a broken layout. See [W3C Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html).

## Manual reading review

Use a representative editorial page and an interactive form. Check normal text, 200% text enlargement and actual browser zoom up to 400% on a desktop viewport around 1280px wide. Read important metadata, labels, long translations, links, code and error messages. Distinguish supplementary metadata from information required to understand or complete a task; use the body role for the latter when small metadata is unsuitable.

Compare any proposed typography change in both themes on desktop and mobile before making it a shared default. Small size alone is not evidence of a WCAG failure, and a passing contrast calculation does not establish comfortable reading.

## Manual keyboard and screen reader review

1. Record OS, browser, assistive technology, versions and the route tested. Test real Safari and Firefox where they are target browsers.
2. Start from reload. Tab to `SkipLink` and use it. Inspect landmarks, heading hierarchy, link names and translated controls. Focus must remain visible, including inside clipped and scrolling surfaces.
3. Open a modal with the keyboard; cycle through controls, use Escape and verify restored focus and scroll. Repeat after a viewport change.
4. Submit an invalid form. Verify the focused field, associated help/error, group legends and native checkbox/radio keyboard behavior. Start, cancel and complete work without losing input or announcing a result twice.
5. Read a chat response as it streams. Confirm new content is understandable without repeated announcements of the entire thread or token-by-token noise. Test stop, failure, retry and reading older messages. Do not move focus to each new message.

Keep progress announcements outside a busy region. Add a dedicated completion/status announcement in the consuming app if actual screen-reader behavior requires it; the toolkit's polite log does not guarantee a good streaming experience. See [W3C Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html).

## Evidence and completion

Report the exact automated command and results, screenshots inspected and manual scenarios performed. Mark unperformed reviews as not verified; never infer a screen-reader pass from ARIA attributes or WebKit results. Capture a failing sequence before changing the component and add a regression test where automation can represent it.