Web Accessibility Compliance Guide

The Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C in October 2023, is the current standard for web accessibility. WCAG defines three conformance levels: A (minimum), AA (the standard most regulations require), and AAA (highest). Most legal requirements and industry standards target WCAG 2.2 Level AA compliance.

WCAG is organized around four principles, known by the acronym POUR. Perceivable means information and UI components must be presentable in ways users can perceive, accounting for visual, auditory, and cognitive differences. Operable means UI components and navigation must be operable by all users, including those using keyboards, switches, or voice control. Understandable means information and interface operation must be understandable, with consistent navigation, predictable behavior, and clear error messages. Robust means content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

WCAG 2.2 added nine new success criteria to the existing 2.1 guidelines. Key additions include Focus Not Obscured (minimum), which requires that focused elements remain at least partially visible when other content overlaps, and Dragging Movements, which requires that any functionality using drag movements can also be operated with single pointer actions. Target Size (minimum) requires interactive targets to be at least 24x24 CSS pixels, improving usability for users with motor impairments.

The legal landscape for accessibility is intensifying. In the United States, the Department of Justice published a final rule in 2024 requiring state and local government websites to meet WCAG 2.1 Level AA. ADA-related web accessibility lawsuits have increased every year, with over 4,600 filed in 2023 alone. The European Accessibility Act takes effect in June 2025, requiring accessible digital products and services across the EU. Accessibility is no longer optional for any business with a web presence.

Semantic HTML is the foundation of web accessibility. When you use the correct HTML elements for their intended purpose, assistive technologies can interpret and present content accurately without additional markup. A button element is announced as a button by screen readers, receives keyboard focus automatically, and activates with both Enter and Space keys. A div with an onclick handler does none of these things without significant additional work.

Use landmark elements to give your page navigable structure. The header element wraps your site's banner and primary navigation. The main element contains the page's primary content. The nav element identifies navigation blocks. The footer element wraps footer content. Screen reader users navigate between landmarks directly, skipping repetitive content. A page without landmarks forces users to listen through every element sequentially.

Use heading levels (h1 through h6) to create a logical document outline. Every page should have exactly one h1. Headings should follow a hierarchical structure without skipping levels. Screen reader users often navigate by heading to scan page content, making a well-structured heading hierarchy essential for efficient content consumption.

ARIA (Accessible Rich Internet Applications) attributes supplement semantic HTML for complex interactive components that have no native HTML equivalent, such as tabs, accordions, tree views, and comboboxes. The first rule of ARIA is: don't use ARIA if a native HTML element provides the behavior you need. A native button element is always better than div role="button". When ARIA is necessary, use established patterns from the WAI-ARIA Authoring Practices Guide. Common ARIA attributes include aria-label (provides an accessible name), aria-expanded (indicates expandable state), aria-live (announces dynamic content changes), and aria-hidden (hides decorative elements from assistive technology).

Full keyboard accessibility is a WCAG Level A requirement and a baseline expectation for any accessible website. Many users navigate exclusively with keyboards, including people with motor impairments, power users, and screen reader users. If any functionality on your site requires a mouse, it's inaccessible to these users.

All interactive elements must be reachable and operable with the keyboard alone. Native HTML elements like links, buttons, and form controls are keyboard-accessible by default. Custom interactive elements built with divs or spans need tabindex="0" to enter the tab order and JavaScript key event handlers for activation. The Tab key moves focus forward through interactive elements. Shift+Tab moves backward. Enter and Space activate buttons and links. Arrow keys navigate within composite widgets like menus, tabs, and radio groups.

Focus management is critical for single-page applications and dynamic content. When new content appears (a modal dialog, an expanded section, or a route change), focus must move to the new content. When a modal closes, focus should return to the element that triggered it. Use the inert attribute or aria-hidden to prevent focus from moving behind modal overlays. Test focus order by tabbing through your entire page. Focus should follow a logical reading order without getting trapped in any component.

Provide visible focus indicators on every interactive element. The default browser focus outline is functional but often overridden by CSS resets. WCAG 2.2 requires focus indicators with a minimum contrast ratio of 3:1 against adjacent colors and a minimum area of the element's perimeter plus 2 CSS pixels. Design custom focus styles that are prominent and consistent across your site. Never use outline: none without providing an alternative visible indicator. Skip navigation links ("Skip to main content") should be the first focusable element on every page, allowing keyboard users to bypass repetitive navigation.

Color and visual design choices directly affect accessibility for users with low vision, color blindness, and cognitive disabilities. Approximately 8% of men and 0.5% of women have some form of color vision deficiency. WCAG defines specific contrast ratios that ensure text and UI components are perceivable across a wide range of visual abilities.

WCAG 2.2 Level AA requires a minimum contrast ratio of 4.5:1 for normal text (under 18pt or 14pt bold) and 3:1 for large text (18pt+ or 14pt+ bold). Level AAA increases these to 7:1 and 4.5:1 respectively. Use contrast checking tools like WebAIM's Contrast Checker, the Stark plugin for Figma, or Chrome DevTools' built-in contrast overlay during design and development. Dark text on a white background easily meets these ratios, but contrast issues frequently appear with colored text on colored backgrounds, placeholder text in form fields, and text overlaid on images.

Never use color as the only means of conveying information. A form that marks required fields only with red text, or a graph that distinguishes data series only by color, is inaccessible to color-blind users. Supplement color with text labels, patterns, icons, or other visual indicators. Error messages should include descriptive text in addition to red highlighting.

Support user preferences for reduced motion and color schemes. Use the prefers-reduced-motion media query to disable or simplify animations for users who experience motion sickness or vestibular disorders. Support prefers-color-scheme to offer dark mode, which many users with light sensitivity prefer. Ensure sufficient contrast in both light and dark themes. Set text at a readable base size (16px minimum for body text) and use relative units (rem, em) so users can scale text with browser settings. Never disable zoom with maximum-scale=1 in the viewport meta tag.

Automated tools catch approximately 30-40% of accessibility issues. The remaining 60-70% require manual testing and human judgment. An effective accessibility testing strategy combines automated scanning, manual keyboard and screen reader testing, and user testing with people who have disabilities.

Automated testing tools provide a fast first pass to catch common issues. axe-core (by Deque Systems) is the most widely used accessibility testing engine, powering browser extensions (axe DevTools), CI/CD integrations, and testing libraries. Use @axe-core/react or jest-axe to run automated checks in your test suite. Lighthouse includes accessibility audits in its reports. WAVE (by WebAIM) provides a visual overlay showing errors, alerts, and structural elements directly on your page. Run automated scans on every page template and fix all reported issues before proceeding to manual testing.

Manual keyboard testing is essential and requires no special tools. Tab through every page, verifying that all interactive elements are reachable, focus is visible, and functionality works without a mouse. Test that modals trap focus correctly and return it when dismissed. Verify that dynamic content updates are perceivable without visual context. This testing catches focus order issues, keyboard traps, and interaction patterns that automated tools miss.

Screen reader testing verifies that your site works with the assistive technology real users depend on. Test with at least two screen readers: NVDA (free, Windows) with Firefox or Chrome, and VoiceOver (built-in, macOS/iOS) with Safari. These two combinations cover the majority of screen reader users. Verify that all content is announced accurately, form labels are associated correctly, error messages are communicated, and navigation is logical. Consider conducting usability testing with users who have disabilities. Their feedback reveals issues no tool or developer testing can surface, and their insights improve the experience for all users.