Web accessibility means building sites that people with visual, auditory, motor, and cognitive disabilities can use. In 2026, it is a legal requirement, a ranking signal, and a mark of sound engineering. An estimated 1.3 billion people worldwide are excluded by inaccessible sites, which also face growing regulatory consequences.
What Is Web Accessibility?
Web accessibility (often shortened to a11y: “a” + 11 letters + “y”) means designing and building sites that people with disabilities can perceive, understand, navigate, and use. Disabilities that can affect web use include:
- Visual – blindness, low vision, color blindness
- Auditory – deafness, hearing impairment
- Motor – limited fine motor control, inability to use a mouse
- Cognitive – dyslexia, ADHD, memory impairment, autism spectrum conditions
- Situational – a broken arm, bright sunlight on a screen, slow internet connection
This last group is easy to overlook. Accessible design can help people in everyday situations, not only those with permanent disabilities: captions are useful in noisy places, strong contrast in bright sunlight, and keyboard controls for people who prefer them.
Why Accessibility Matters in 2026
Legal Requirements
Accessibility requirements have tightened in many parts of the world:
| Region | Legislation | Standard Required |
|---|---|---|
| European Union | European Accessibility Act (EAA) — enforceable June 2025 | WCAG 2.1 AA |
| United States | ADA Title III, Section 508 | WCAG 2.1 AA |
| United Kingdom | Equality Act 2010, Public Sector Bodies Accessibility Regulations | WCAG 2.1 AA |
| Canada | AODA, ACA | WCAG 2.0 AA |
The EU’s European Accessibility Act became enforceable in June 2025. It covers private-sector businesses that offer digital products or services, not only government sites. Non-compliance can lead to fines or litigation.
Accessibility and SEO
Several accessibility practices also help search engines understand pages, including semantic markup and useful labels:
- Alt text on images helps both screen readers and Google Image Search
- Semantic HTML (proper heading structure, landmark elements) helps both assistive technologies and crawlers understand page structure
- Descriptive link text improves both usability and internal linking signals
- Fast load times benefit both users with cognitive disabilities and Core Web Vitals scores
- Clear, readable content satisfies both WCAG readability guidelines and Google’s Helpful Content System
Business Case
Accessible sites also consistently outperform inaccessible ones in several areas:
- Larger addressable audience — 15–20% of the global population has some form of disability
- Lower legal risk from accessibility lawsuits (over 4,600 filed in the US in 2024 alone)
- Improved brand perception and customer loyalty
- Better mobile experience — accessibility improvements disproportionately benefit mobile users
WCAG 2.2 – The Standard
The Web Content Accessibility Guidelines (WCAG), published by the W3C Web Accessibility Initiative (WAI), are an international technical standard for web accessibility. The current stable version is WCAG 2.2, published in October 2023.
Conformance Levels
WCAG sets three levels of conformance:
| Level | Description | Required By |
|---|---|---|
| A | Minimum accessibility — removes the most severe barriers | All regulations |
| AA | Standard accessibility — the legal target in most jurisdictions | EAA, ADA, Section 508 |
| AAA | Maximum accessibility — not required but aspirational | Best practice only |
Many organizations use WCAG 2.2 AA as their conformance target.
The Four POUR Principles
WCAG groups its criteria under four principles:
- Perceivable – Information must be presentable to users in ways they can perceive (e.g. alt text for images, captions for video)
- Operable – Interface components must be operable by all users (e.g. full keyboard navigation, no seizure-inducing content)
- Understandable – Information and UI operation must be understandable (e.g. clear language, predictable navigation)
- Robust – Content must be robust enough to be interpreted by assistive technologies (e.g. valid HTML, correct ARIA usage)
Semantic HTML – The Foundation of Accessibility
One of the most effective steps a developer can take is to use semantic HTML. These elements convey meaning to browsers and assistive technologies.
Use the Right Element for the Job
xml<!-- Bad — div soup with no semantic meaning -->
<div class="button" onclick="submit()">Submit</div>
<div class="header">Page Title</div>
<div class="nav">Menu</div>
<!-- Good — semantic HTML that works out of the box -->
<button type="submit">Submit</button>
<h1>Page Title</h1>
<nav>Menu</nav>
A native <button> can receive keyboard focus, be activated from the keyboard, and be announced correctly by screen readers. A <div> with onclick needs extra code to provide those behaviors.
HTML Landmark Elements
Landmark elements label the main regions of a page so screen reader users can move directly to the section they need:
| Element | Role | Usage |
|---|---|---|
<header> | banner | Site header, logo, primary navigation |
<nav> | navigation | Navigation menus |
<main> | main | Primary page content (one per page) |
<aside> | complementary | Sidebars, related content |
<footer> | contentinfo | Site footer |
<section> | region | Distinct content sections (needs accessible name) |
Heading Hierarchy
Use headings in order (H1 → H2 → H3). Screen reader users often navigate by headings, so do not skip levels or choose a heading only for its visual style.
Keyboard Navigation
Every interactive element must work with a keyboard alone. This is essential for people with motor disabilities and for anyone who prefers keyboard navigation.
Focus Management
- All interactive elements (links, buttons, form fields, modals) must receive keyboard focus
- Focus must be visible — the default browser focus indicator is often removed by CSS resets and never replaced. WCAG 2.2 introduced Success Criterion 2.4.11 (Focus Appearance) requiring a minimum visible focus indicator
- Focus must follow a logical order that matches the visual layout (managed via DOM order and
tabindex)
css/* Never do this without a replacement */
*:focus { outline: none; }
/* Do this instead */
*:focus-visible {
outline: 3px solid #005FCC;
outline-offset: 2px;
}
Keyboard Traps
When a modal or custom dropdown is open, keep keyboard focus inside it. When it closes, return focus to the control that opened it.
Skip Navigation Links
A “Skip to main content” link at the top of the page lets keyboard users bypass repeated navigation. It can remain visually hidden until focused:
xml<a href="#main-content" class="skip-link">Skip to main content</a>
ARIA – Accessible Rich Internet Applications
ARIA (Accessible Rich Internet Applications) adds HTML attributes for meaning that native HTML cannot express, especially in custom controls such as tabs, accordions, sliders, and date pickers.
The First Rule of ARIA
When a native HTML element does the job, use it instead of ARIA.
ARIA adds to HTML; it does not replace it. Prefer a native <button> to <div role="button">.
Essential ARIA Attributes
role– defines what an element is (e.g.role="dialog",role="alert",role="tablist")aria-label– provides an accessible name for elements without visible textaria-labelledby– references another element’s text as the accessible namearia-describedby– references additional descriptive textaria-expanded– indicates whether a collapsible element is open or closedaria-hidden="true"– hides decorative elements from assistive technologiesaria-live– announces dynamic content updates to screen readers
xml<!-- Custom modal with correct ARIA -->
<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
<h2 id="modal-title">Confirm Action</h2>
<p>Are you sure you want to delete this item?</p>
<button>Confirm</button>
<button aria-label="Close dialog">×</button>
</div>
Color and Visual Accessibility
Color Contrast
WCAG 2.2 AA sets minimum contrast ratios for text and its background:
- 4.5:1 for normal text (under 18pt / 14pt bold)
- 3:1 for large text (18pt+ / 14pt+ bold)
- 3:1 for UI components and graphical objects (icons, chart lines, form borders)
Check ratios with tools such as the WebAIM Contrast Checker or Colour Contrast Analyser. Low contrast is common and usually straightforward to correct.
Color as the Only Visual Cue
Do not use color as the only way to convey information. Mark form errors with another cue too, such as an icon, label, pattern, or underline.
xml<!-- Bad — color only -->
<span style="color: red;">Error</span>
<!-- Good — color + icon + text -->
<span style="color: #D32F2F;">
<svg aria-hidden="true"><!-- error icon --></svg>
Error: This field is required
</span>
Motion and Animation
Excessive motion can cause nausea or seizures for people with vestibular disorders. Respect the prefers-reduced-motion setting:
css@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
Forms and Accessible Inputs
Forms are central to many tasks, yet they are a frequent source of accessibility problems.
Labels
Associate each form field with a programmatic <label>:
xml<!-- Bad — no label association -->
<input type="email" placeholder="Email address">
<!-- Good — explicit label association -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">
Placeholder text cannot replace a label. It disappears when someone starts typing and often has insufficient contrast.
Error Messages
- Errors must be described in text — not just highlighted in red
- Error messages must be programmatically associated with their fields via
aria-describedby - Error messages must be specific — “Invalid input” is unhelpful; “Email must include an @ symbol” is actionable
Autocomplete
Use the HTML autocomplete attribute for common fields. It can help people with cognitive or motor impairments complete forms faster:
xml<input type="text" autocomplete="given-name">
<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
Images and Media
Alt Text Best Practices
- Informative images – describe the content and function:
alt="Bar chart showing 40% increase in organic traffic from Q1 to Q2 2026" - Decorative images – use empty alt text to hide from screen readers:
alt="" - Functional images (buttons, links) – describe the action:
alt="Search",alt="Close menu" - Complex images (charts, diagrams) – provide a longer description via
aria-describedbyor a visible caption
Video and Audio
- All video content must have closed captions (auto-generated captions are not sufficient for WCAG compliance — they must be accurate)
- Audio-only content must have a text transcript
- Videos with important visual information must have audio descriptions
- Never use autoplay with audio — it is disorienting and inaccessible
Accessibility Testing Tools
Automated Testing (Catches ~30–40% of Issues)
- axe DevTools (browser extension) – industry-standard accessibility scanner
- Lighthouse (Chrome DevTools) – accessibility audit tab included in every run
- WAVE (WebAIM) – visual accessibility evaluation overlay
- Deque axe-core – integrates into CI/CD pipelines for automated regression testing
Manual Testing (Required for Full Coverage)
- Keyboard-only navigation – unplug the mouse and attempt to use every feature on the page
- Screen reader testing – test with NVDA + Firefox (Windows), JAWS (Windows), VoiceOver (macOS/iOS), TalkBack (Android)
- Zoom testing – test at 200% and 400% browser zoom; content must not overlap or disappear
- Color contrast analyzer – check every text/background combination
Real User Testing
Automated tools cannot replace testing with people with disabilities. Testing with assistive technology users can reveal barriers that scanners and developer checks miss.
WCAG 2.2 New Success Criteria
WCAG 2.2 added criteria to version 2.1 that are especially relevant to modern web applications:
| Criterion | Level | Requirement |
|---|---|---|
| 2.4.11 Focus Appearance | AA | Visible focus indicator must meet minimum size and contrast requirements |
| 2.4.12 Focus Appearance (Enhanced) | AAA | Stricter focus indicator requirements |
| 2.4.13 Focus Appearance | AA | Focus indicator area must be sufficient |
| 2.5.7 Dragging Movements | AA | All drag-and-drop functionality must have a pointer alternative |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets must be at least 24×24 CSS pixels |
| 3.2.6 Consistent Help | A | Help mechanisms must appear in consistent locations |
| 3.3.7 Redundant Entry | A | Users shouldn’t need to re-enter information already provided |
| 3.3.8 Accessible Authentication | AA | No cognitive function test required during login (supports password managers) |
Web Accessibility Audit Checklist
Perceivable
- All images have appropriate alt text (descriptive, empty for decorative)
- Videos have accurate closed captions
- Audio content has text transcripts
- Color contrast meets 4.5:1 for normal text, 3:1 for large text and UI components
- Information is not conveyed by color alone
-
prefers-reduced-motionrespected in CSS animations
Operable
- All functionality accessible via keyboard only
- Visible focus indicator on all interactive elements
- No keyboard traps (except modals, which must trap and return focus correctly)
- Skip navigation link present
- Interactive targets minimum 24×24 CSS pixels
- No content flashes more than 3 times per second
Understandable
- Page language declared (
<html lang="en">) - Form inputs have visible, programmatically associated labels
- Error messages are specific, descriptive, and associated with fields
- Navigation is consistent across pages
- No unexpected context changes on focus or input
Robust
- Valid, well-structured HTML (validate with W3C Validator)
- One
<main>landmark, logical heading hierarchy (one H1) - ARIA used correctly — no invalid roles, no missing required attributes
- Site tested with at least one screen reader
- Automated axe scan passing with zero critical violations
Add axe-core to your CI/CD pipeline so accessibility regressions are caught before release. Finding and fixing them during development costs a fraction of post-launch repairs and helps you keep pace with increasingly strict accessibility regulations.