Accessibility across web & native
draftedconfidence: mediumthis tier holds 50% on the public scorecard (3/19 graded · 0 overturned) →
recommendation
Use semantic roles + labels, manage focus order, and announce dynamic updates; test with role-based queries, not data-testid.
- web → ARIA roles + keyboard focus management
- React Native → accessibilityRole/Label + screen-reader focus
- depth audit (contrast, intrinsics, dynamic type) → design-systems-governance
Options & tradeoffs
| option | tradeoff |
|---|---|
| semantic roles/labels | web ARIA vs RN accessibility props |
| focus management | keyboard (web) vs screen-reader focus (native) |
Canonical reading
Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.
A durable React a11y reference from a recognized expert: semantic HTML, labeling, focus management on route/modal changes, ARIA live regions, with concrete useId/useRef patterns and a WCAG-cited checklist.
Why LLM-generated components ship empty accessibility trees, and a five-layer enforcement system (prompt constraints, jsx-a11y lint, axe-core runtime tests, CI gates, headless primitives). Durable guidance as AI codegen becomes the default.
Depth (in-domain rules) is owned by the design-systems-governance skill — this entry is selection breadth.
Related in ui: styling · component-libs · animation · lists · i18n · charts · editors · svg · maps · calendars · polish