accessibility

Keyboard and screen reader accessibility requires semantic HTML, ARIA labels, and proper keyboard navigation. Audit your UI for missing focus management, add landmark roles and labels, ensure all interactive elements are keyboard-operable, and test with screen readers to verify content is announced correctly.

WCAG 2.1 is the Web Content Accessibility Guidelines standard defining how to make web content accessible. It organizes requirements into POUR principles (Perceivable, Operable, Understandable, Robust) across three conformance levels: A, AA, and AAA. Most organizations target Level AA compliance.

Start by testing keyboard navigation—tab through all interactive elements and verify focus is visible. Add missing ARIA labels and roles to components. Check color contrast ratios against WCAG standards. Use automated testing tools to identify semantic HTML issues, then manually verify screen reader compatibility with assistive technologies.

ARIA attributes enhance accessibility but cannot fully replace semantic HTML. Use ARIA to add labels, descriptions, and roles where semantic elements don't exist, but prioritize proper semantic HTML first—use `<button>` instead of `<div role="button">`, and `<nav>` for navigation landmarks. ARIA works best as a supplement, not a replacement.

Level A is the baseline (e.g., alt text for images). Level AA adds stricter requirements (e.g., 4.5:1 color contrast, clear language). Level AAA demands the highest standard (e.g., 7:1 contrast, sign language for video). Most organizations target AA; AAA is reserved for specialized contexts like government or healthcare.

Manual testing with real screen readers (NVDA, JAWS, VoiceOver) is essential—automated tools catch structural issues but miss announcement quality. Verify all content is announced, interactive elements are discoverable and operable via keyboard, form fields have labels, and landmarks guide navigation. Testing requires hands-on use of assistive technology.