Web accessibility: what it is, what the law asks, and the ten fixes that matter most

Web accessibility means that people with disabilities can perceive, understand, navigate and use your website: blind visitors with screen readers, people who zoom to 200 %, people who cannot use a mouse, people with colour blindness or cognitive disabilities. The standard that defines it is WCAG 2.2, level AA, and it is what the European Accessibility Act and most US court settlements point to.

This guide is the map of website accessibility for site owners and the people who build for them. It explains what the guidelines ask, what the law requires in the US and the EU, the ten findings that make up most automated results with their fixes, and how to test what a machine cannot. Each topic links to a detailed guide.

Quick answer

• Target WCAG 2.2 level AA. It is the current W3C standard, and meeting it also meets 2.1 AA, which most laws reference.
• Fix the ten common findings first: contrast (4.5:1 for text), alt text, form labels, link and button names, page language, landmarks, zoom, target size, heading order and keyboard access.
• Fix in templates and design tokens, not page by page: two colour changes and one header component often clear dozens of findings.
• Test by hand after the scan. Automated checks find about a third of the barriers; a keyboard pass and a 20-minute screen reader test find much of the rest.
• Don't rely on an overlay widget. It does not make a site conformant, and the US Federal Trade Commission has fined a vendor for claiming it did.
• Run the free accessibility checker on one page per template to see where you stand.

Why web accessibility matters

The World Health Organization estimates that 1.3 billion people, about one in six, live with a significant disability. Add everyone temporarily limited: a bright screen outdoors, a broken arm, a phone in one hand, an older visitor whose eyesight has changed. Accessible sites work for all of them, and the fixes help everyone else too: contrast helps in sunlight, labels help autofill, keyboard access helps power users, and clean structure helps search engines.

Most sites are not there yet. The WebAIM Million 2026 report, which scans the home pages of the top one million sites every year, found detectable WCAG failures on 95.9 % of them, up from 94.8 % in 2025, with an average of about 56 errors per page. The same six problems (low-contrast text, missing alt text, missing form labels, empty links, empty buttons and a missing page language) top the list every year and make up 96 % of all errors detected, which is good news: they are mechanical to fix.

Web accessibility guidelines: WCAG in plain language

WCAG, the Web Content Accessibility Guidelines, is published by the W3C. It sorts its requirements under four principles (perceivable, operable, understandable, robust) into testable success criteria, each at one of three levels. Level A removes the barriers that stop people completely, level AA is the usual legal and contractual target, and level AAA adds stricter criteria that are rarely required for a whole site.

WCAG 2.2, published in October 2023, is the current version and, since October 2025, also the ISO standard ISO/IEC 40500:2025. It keeps every WCAG 2.1 criterion except the obsolete 4.1.1 Parsing and adds nine new ones, such as a 24 × 24 CSS px minimum target size and focus that is not hidden behind sticky headers. Many laws still cite 2.1, but because 2.2 includes it, building to 2.2 AA covers both. WCAG 3 is a working draft that the W3C says is years from finished.

WCAG explained: versions, levels and the checklist that matters covers the four principles with examples, AA versus AAA, the nine 2.2 criteria in plain language, the status of WCAG 3 and a level AA checklist grouped by what you build.

What the law asks

The ADA and websites in the United States

The Americans with Disabilities Act does not name a technical standard for the websites of private businesses. Title III requires "places of public accommodation" to give people with disabilities equal access, and the Department of Justice and most courts apply it to websites, most clearly where a site is linked to a physical store or service; for online-only businesses, courts disagree. Lawsuits are common: Seyfarth Shaw's ADA Title III tracker counted 3,117 website accessibility lawsuits in federal court in 2025, up from 2,452 in 2024, and state courts add more.

The DOJ's 2022 guidance on web accessibility, still published on ADA.gov, points businesses to WCAG. For state and local governments there is a binding rule: the 2024 Title II rule requires WCAG 2.1 AA, and an interim final rule in April 2026 moved its deadlines to 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller ones. Federal agencies follow Section 508.

In practice, an ADA compliant website meets WCAG AA, backed by testing, an accessibility statement and a way for people to report problems. ADA compliant website: what the law asks explains who is covered, the state laws that add damages, the lawsuit numbers and a seven-step plan.

The European Accessibility Act

Since 28 June 2025, the European Accessibility Act (Directive (EU) 2019/882) requires e-commerce, consumer banking, e-books, electronic communications and parts of passenger transport, including their websites and apps, to be accessible to consumers in the EU. Microenterprises providing services (fewer than 10 people and no more than EUR 2 million annual turnover or balance sheet total) are exempt from the service requirements. Compliance is measured against the harmonised standard EN 301 549. The version cited today, v3.2.1, points at WCAG 2.1 AA for web content; v4.1.1, published in September 2026, moves to WCAG 2.2 AA and takes over once the Commission cites it in the Official Journal. Each member state enforces it through its own law and penalties.

European Accessibility Act: what small sites must do explains who is covered, how the exemption works and a 90-day plan for an online shop.

The accessibility statement

