WCAG compliance guide: Accessibility standards your app must meet

In 2024, over 4,000 ADA web accessibility lawsuits were filed in US federal courts. That's roughly 11 per day. The targets weren't just Fortune 500 companies. Small businesses, SaaS startups, and e-commerce stores all got hit.

The lawsuits follow a pattern. A user with a disability tries to use a website or app. It doesn't work with their screen reader, keyboard, or assistive device. They file a complaint. The company settles for $25,000 to $75,000 - or more if they've been sued before.

The fix for most of these cases is the same standard: WCAG 2.1 Level AA. It's the benchmark that courts, regulators, and accessibility laws point to across the US, EU, Canada, and dozens of other countries. If your app meets it, you're covered. If it doesn't, you're exposed.

Who WCAG applies to

WCAG compliance isn't limited to government websites. The laws that reference it cast a wide net.

ADA (Americans with Disabilities Act): US courts have consistently ruled that websites and apps of businesses open to the public must be accessible. There's no explicit "website" mention in the ADA text, but case law has established the precedent. WCAG 2.1 Level AA is the accepted standard.

Section 508: Applies to all US federal government technology and any technology purchased with federal funds. Requires WCAG 2.0 Level AA (with updates moving toward 2.1).

European Accessibility Act (EAA): Starting June 2025, most digital products and services sold in the EU must meet WCAG 2.1 Level AA. This covers e-commerce, banking, transport, e-books, and more. We've covered this in detail in our European Accessibility Act guide.

Other laws referencing WCAG: Canada's Accessible Canada Act, Australia's Disability Discrimination Act, UK's Equality Act, Japan's JIS X 8341-3, and accessibility laws in over 40 countries all reference WCAG as the benchmark standard.

The practical reality: If your app is used by people, someone with a disability will try to use it. If they can't, you face legal risk in most markets. And beyond compliance: according to the Return on Disability Group's 2024 Global Economics of Disability report, people with disabilities represent over $18 trillion in global spending power. That's a market you're excluding from your product.

WebAIM's 2024 Million Report found that 95.9% of the top 1 million home pages had detectable WCAG 2 failures - an average of 56.8 accessibility errors per page, up 13.6% year over year. The most common violations are also the most fixable: low color contrast, missing alt text, and missing form labels.

The four POUR principles

Every WCAG requirement maps to one of four principles. Learn these, and the 78 individual success criteria make intuitive sense.

The World Health Organization estimates that 1.3 billion people - 16% of the world's population - live with a significant disability. That includes around 253 million with vision impairment, 430 million with disabling hearing loss, and hundreds of millions with physical or cognitive disabilities. Each POUR principle corresponds to a different category of user who would otherwise be locked out of your product.

Perceivable

Users must be able to perceive the information and interface. If they can't see, hear, or otherwise detect content, it doesn't exist for them.

What this means in practice:

• Every image needs alt text that conveys its meaning (not "image.png" or "photo")
• Videos need captions and audio descriptions
• Color can't be the only way to convey information (a red border alone doesn't tell a color-blind user there's an error)
• Text must be resizable up to 200% without losing content or function
• Content must have sufficient color contrast (at least 4.5:1 for normal text, 3:1 for large text)

Operable

Users must be able to operate every control and navigate every element. If a feature requires a mouse and nothing else, keyboard-only users are locked out.

What this means in practice:

• Every interactive element must be reachable and usable via keyboard alone
• No keyboard traps - if a user can tab into a component, they must be able to tab out
• Users get enough time to read and interact (no disappearing content without warning)
• No content that flashes more than three times per second (seizure risk)
• Multiple ways to find content (search, navigation, sitemap)
• Clear and visible focus indicators on all interactive elements

Understandable

Users must be able to understand the content and how the interface works. Confusing labels, unexpected behavior, and jargon all create barriers.

What this means in practice:

• The page language is declared in HTML (so screen readers pronounce words correctly)
• Navigation is consistent across pages
• Form inputs have visible labels (not just placeholder text)
• Error messages identify what went wrong and suggest how to fix it
• No unexpected context changes (auto-submitting forms, opening new windows without warning)

Robust

Content must work reliably across current and future assistive technologies. This comes down to clean, standards-compliant code.

What this means in practice:

