Web accessibility means building your site so that people with disabilities can use it. The standard almost everyone works to is WCAG 2.2 at Level AA, and most of what it asks for is what good engineering asks for anyway: clear structure, enough contrast, full keyboard support and honest labels. Getting it wrong carries legal exposure, and the work overlaps with the structure search engines rely on.

This guide explains what that means in plain language, where the law stands as of October 2026, and the failures worth fixing first.

Why it matters to a business

We are not lawyers, and this is not legal advice. Accessibility law changes, so check the current position with counsel before relying on any of this. As of October 2026:

  • US businesses open to the public. Title III of the Americans with Disabilities Act (ADA) covers places of public accommodation, and plaintiffs and many courts have applied it to websites. Demand letters and lawsuits over inaccessible sites are common, and they usually measure a site against WCAG. Courts have not all agreed on how far the ADA reaches online, which is a reason for caution, not comfort.
  • US state and local government. The Department of Justice’s 2024 rule under Title II of the ADA requires state and local governments to make their websites and mobile apps meet WCAG 2.1 Level AA. An interim final rule in April 2026 moved the compliance dates to April 26, 2027 for governments with a population of 50,000 or more, and April 26, 2028 for smaller ones and for special district governments. ADA.gov summarizes the rule and its current dates. If you build or supply digital services to public bodies, expect these requirements in your contracts.
  • The European Union. The European Accessibility Act sets accessibility requirements for a range of consumer products and services, including ecommerce, through each member state’s national law. If you sell online to consumers in the EU, check how it applies to you.

Meeting WCAG 2.2 AA does not guarantee that nobody will ever send you a demand letter. It does put you in the strongest position to answer one, and it is the right thing to build anyway.

The audience is larger than teams assume

A significant share of people live with a disability that affects how they use the web: vision, hearing, motor or cognitive. Many more have temporary or situational limits, such as a broken wrist or a phone in bright sunlight. An inaccessible site turns these visitors away silently. You never see the loss in analytics, because people who could not use the checkout do not show up as a tracked drop-off.

It overlaps with SEO

Accessible markup is structured markup. Proper headings, descriptive link text, image alt text and semantic HTML help screen readers and search engines for the same reasons. Accessibility is not a ranking shortcut, but the work and the structure overlap heavily.

WCAG in one paragraph

WCAG (the Web Content Accessibility Guidelines) is published by the W3C. WCAG 2.2 became a W3C Recommendation in October 2023 and is the current version; it builds on 2.1, which is the version the US Title II rule references. WCAG is organized around four principles (content must be perceivable, operable, understandable and robust) and three conformance levels: A (the minimum), AA (the level almost everyone targets) and AAA (aspirational, and rarely required in full). When someone says “make the site accessible,” they almost always mean WCAG 2.2 Level AA. Target AA everywhere, and go further where it is cheap to do so.

The failures that matter most

A handful of issues account for most real-world problems. Fix these first.

Color contrast

Body text needs a contrast ratio of at least 4.5:1 against its background. Large text, and the parts of controls and graphics people need to see, need at least 3:1. Pale gray captions, faint placeholder text, and text that is legible in one color theme but not the other are all common failures. Contrast is also the easiest category to verify objectively: you can compute the exact ratio for every text and background pair, which makes it a good place to start an audit.

Text alternatives for images

Every image that conveys information needs descriptive alt text. Purely decorative images should have empty alt text (alt="") so screen readers skip them. Alt text such as “image” or a filename is as good as nothing.

Keyboard operability

Everything that works with a mouse must work with a keyboard alone: navigation, menus, forms, dialogs and custom controls. A visible focus indicator must show where the keyboard is. Many sites trap keyboard users inside a component, or hide the focus outline entirely with a careless outline: none, which strands anyone who cannot use a pointer.

Forms and labels

Every input needs a properly associated label, not a placeholder pretending to be one. Placeholders disappear as soon as the user starts typing and are often too faint to read. Errors must be announced to assistive technology, not just shown in red. Forms are where accessibility failures cost the most directly, because forms are where people buy, book and get in touch.

Headings and structure

Use one <h1> per page, headings that descend in order without skipping levels, and semantic landmarks (header, nav, main, footer). Screen-reader users navigate by heading, so the heading outline is their table of contents.

Motion and animation

Respect the prefers-reduced-motion setting for people who experience nausea or distraction from animation. Anything that moves automatically for more than five seconds, such as a carousel, needs a way to pause it.

What WCAG 2.2 added

If your last audit was against WCAG 2.1, these are the AA and A criteria 2.2 added that most often catch sites out:

  • Focus not obscured: a sticky header, cookie banner or chat widget must not completely hide the element that has keyboard focus.
  • Target size: interactive targets need to be at least 24 by 24 CSS pixels, or spaced so that a 24-pixel circle centered on each one does not overlap another target. Links inside a sentence are among the exceptions.
  • Dragging movements: anything done by dragging, such as a slider or a sortable list, needs a single-pointer alternative like buttons.
  • Accessible authentication: logins must not depend on remembering or transcribing something, so allow paste and password managers.
  • Redundant entry: do not make people retype information they already gave you in the same process.
  • Consistent help: if you offer help such as a contact link or chat, keep it in the same place on every page.

How to approach it without boiling the ocean

Accessibility is not a one-time certificate. Like performance, it is a property of the site that holds only if someone maintains it. A practical sequence:

  1. Audit the current state against WCAG 2.2 AA. Automated tools catch only part of the problem, so pair them with manual keyboard and screen-reader testing.
  2. Fix the high-impact, site-wide issues first: contrast, focus styles, alt text conventions and form labels. These usually live in shared components or design tokens, so one fix can resolve an issue on every page.
  3. Build it in. Make accessible patterns the default in your components and your brand and design system, so new pages start accessible instead of needing remediation later.
  4. Re-test when things change, rather than assuming conformance persists.

Be wary of accessibility overlay widgets that promise instant compliance from a single script. They do not fix the underlying markup, and they can introduce new problems. In 2025 the US Federal Trade Commission finalized an order requiring one overlay vendor to pay $1 million and barring it from claiming its automated product could make any website WCAG-compliant without evidence. Accessibility is built into a site, not bolted on.

The bottom line

WCAG 2.2 AA is achievable, and most of it is good engineering: enough contrast, real labels, keyboard support, sensible structure and respect for user settings. It lowers legal risk, widens your audience and strengthens the structure search engines read. Start with an audit of your shared components, because that is where one fix pays off on every page.