EU public-sector sites must publish an accessibility statement, and it is good practice for everyone under the EAA: what standard you target, what does not work yet and how people can reach you. Accessibility statement: what to write has a template and a routine that keeps every claim in it backed by a test.

How to test website accessibility

The checker renders the page in Chromium and runs axe-core (the engine behind most browser accessibility tools) with the WCAG 2.0, 2.1 and 2.2 A and AA rules plus best practices. Violations are grouped by impact (critical, serious, moderate, minor), and getReport's own checks single out the frequent ones with their elements:

An automated pass finds roughly a third of the barriers, the ones a machine can decide from the page's code. Two manual passes cover much of the rest:

• Keyboard. Put the mouse away and press Tab through the page: every control reachable in a sensible order, focus always visible, menus and dialogs usable and escapable.
• Screen reader. Testing your site with a screen reader in 20 minutes gives the keys for VoiceOver and NVDA and a script: headings, landmarks, a form, a dialog, and how the page language changes pronunciation.

Then zoom to 200 % and check that nothing overlaps or disappears.

The ten most common accessibility issues and how to fix them

These ten account for most automated findings on most sites. Each lists the WCAG 2.2 criterion it maps to, so the change can be justified in a ticket.

1. Colour contrast (WCAG 1.4.3)

Grey text on white at #999 is 2.8:1; the minimum is 4.5:1 for normal text and 3:1 for text from 24 px (or about 18.5 px bold) and for icons and control borders. Placeholder text, footer links and muted captions are the usual offenders. Darken the text (#767676 on white is the lightest grey that passes) or lighten the background; logos and disabled controls are exempt. Fix it in the design tokens, and every page follows. Colour contrast: fixing the most common finding covers the ratios, the colours that fail most and theme fixes.

2. Image alt text (WCAG 1.1.1)

A screen reader reads the alt text; without it, it reads the file name. Informative images get a short description of what matters in them, decorative images get alt="" so they are skipped, and images that are links get the link's purpose.

<img src="/img/runner-x.webp" alt="Blue running shoe, side view, white sole">
<img src="/img/divider.svg" alt="">
<a href="/size-chart/"><img src="/img/ruler.svg" alt="Open the size chart"></a>

Alt text: what it is and how to write it gives the five-question decision and worked examples for logos, product photos, icons and charts.

3. Form labels (WCAG 1.3.1, 4.1.2)

Every input needs a visible label connected with for/id, or an aria-label when the design truly has no room. A placeholder disappears when the field is filled and is not a reliable label.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

Accessible forms shows the ways to name a field, error messages and the form-plugin settings.

4. Link and button names (WCAG 2.4.4, 4.1.2)

An icon-only button (the menu, the cart, the search magnifier) has no text, so it needs a name. A link whose text is "Read more" is announced as "link, read more" twenty times on a listing page; add the target in visually hidden text or in the link text itself.

<button type="button" aria-label="Open menu" aria-expanded="false">
  <svg aria-hidden="true">…</svg>
</button>

Accessible names for links and buttons covers cards, icon buttons and the WordPress "read more" filters.

5. Page language (WCAG 3.1.1)

<html lang="hr"> tells screen readers which pronunciation rules to use; without it, Croatian text is read with English rules and is hard to follow. WordPress sets it from Settings → General → Site Language; static sites set it in the layout. The page language fix page has the details, and testing with a screen reader shows how a wrong value sounds and which tags are valid.

6. Landmarks and a skip link (WCAG 1.3.1, 2.4.1)

<header>, <nav>, <main> and <footer> let screen-reader users jump to the content instead of hearing the menu on every page, and a "Skip to main content" link does the same for keyboard users. Use one <main> per page and label multiple <nav> elements. Landmarks and skip links has the markup and the CSS for a skip link that appears on focus.

7. Zoom (WCAG 1.4.4)

maximum-scale=1 or user-scalable=no in the viewport tag stops pinch-zoom on phones, which blocks low-vision users. Remove both; the page still lays out correctly. See the zoom fix page.

8. Target size (WCAG 2.5.8)

WCAG 2.2 AA requires interactive targets of at least 24 × 24 CSS px, with exceptions for inline links in text and targets with enough spacing around them. Icon buttons of 16 px, pagination numbers and social icons are the usual misses; padding fixes them without changing the icon. For comfortable tapping, aim for 44 px. The target size fix page lists the exceptions.

9. Heading order (WCAG 1.3.1, best practice)

Screen-reader users navigate by headings. A jump from H2 to H4 suggests a missing section. Use levels for structure and CSS for size.

10. Keyboard access and focus (WCAG 2.1.1, 2.1.2, 2.4.7)

Everything a mouse can do, a keyboard must do: Tab reaches every control in a sensible order, Enter and Space activate, Esc closes dialogs, and focus is visible (never outline: none without a replacement). Modals that trap focus with no way out, carousels that swallow Tab and custom dropdowns built from <div>s are the classic failures. Native elements (<button>, <a href>, <select>, <dialog>) get keyboard behaviour for free. Keyboard navigation covers focus rings, traps, accessible modals and cookie banners.

