Web Accessibility & WCAG Standards

WCAG 2.1 is organized around four principles, remembered by the acronym POUR. Perceivable: users must be able to perceive all information and UI components through at least one sense. Requirements: all images have descriptive alt text; all video content has captions; color is not the sole way of conveying information (e.g., error states use text or icons in addition to red color); text maintains sufficient color contrast against its background (4.5:1 ratio for normal text; 3:1 for large text at AA compliance). Operable: all functionality must be operable through keyboard alone (users with motor disabilities who cannot use a mouse must be able to navigate, activate, and complete all workflows using Tab, Enter, arrow keys, and Escape). Requirements: focus states are clearly visible; no keyboard traps (user can always navigate out of any UI element); skip navigation links for screen reader users. Understandable: the interface must be understandable in its language, behavior, and error handling. Requirements: language of the page is specified in the HTML; form fields have visible labels; error messages clearly identify what went wrong and how to fix it; UI behavior is predictable (no unexpected context changes on focus). Robust: content must be interpreted reliably by assistive technologies. Requirements: semantic HTML (use heading hierarchy, landmark elements, ARIA roles appropriately); form elements have associated labels; custom interactive components implement the correct ARIA pattern.

Accessibility testing requires a combination of automated scanning and manual testing — automated tools find approximately 30–40% of WCAG issues; manual testing with assistive technologies and disabled user research finds the rest. Automated testing tools: Axe (browser extension + CI integration — the most widely used, most accurate automated tool); WAVE (WebAIM's browser extension — good for visual annotation of issues); Lighthouse (built into Chrome DevTools — includes accessibility audit). Automated testing should run in the CI pipeline on every pull request, failing the build if new accessibility violations are introduced. Manual testing protocol: keyboard navigation audit (navigate every workflow using only the keyboard — Tab to navigate forward, Shift+Tab to navigate backward, Enter/Space to activate, Escape to close). Document any traps or broken paths. Screen reader testing: test with NVDA + Firefox (Windows, free) and VoiceOver + Safari (macOS, built-in). Navigate through the core user flows and identify any elements that are not announced correctly, have missing context, or create confusion. Color contrast check: use a color contrast analyzer tool (ColorContrastChecker, Colour Contrast Analyser app) on all text/background combinations in the design system and product. User testing with people with disabilities: quarterly usability sessions with 2–3 users with relevant disabilities (visual, motor, cognitive) provide the qualitative insights that automated tools cannot generate.

A Voluntary Product Accessibility Template (VPAT) is a standardized document — published by the Information Technology Industry Council (ITI) — that describes how a product meets each WCAG 2.1 criterion and the Section 508 requirements (the US federal accessibility law). Enterprise and government procurement teams require a completed VPAT (formally called an Accessibility Conformance Report, ACR) as part of vendor evaluation. Without a VPAT, many government, healthcare, financial services, and education sector deals are automatically disqualified — the security questionnaire equivalent for accessibility. VPAT sections: for each WCAG success criterion, the VPAT records: Supports (the product fully meets the criterion); Partially Supports (the product meets some but not all requirements with explanation); Does Not Support (the product does not meet this criterion with explanation); and Not Applicable (the criterion does not apply to this product type). VPAT honesty and accuracy: a VPAT that claims "Supports" for criteria the product doesn't meet is a legal liability. The VPAT should be prepared with a combination of accessibility audit results (automated + manual testing) and legal review. Product Ops coordinates the VPAT production — engaging an external accessibility consultant for the audit, the legal team for review, and maintaining a quarterly update cadence as the product changes (a VPAT more than 12 months old without updates is considered unreliable by procurement teams).