• Valid HTML with proper semantic elements (headings, landmarks, lists)
• ARIA attributes used correctly (and only when native HTML isn't enough)
• Custom components expose their name, role, and state to assistive technology
• Status messages are announced to screen readers without stealing focus

The 10 most common WCAG violations (and how to fix them)

WebAIM's annual accessibility analysis of the top 1 million websites consistently finds the same violations. In 2024, low color contrast alone affected 79.9% of home pages - making it the single most common WCAG failure for the eighth consecutive year. Here are the ten that account for the vast majority of failures.

1. Low color contrast

The problem: Text doesn't have enough contrast against its background. Light gray text on a white background is the most common offender.

The requirement: WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px+ or 14px+ bold).

The fix: Run your color palette through a contrast checker. Tools like WebAIM's Contrast Checker or the axe browser extension flag every instance. Update your design system's color tokens once, and the fix cascades across the product.

2. Missing alt text for images

The problem: Images have no alt attribute, or the alt text is meaningless ("image1.jpg," "banner," "photo").

The requirement: Every non-decorative image needs alt text that conveys the same information a sighted user would get from the image.

The fix: Descriptive alt text for informational images. Empty alt attributes (alt="") for purely decorative images. For complex images like charts, a longer description via aria-describedby or a visible caption.

3. Missing form labels

The problem: Form inputs use placeholder text instead of labels, or labels exist visually but aren't programmatically associated with their inputs.

The requirement: Every form input must have a visible label that's programmatically linked to the input via for/id attributes or by wrapping the input in a <label> element.

The fix: Add <label> elements to every input. If the design requires visually hidden labels, use CSS to hide them visually while keeping them available to screen readers. Never rely on placeholder text as the only label - it disappears on focus.

4. Missing link text

The problem: Links with no text content, or links that only say "click here" or "read more" without context.

The requirement: Every link must have descriptive text that tells the user where the link goes, even out of context.

The fix: Replace "click here" with descriptive text ("view our pricing plans"). For icon-only links, add aria-label or visually hidden text.

5. Keyboard navigation failures

The problem: Interactive elements can't be reached or activated via keyboard. Custom dropdowns, modals, and carousels are the usual culprits.

The requirement: Every interactive element must be reachable via Tab key and activatable via Enter or Space. Focus order must follow a logical sequence.

The fix: Use native HTML elements where possible (<button>, <a>, <select>). For custom components, add tabindex, keyboard event handlers, and proper ARIA roles. Test by unplugging your mouse and trying to use the entire interface.

6. Missing document language

The problem: The HTML element doesn't declare the page language.

The requirement: The default language of each page must be declared using the lang attribute on the <html> element.

The fix: Add <html lang="en"> (or the appropriate language code). Takes 30 seconds to fix globally. Without it, screen readers can't pronounce words correctly.

7. Empty buttons

The problem: Buttons with no text content - often icon-only buttons without accessible names.

The requirement: Every button must have an accessible name that describes its function.

The fix: Add text content (visible or visually hidden) or an aria-label attribute. A hamburger menu button needs aria-label="Open navigation menu", not just an SVG icon.

8. Missing skip navigation

The problem: No mechanism to skip repeated content (navigation, headers) and jump straight to the main content.

The requirement: WCAG 2.1 requires a mechanism to bypass blocks of content repeated across pages.

The fix: Add a "Skip to main content" link as the first focusable element on the page. It can be visually hidden until focused. Link it to the <main> element or main content area with an id.

9. Incorrect heading hierarchy

The problem: Heading levels skipped (jumping from <h1> to <h3>), multiple <h1> elements, or headings used for visual styling rather than document structure.

The requirement: Headings must follow a logical hierarchy. Screen reader users navigate by heading level, so skipped levels create confusion.

The fix: Use one <h1> per page. Follow a sequential hierarchy (<h1> then <h2> then <h3>). Don't skip levels. If you need smaller text that isn't a heading, use CSS - not a heading element.

10. Auto-playing media

The problem: Audio or video that plays automatically when the page loads.

The requirement: If media plays automatically for more than 3 seconds, users must be able to pause, stop, or control the volume independently.

The fix: Don't autoplay media with audio. If autoplay is essential for the experience, provide visible controls and respect the user's prefers-reduced-motion setting.

WCAG 2.2: What's New

WCAG 2.2, published October 2023, adds nine new Level A and AA success criteria. The UK Government Digital Service adopted WCAG 2.2 as its accessibility standard in October 2024, replacing WCAG 2.1. The US Access Board is reviewing WCAG 2.2 for inclusion in updated Section 508 rules. Building to 2.2 now means your product is ready for the next wave of legal requirements. The ones that most affect app builders:

