Web Accessibility: WCAG 2.2 Standards and Inclusive Design

Web accessibility ensures people with disabilities can perceive, understand, navigate, and interact with websites effectively. With over 1.3 billion people worldwide experiencing significant disability, accessibility is both a legal requirement and a business imperative. ADA lawsuits related to web accessibility reached record numbers in 2024 with over 4,600 federal lawsuits filed. Major companies including Domino’s, Beyoncé’s company Parkwood Entertainment, and Harvard University have faced accessibility litigation, often resulting in costly settlements and court-mandated remediation.

WCAG Standards and Legal Compliance

The Web Content Accessibility Guidelines (WCAG) 2.2 define international standards for web accessibility organized around four principles — Perceivable, Operable, Understandable, and Robust (POUR). WCAG 2.2 was published in October 2023 by the World Wide Web Consortium (W3C), adding new success criteria for focus visibility (2.4.11 Focus Appearance), accessible authentication (3.3.7 Accessible Authentication), and drag-and-drop operations (2.5.8 Dragging Movements).

WCAG provides three conformance levels. Level A removes critical barriers — keyboard accessibility for all interactive elements, text alternatives for non-text content, and captions for synchronized media. Level AA addresses major barriers — color contrast of at least 4.5:1 for normal text, resizable text up to 200% without loss of content, and consistent navigation across pages. Level AAA meets the highest standards — extended time limits for timed content, sign language interpretation for pre-recorded audio, and pre-recorded audio descriptions for video.

Legal requirements vary by jurisdiction. The United States requires compliance under the Americans with Disabilities Act (ADA) Title III for public accommodations and Section 508 of the Rehabilitation Act for federal agencies. The European Union mandates accessibility through the European Accessibility Act (EAA), effective June 28, 2025, applying to websites, mobile apps, and digital services. Canada’s Accessible Canada Act (ACA) and the UK’s Equality Act 2010 impose similar requirements.

Semantic HTML as the Foundation

Semantic HTML is the most important accessibility technique and the foundation upon which all other accessibility practices build. Native HTML elements have built-in roles, states, and keyboard interactions that assistive technologies understand automatically. A <nav> element communicates navigation region. A <button> indicates clickable action with implicit Enter/Space activation. A <form> groups form controls with implicit submission behavior.

Headings create document structure that screen reader users navigate using heading shortcuts. Use a single <h1> per page for the main heading or page title. Nest headings hierarchically (h1 → h2 → h3) without skipping levels — going from h2 to h4 creates gaps that confuse screen reader navigation. Landmark elements — <header>, <main>, <footer>, <aside>, <nav> — provide navigation shortcuts in screen readers and improve keyboard navigation.

Lists semantically group related items. <ul> for unordered lists (features, navigation links), <ol> for ordered lists (step-by-step instructions, rankings), <dl> for definition lists (glossaries, metadata). Table markup includes <caption> for the table title, <thead> and <tbody> for header and data body separation, and <th> with scope attributes (scope="col" for column headers, scope="row" for row headers).

ARIA for Enhanced Semantics

ARIA (Accessible Rich Internet Applications) attributes enhance HTML semantics when native elements aren’t sufficient for the interface being built. The role attribute communicates widget types to assistive technologies — role="tab", role="tabpanel", role="alert", role="dialog", role="progressbar". ARIA states and properties describe current conditions — aria-expanded="true" for open accordions, aria-selected="true" for active tabs, aria-hidden="true" for off-screen content.

The ARIA specification defines strict rules to prevent misuse. The first rule of ARIA: don’t use ARIA if you can use a native HTML element that provides the semantics and behavior you need — use <button> not role="button". The second rule: don’t change native semantics — <h1 role="button"> is incorrect and creates confusion. The third rule: all interactive ARIA widgets must be keyboard accessible with standard keyboard interactions (Tab, Enter, Arrow keys, Escape).

Live regions announce dynamic content changes to screen readers without requiring user focus. aria-live="polite" announces changes when the user is idle, suitable for chat messages and notifications. aria-live="assertive" interrupts current speech for urgent messages like form validation errors. aria-atomic="true" announces the entire region content rather than just changed sections, preventing partial announcements that lack context.

Keyboard Navigation and Focus Management

Every interactive element must be reachable and operable through the keyboard alone. The Tab key navigates forward through focusable elements (links, buttons, form controls). Shift+Tab navigates backward. Enter and Space activate buttons and links. Arrow keys navigate within widgets — tabs switch panels, arrow keys move between menu items, Up/Down adjust slider values. Escape closes dialogs, menus, and popovers.

Visible focus indicators are essential for keyboard users. Never use outline: none without providing an alternative focus style with higher contrast. Custom focus indicators require at least a 3:1 contrast ratio against the background according to WCAG 2.2 Focus Appearance (2.4.11). The focus indicator area should be at least as large as a 2 CSS pixel thick perimeter around the element. Focus rings should be visible in all states — hover, active, and focus combined.

Focus management within components ensures logical navigation. When a dialog opens, focus moves to the dialog container or the first focusable element. When a dialog closes, focus returns to the element that triggered its opening. Tab traps within modals prevent focus from escaping to page content behind the overlay — the last focusable element cycles back to the first, and pressing Escape closes the modal.