Beyond the ten: tables and motion

Two topics come up less often in scans but matter a lot to the people they affect.

Data tables. A screen reader announces each cell with its row and column headers, but only when the table marks them up with <th>, scope and a <caption>. Layout built from tables, or tables built from <div>s, loses that. Accessible tables covers headers, captions, responsive tables and when a table is the wrong element.

Motion. Parallax, zooming transitions and autoplaying animation can cause nausea and dizziness for people with vestibular disorders. The prefers-reduced-motion media query tells you when a visitor has asked their system for less motion; honour it. Motion and prefers-reduced-motion has both CSS strategies and the settings for common animation libraries.

How to make a website accessible, step by step

1. Scan one page per template with the accessibility checker: home, a listing, a detail page, a form, the checkout. The same findings across templates are theme-level.
2. Fix critical and serious first. They block tasks: unlabelled forms, unnamed buttons, missing alt on functional images.
3. Fix contrast in the design tokens and names in the shared components, not per page.
4. Re-run the scan, then do the keyboard pass, the screen reader test and the 200 % zoom check.
5. Write down what is left in an accessibility statement with dates, and add a contact route.
6. Make it part of "done". A new component or page is not finished until it passes the scan and a keyboard pass; otherwise the problems come back with the next redesign.

Platform notes. On WordPress, most findings come from the theme (contrast, landmarks, icon buttons) and page builders (buttons without names, sliders without controls); alt text is set per image in the media library. On Shopify, themes from the theme store pass the basics, while custom sections often lose labels. On static sites, fix the layout and the components once.

Accessibility overlays

An accessibility overlay is a script that adds a toolbar or tries to repair a page automatically in the browser. It can change font size or contrast for the visitor who opens it, but it cannot write meaningful alt text, fix a checkout that traps focus or restructure headings reliably, and many screen-reader users find overlays get in their way. In April 2025 the US Federal Trade Commission finalised an order requiring one overlay vendor to pay $1 million over claims that its product could make any website WCAG-compliant. Spend the budget on fixing the templates instead.

Common mistakes

• aria-label on everything. It overrides visible text and confuses voice-control users who say what they see. Use it only where there is no visible text.
• Alt text that describes the file ("image", "photo1") or repeats the caption.
• Fixing contrast with a text shadow. The ratio is computed on the colours, not the shadow.
• tabindex on non-interactive elements to "make them accessible". It adds tab stops to things that do nothing.
• Treating a clean automated scan as compliance. It is about a third of the work; the rest needs a person.

Questions people ask

What is website accessibility?

Website accessibility means people with disabilities can perceive, understand, navigate and use a site: blind visitors with screen readers, people with low vision who zoom to 200 %, people who cannot use a mouse, people with colour blindness or cognitive disabilities. In practice it means enough contrast, text alternatives for images, labels on forms, full keyboard access, a sensible heading structure and no content that depends on sight or hearing alone.

What are the web accessibility guidelines?

The web accessibility guidelines are WCAG, the Web Content Accessibility Guidelines from the W3C, currently version 2.2. They set out testable success criteria under four principles (perceivable, operable, understandable, robust) at levels A, AA and AAA. Level AA is the target laws and contracts ask for. WCAG explained covers the levels, what 2.2 added and a checklist to work through.

How do I make my website accessible?

Fix the ten common findings in order, then test by hand. Use real HTML elements (buttons, links, labels, headings, landmarks), give every image a suitable alt text, keep text contrast at 4.5:1, make everything work with the keyboard with visible focus, and never disable zoom. Fix colours and components in the theme or design system, not page by page. Then add accessibility to your definition of done so new pages stay accessible.

How do I test website accessibility by hand?

Use three free checks after an automated scan. Put the mouse away and press Tab through the page: every control should be reachable, visibly focused and usable. Zoom the browser to 200 % and check that nothing overlaps or disappears. Then listen to a key journey with a built-in screen reader, VoiceOver on a Mac or iPhone, Narrator on Windows or the free NVDA.

What is digital accessibility?

Digital accessibility is the broader term: websites, apps, documents such as PDFs, emails, kiosks and software that people with disabilities can use. Web accessibility is the part that covers websites and web apps. The same standard sits behind both, WCAG, and laws such as the European Accessibility Act cover websites and apps together, so the fixes in this guide apply to your app's web views as well.

Do accessibility overlays make a website compliant?

No. An overlay widget can let a visitor change text size or contrast, but it cannot write meaningful alt text, fix focus traps or repair a form's structure reliably, so the underlying failures stay. In 2025 the US Federal Trade Commission ordered one overlay vendor to pay $1 million for claiming its product made websites WCAG-compliant. Fix the templates instead and test with real users.

What are the most common accessibility errors?

Low-contrast text, missing alt text, missing form labels, empty links, empty buttons and a missing page language, in that order, according to WebAIM's yearly Million report, which in 2026 found detectable WCAG failures on 95.9 % of home pages. All six usually live in templates, so fixing each once repairs every page built from that template. Run the accessibility checker to see which of them your page has.