Focus Not Obscured (AA): When an element receives keyboard focus, it must be at least partially visible - not hidden behind a sticky header, cookie banner, or chat widget. This catches the common pattern where tabbing through a page puts focus behind a fixed navigation bar.

Dragging Movements (AA): Any feature that requires dragging (drag-and-drop file uploads, reorderable lists, slider controls) must also work with a single pointer click/tap. Users with motor disabilities often can't perform drag gestures.

Target Size (AA): Interactive targets (buttons, links, form controls) must be at least 24x24 CSS pixels. This is smaller than the AAA requirement of 44x44 but larger than what many mobile-first designs use for secondary actions.

Accessible Authentication (AA): Login and authentication flows can't require users to memorize, transcribe, or solve cognitive function tests (like CAPTCHAs) without providing an alternative. Passkeys, email magic links, and password managers satisfy this criterion.

Consistent Help (A): If your app provides help mechanisms (contact info, chat, FAQ links), they must appear in the same relative location across pages.

How accessibility affects your app architecture

Accessibility isn't a coat of paint. It affects fundamental technical decisions.

"We've seen teams spend $60,000 fixing accessibility issues that would have cost $6,000 to build correctly from the start. The component library is where it matters most - if your base components aren't accessible, every screen inherits the problems." - 1Raft Engineering Team

Component library design

Every component in your library should be accessible by default. That means:

• Native HTML elements as the foundation (not <div> with click handlers pretending to be buttons)
• ARIA attributes baked into component APIs, not added as afterthoughts
• Keyboard interaction patterns following WAI-ARIA Authoring Practices
• Focus management built into modals, menus, tabs, and dialog components

If your component library isn't accessible, every page built with it inherits the problems. Fix it at the source.

State management and screen readers

Dynamic content updates (loading states, error messages, live data) need to be announced to screen reader users. This requires:

• ARIA live regions (aria-live="polite" or aria-live="assertive") for content that updates without a page reload
• Status messages that announce changes without moving focus
• Loading indicators that communicate state to assistive technology, not just visual spinners

Routing and single-page apps

SPAs (React, Next.js, Vue) create unique accessibility challenges:

• Client-side navigation doesn't trigger screen reader page announcements by default
• Focus must be managed on route changes (move focus to the main content or a heading)
• The document title must update on navigation
• Browser back/forward button behavior must work correctly

Testing infrastructure

Accessibility testing should be part of your CI/CD pipeline:

• Automated scans (axe-core integrated into unit tests or E2E tests) catch regressions
• Manual testing protocol - a documented checklist for screen reader, keyboard, and zoom testing on every release
• User testing - periodic testing with actual assistive technology users

What accessibility costs

The math is simple. Spending 5-10% more upfront saves 3-5x in remediation costs. And it eliminates the legal risk entirely.

The business case beyond compliance: According to the Return on Disability Group's 2024 Global Economics of Disability report, people with disabilities control over $2.6 trillion in disposable income across North America and Europe alone. Accessible products reach a larger market. They also tend to be better products overall - the constraints of accessibility (clear labels, logical structure, keyboard operability) make interfaces cleaner and easier to use for everyone.

Questions to ask your development partner

1. Do you build to WCAG 2.1 Level AA by default, or is accessibility an add-on? The right answer: it's built into the component library and development process, not a separate workstream.

2. What automated accessibility testing do you run in CI/CD? Look for axe-core integration in unit tests or E2E tests. If they rely only on Lighthouse audits before deployment, that's not enough.

3. How do you handle manual accessibility testing? Ask about their screen reader testing protocol (which screen readers, which browsers, how often), keyboard testing procedures, and whether they work with assistive technology users.

4. Can you show me an accessible component you've built? Have them walk through a complex component (modal, autocomplete, data table) and explain the ARIA attributes, keyboard interactions, and focus management.

5. What's your approach to WCAG 2.2 compliance? This tests whether they're current. If they haven't heard of WCAG 2.2 or its new criteria (Focus Not Obscured, Accessible Authentication, Target Size), they're behind.

6. How do you handle accessibility in design reviews? Accessibility starts in design, not development. Ask whether designers check contrast ratios, target sizes, and focus states before handing off to developers.

Your WCAG compliance checklist

Accessibility isn't a one-time project. It's a continuous practice - like security. Build it into your process, test it every release, and treat violations like bugs that need fixing, not suggestions for "someday."