Color, Contrast, and Non-Text Information

Color contrast ensures text readability for users with low vision and color vision deficiencies. WCAG AA requires 4.5:1 contrast ratio for normal text (under 18px regular or 14px bold) and 3:1 for large text. WCAG AAA requires 7:1 and 4.5:1 respectively. Large text benefits from lower contrast requirements because the thicker strokes provide adequate differentiation. Tools like WebAIM Contrast Checker, axe DevTools, and the Paciello Group Colour Contrast Analyser verify contrast ratios.

Color must never be the sole method of conveying information. Error states combine color (red) with icons (warning triangle) and text (descriptive error message). Links have underline indicators in addition to color differences — WCAG 2.4.9 Link Purpose requires links to be identifiable by text alone. Charts label data directly or through patterns rather than relying solely on color-coded legends. Status indicators use text and icons alongside color-coded badges.

Non-text content requires text alternatives for screen readers. Images have meaningful alt attributes describing their purpose — “A chart showing quarterly revenue growth from Q1 to Q4 2024” rather than “chart.png”. Decorative images use alt="" to be ignored by screen readers and not announced. Complex images — charts, diagrams, infographics — have detailed descriptions in adjacent text.

Testing with Assistive Technologies

Automated testing catches approximately 30% of accessibility issues according to accessibility experts. Tools like axe DevTools, WAVE, and Google Lighthouse identify missing alt text, insufficient color contrast, missing form labels, and ARIA violations. Integrate automated testing into CI/CD pipelines with axe-core or Pa11y for continuous monitoring that catches regressions before deployment.

Manual testing catches issues automated tools cannot detect. Keyboard-only testing verifies all functionality works with Tab, Enter, Arrow keys, and Escape — if you cannot complete a task with the keyboard alone, it fails WCAG 2.1.1 Keyboard. Screen reader testing with VoiceOver (macOS), NVDA (Windows), and TalkBack (Android) reveals navigation and announcement issues that automated tools miss entirely.

User testing with people who have disabilities provides the most accurate assessment of real-world accessibility. Recruit participants who use assistive technologies — screen readers, screen magnifiers, speech input, and switch devices — in their daily lives. Observing real users navigating your application reveals usability issues no automated or manual checklist can identify.

Web Performance Metrics

Understanding performance metrics helps prioritize optimization efforts. First Contentful Paint (FCP): when the first text or image appears — target under 1.8 seconds. Largest Contentful Paint (LCP): when the main content loads — target under 2.5 seconds. Interaction to Next Paint (INP): responsiveness to user interactions — target under 200 milliseconds. Cumulative Layout Shift (CLS): visual stability — target under 0.1. First Input Delay (FID): time to first interaction — target under 100 milliseconds. Time to First Byte (TTFB): server response time — target under 800 milliseconds. Use Google’s Lighthouse, WebPageTest, and Chrome DevTools to measure these metrics. Real User Monitoring (RUM) captures actual user experiences, which may differ from synthetic tests. Set up dashboards tracking Core Web Vitals and alert when thresholds are breached.

Accessibility Beyond Compliance

Web accessibility ensures your site works for everyone, including people using screen readers, keyboard navigation, or other assistive technologies. WCAG 2.2 guidelines organize requirements into four principles: Perceivable (content must be available to senses), Operable (interface must be usable), Understandable (content and interface must be comprehensible), and Robust (content must work with current and future technologies). Practical steps: use semantic HTML elements (nav, main, aside, article), provide alt text for images, ensure color contrast ratios meet WCAG AA standards (4.5:1 for normal text), support keyboard navigation with visible focus indicators, and test with screen readers (NVDA, VoiceOver, JAWS). Accessibility benefits everyone — captions help users in noisy environments, keyboard navigation helps users with repetitive strain injuries, and high contrast helps users in bright sunlight.

FAQ

What is the difference between WCAG A, AA, and AAA? Level A removes the most critical barriers. Level AA is the legal compliance target for most jurisdictions. Level AAA is the highest standard but may not be achievable for all content. Target AA compliance with AAA improvements where practical.

Do I need to support WCAG 2.2 or 2.1? WCAG 2.2 is backward-compatible with 2.1 and 2.0. Target WCAG 2.2 AA compliance. The new 2.2 criteria include focus appearance (2.4.11), accessible authentication (3.3.8), and draggable operations (2.5.8).

How do I make a single-page application accessible? Manage focus on route changes, announce page navigation to screen readers with live regions, ensure dynamic content has appropriate ARIA landmarks, and maintain keyboard navigation throughout all state changes.

What is the most common accessibility mistake? Missing or incorrect form labels is the most common WCAG failure. Every form input must have an associated label through a visible <label> element with for attribute, aria-label, or aria-labelledby. Placeholder text is not a substitute for labels.

How do I convince stakeholders to invest in accessibility? Accessibility benefits everyone — captions help users in noisy environments, keyboard navigation helps power users, high contrast helps reading in sunlight. Accessibility correlates with better SEO, reduced maintenance costs, and expanded market reach.

For more frontend development techniques, explore our HTML forms guide and web typography guide.