Accessibility status

What built Emily UI examples already do, what Emily does not guarantee, and which patterns are still gated on manual testing.

What every built example already does

Semantic HTML first; ARIA only where native elements cannot carry the meaning.
Visible label on every form control; hints and errors linked via aria-describedby; error styling driven by aria-invalid.
Skip link first, labelled nav landmarks, one h1 per page in page-level examples.
No colour-only meaning — status text leads, glyphs are aria-hidden.
Token-driven focus ring, never removed.
Reduced-motion handling on animated atoms (spinner, skeleton).

What Emily does not guarantee

No WCAG conformance claim is made. Accessibility-native, not audited-in: built examples use semantic HTML, token-driven focus styles, and honest status tracking — but static review is not manual assistive-technology testing, and no screen reader testing has been claimed that has not actually been run. Production projects still own their own audit.

Manual gates still open (needs-a11y-review)

FAQ accordion (organism) and FAQ page (template)

Why it waits: Grouped details/summary announcement quality needs a human assistive-technology pass.

Next step: Run the manual AT checklist (emily-components/docs/accessibility/faq-accordion-manual-test.md). The checklist is ready but has not been run yet.

Transparent-over-hero header

Why it waits: Text-over-image contrast cannot be verified statically.

Next step: Needs a per-image contrast strategy and a contrast-tested example before it ships.

Full-bleed image hero

Why it waits: Same contrast problem as the transparent header.

Next step: Needs a tested scrim treatment and a tested example.

Comparison table

Why it waits: Needs real content in a caption plus a th[scope] table inside a scroll area, verified on mobile and with assistive technology.

Next step: Build the example only alongside real testing; the card comparison is the built alternative today.

Rules for consumers

needs-a11y-review is not production-ready. Prototype if you accept the risk; do not ship unreviewed.
Interactive widgets (accordion ARIA pattern, rating input, JS wizards) wait for emily-js behaviours — they are needs-js, not built.
Statuses move only on evidence: completed checklist results or a tested example, never plausibility.

General guidance lives on the accessibility docs page; counts are on component build status.