compliance-accessibility

Run automated scans with axe-core in tests or CI, lint source with eslint-plugin-jsx-a11y, and validate contrast on text and indicators. Then manually tab through the primary flow with a keyboard and screen reader, since automated tools catch only about a third of WCAG issues.

Use axe-core via @axe-core/cli, jest-axe, or @axe-core/playwright for WCAG rule scans, and eslint-plugin-jsx-a11y for static linting of missing names, roles, and keyboard handlers. Pair these with a contrast validator and manual keyboard testing.

No. Automated scans catch roughly a third of WCAG issues and gate only the obvious defects. A meaningful review requires keyboard-only navigation of the primary flow and screen reader verification of names, focus behavior, and error announcements.

Adding ARIA to non-semantic elements creates maintenance burden and often broken behavior when a native HTML element already provides the needed semantics and keyboard support. Use native controls first and reserve ARIA for cases with no native equivalent.

No. This is engineering guidance, not legal advice. Formal conformance claims, contract obligations, and jurisdiction-specific accessibility duties should be escalated to qualified legal or compliance professionals.