Website Accessibility: WCAG Compliance Guide

The uncomfortable truth

I'll be direct: your website is probably not accessible. 96.3% of home pages have detectable WCAG failures. But here's the thing — fixing accessibility makes your site better for everyone, not just the 15% of people with disabilities.

That statistic comes from the WebAIM Million study, which analyzes the accessibility of the top one million home pages annually. The average page has 56.8 detectable accessibility errors. And "detectable" is the key word — automated tools catch only about 30% of real-world accessibility issues. The actual failure rate is higher.

But this isn't a guilt trip. This is a practical guide. Accessibility work has an outsized return on investment because it improves usability for all users, boosts SEO (there's significant overlap between accessibility and search optimization), and — yes — protects you from increasingly aggressive ADA litigation.

WCAG 2.2: the standard you actually need to meet

WCAG (Web Content Accessibility Guidelines) 2.2 was released in October 2023 and is the current standard. It's organized into three conformance levels:

• Level A: The bare minimum. Covers the most fundamental accessibility requirements. Not meeting Level A means your site is essentially unusable for many people with disabilities.
• Level AA: The practical target. This is what courts reference, what most regulations require, and what provides a genuinely usable experience. Aim here.
• Level AAA: The gold standard. Meeting every AAA criterion is aspirational and not practical for most websites. Aim for it where feasible, but don't make it your primary target.

WCAG 2.2 added 9 new success criteria over WCAG 2.1, with notable additions for focus appearance (visible focus indicators), dragging movements (alternatives to drag-and-drop), and target size minimum (at least 24x24px for interactive elements). If you were meeting WCAG 2.1 AA, the gap to 2.2 AA is manageable.

The legal landscape: who's getting sued

ADA website accessibility lawsuits hit 4,600 in 2025 — a record, and a 12% increase from 2024. The trend has been consistent upward movement since 2018, when the Domino's Pizza ruling established that websites are "places of public accommodation" under ADA Title III.

Who's most at risk:

• E-commerce sites: 77% of all ADA website lawsuits target online retail. If you sell products online, you are a primary target.
• Food service: Restaurants, delivery services, and food brands are the second most targeted category, especially those with online ordering.
• Healthcare: Medical practices, telehealth platforms, and health information sites face both ADA and Section 508 requirements.
• Financial services: Banks, insurance companies, and fintech platforms have strict accessibility obligations under both ADA and state-specific regulations.

The four principles: POUR

Every WCAG criterion falls under one of four principles. Understanding these principles helps you make accessibility decisions even in situations the guidelines don't specifically address.

1. Perceivable

Users must be able to perceive all information and UI components. Content cannot rely on a single sense. If something is visual, it needs a text alternative. If something is audio, it needs captions or a transcript.

2. Operable

All functionality must be operable through multiple input methods. If it works with a mouse, it must also work with a keyboard. Users must have enough time to interact with content. Nothing should cause seizures or physical discomfort.

3. Understandable

Content must be readable and predictable. Navigation should be consistent. Users should be helped to avoid and correct errors. The interface should not behave in unexpected ways.

4. Robust

Content must be compatible with current and future assistive technologies. This means valid, semantic HTML and proper use of ARIA attributes when native HTML is insufficient.

The most common failures (and how to fix each one)

The WebAIM Million study identifies the same failures year after year. The top six account for roughly 80% of all detected issues. Fix these first and you'll eliminate the majority of your accessibility debt.

1. Missing image alt text (58% of pages)

Every meaningful image needs descriptive alt text. Screen readers read the alt attribute to describe images to blind users. Without it, they either skip the image entirely or — worse — read the file name ("IMG_4523.jpg").

• Informative images: Describe what the image conveys. "Bar chart showing 40% increase in mobile traffic from 2024 to 2026" — not "chart" or "image."
• Decorative images: Use an empty alt attribute (alt=""). This tells screen readers to skip the image entirely. Do not omit the alt attribute — that's different from setting it to empty.
• Functional images (links, buttons): Describe the action, not the image. A magnifying glass icon in a search button should have alt="Search", not alt="magnifying glass."
• Complex images (charts, diagrams): Provide a brief alt text plus a longer description nearby, either in a caption or via an expandable details element.

2. Low color contrast (83% of pages)

This is the single most common accessibility failure. 83% of home pages have text that doesn't meet WCAG contrast requirements.

• Normal text (under 18pt or 14pt bold): Minimum contrast ratio of 4.5:1 against its background.
• Large text (18pt+ or 14pt+ bold): Minimum contrast ratio of 3:1.
• UI components and graphical objects: Minimum ratio of 3:1 against adjacent colors. This includes form field borders, icon-only buttons, and chart elements.

The most common offenders: light gray text on white backgrounds (designers love #999 on #fff, which fails at 2.85:1), placeholder text in form fields (typically too light), and text overlaid on images without sufficient contrast overlay.

Use the WebAIM Contrast Checker to verify your color combinations. Better yet, build contrast checking into your design system so every component meets requirements by default.

3. Missing form labels (45% of pages)

Every form input needs a programmatically associated label. Placeholder text is not a label — it disappears when the user starts typing, it typically has insufficient contrast, and screen readers may not reliably announce it.

The fix is simple: use a <label> element with a for attribute matching the input's id. Or wrap the input inside the label element. Both approaches are valid and both create a programmatic association that assistive technologies can use.

For visually hidden labels (when the design doesn't show a visible label), use a CSS visually-hidden class — not display: none or visibility: hidden, which hide the label from screen readers too.

4. No keyboard navigation (34% of pages)

Many users cannot use a mouse. People with motor impairments, blind users navigating with screen readers, and power users who prefer keyboard navigation all rely on keyboard accessibility. If your site isn't fully operable with Tab, Enter, Space, and arrow keys, it's broken for these users.

• Tab order: Interactive elements should be reachable in a logical order via the Tab key. This usually means following the visual reading order (left to right, top to bottom). Don't use positive tabindex values — they create confusing custom tab orders. Use tabindex="0" to make non-interactive elements focusable (when absolutely necessary) and tabindex="-1" to make elements programmatically focusable but not in the tab order.
• Focus indicators: WCAG 2.2 strengthened focus appearance requirements. Focus indicators must have a minimum 2px thick outline with a 3:1 contrast ratio against the unfocused state. The default browser focus ring is acceptable, but if you override it for aesthetics, ensure your custom focus style meets the criteria.
• Skip-to-content links: The very first focusable element on every page should be a "Skip to main content" link. It can be visually hidden until focused. This lets keyboard users bypass repetitive navigation and jump directly to the page content.
• Keyboard traps: Users must never get trapped in a component. Modal dialogs should trap focus within the modal (focus cycling), but pressing Escape should always close the modal and return focus to the element that opened it.

5. Missing skip links (81% of pages)

Skip links are the most impactful accessibility feature you can add in five minutes. Without them, keyboard users must Tab through your entire navigation on every single page load before reaching the content. On a site with 20 navigation links, that's 20 Tab presses before they can read anything.

6. Auto-playing media

Auto-playing video or audio with sound violates WCAG 1.4.2. Beyond compliance, it's hostile UX. If video must autoplay (hero sections, background video), ensure it's muted by default with an easily accessible play/pause button and volume control. Better: use a static image or CSS animation instead, especially on mobile where autoplay behavior is inconsistent.

Screen reader testing: how to actually do it

Most web developers have never used a screen reader. This is like a mobile developer who has never held a phone. You cannot build accessible experiences without understanding how assistive technology users experience your site.

VoiceOver (macOS/iOS)

Built into every Mac and iPhone. Turn it on with Cmd + F5 on Mac. Navigate with VO + Right Arrow (VO = Control + Option) to move through elements. Listen to how your page is announced — are headings properly nested? Are links descriptive? Are images described? Do form fields announce their labels?

NVDA (Windows)

Free, open-source screen reader for Windows. It's the second most popular screen reader after JAWS and is used by approximately 30% of screen reader users. Install it and test your critical user flows — navigation, forms, interactive components.

JAWS (Windows)

The most widely used screen reader, with approximately 40% market share. It's commercial software ($90/year), but offers a 40-minute demo mode for testing. If your organization can afford it, JAWS testing is the gold standard because it's what most screen reader users actually use.

ARIA: when to use it and when NOT to

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that add semantic meaning for assistive technologies. It's powerful and widely misused. The first rule of ARIA is: don't use ARIA. That's not a joke — it's the official W3C guidance.

Native HTML elements have built-in semantics and keyboard behavior. A <button> is focusable, activatable with Enter and Space, and announced as a button by screen readers. A <div role="button"> requires you to manually implement all of that behavior — and most developers get it wrong.

Use ARIA only when:

• No native HTML element exists for the interaction pattern (e.g., tabs, tree views, comboboxes with autocomplete).
• You need to convey dynamic state changes that HTML can't express (e.g., aria-expanded for accordions, aria-live for dynamic content updates).
• You need to create relationships between elements that aren't expressed in the DOM (e.g., aria-labelledby to associate a heading with a section, aria-describedby for supplementary descriptions).

Common ARIA mistakes that make accessibility worse:

• Adding role="button" to a link: Screen reader users expect buttons to activate with Space and links to activate with Enter. Mixing these confuses users. Use a <button> for actions and an <a> for navigation.
• Using aria-label when visible text exists: If a button already has visible text, adding aria-label overrides it for screen reader users, potentially creating a mismatch between what sighted and blind users experience.
• Adding role="presentation" to important elements: This removes the element's semantic meaning from the accessibility tree. Used incorrectly, it makes content invisible to assistive technologies.
• Misusing aria-live: Making too many elements aria-live creates a noisy experience where the screen reader is constantly interrupting the user with updates. Reserve aria-live for genuinely important real-time information (error messages, chat messages, alerts).

Automated testing tools (and their limitations)

Automated accessibility tools are necessary but not sufficient. They catch approximately 30% of WCAG violations. The other 70% require human judgment — context-dependent alt text quality, logical reading order, meaningful link text, and usability of interactive components.

• axe DevTools: The industry standard for automated accessibility testing. Available as a browser extension, CI/CD integration, and API. Zero false positives by design — if axe reports an issue, it's a real issue. Start here.
• Lighthouse accessibility audit: Built into Chrome DevTools. Quick and convenient, but less comprehensive than axe. Good for a quick check, not sufficient for compliance auditing.
• WAVE: A browser extension and web service from WebAIM. Provides visual feedback overlaid on the page, making it easy to see exactly where issues are. Particularly useful for non-technical stakeholders because the results are highly visual.
• Pa11y: A command-line tool for automated accessibility testing. Excellent for CI/CD pipelines and automated regression testing. Can be configured to test multiple pages and report violations programmatically.

The testing strategy: automated tools first, manual testing second, user testing third. Run axe on every page during development. Do manual keyboard and screen reader testing on critical user flows. Then test with actual users who rely on assistive technologies — their feedback will reveal issues no tool or developer can catch.

Forms and interactive elements

Forms are where accessibility failures have the highest business impact because they're conversion points. An inaccessible form doesn't just fail compliance — it directly prevents sales, leads, and signups.

• Group related fields with fieldset and legend. Radio buttons and checkboxes that share a question need to be wrapped in a <fieldset> with a <legend> describing the group. Without this, screen reader users hear individual options without knowing what question they're answering.
• Error messages must be associated with fields. Use aria-describedby to link error messages to their input fields. Also use aria-invalid="true" on fields with errors. Screen readers will announce the error when the user focuses the field.
• Required fields need programmatic indication. Don't rely solely on a red asterisk (color alone is insufficient). Use the required HTML attribute and/or aria-required="true".
• Success and failure states must be announced. After form submission, ensure the result (success message or error summary) is communicated to screen readers, either by moving focus to the message or using an aria-live region.

Video captions and audio descriptions

Video content is legally required to have captions (WCAG 1.2.2 for prerecorded, 1.2.4 for live). Auto-generated captions from YouTube or Zoom are a starting point but have 10-15% error rates that can change meaning. All auto-generated captions must be reviewed and corrected by a human.

• Captions: Text synchronized with audio that includes spoken words, speaker identification, and relevant sound effects. Required for deaf and hard-of-hearing users.
• Audio descriptions: A separate audio track that describes important visual information during pauses in dialogue. Required for blind users when visual content isn't conveyed through dialogue alone (WCAG 1.2.5, Level AA).
• Transcripts: A complete text version of audio and video content. Required for audio-only content (podcasts) and helpful for all multimedia. Transcripts also benefit SEO because search engines can index the text.

The business case: why accessibility drives revenue

Accessibility is typically framed as a cost or a legal obligation. That framing is wrong. Accessible websites perform better by every business metric:

• 15% higher conversion rates. Research from the Click-Away Pound Survey shows that accessible e-commerce sites convert significantly better. The reason is simple: accessible sites are easier to use for everyone, not just users with disabilities. Clear labels, consistent navigation, visible focus states, and readable text help all users complete tasks faster.
• SEO overlap is significant. Alt text helps Google understand images. Semantic heading structure helps Google understand content hierarchy. Descriptive link text helps Google understand page relationships. Video transcripts provide indexable text content. Sites that fix accessibility issues frequently see organic traffic improvements as a side effect.
• Market reach. 15% of the world's population has some form of disability. In the US, people with disabilities control over $490 billion in disposable income. An inaccessible website is an inaccessible market.
• Brand perception. Companies known for accessibility — Apple, Microsoft, BBC — are perceived as more innovative and more caring. In surveys, 71% of consumers prefer to buy from brands that demonstrate social responsibility. Accessibility is a visible, concrete demonstration of inclusive values.

Implementation priority: the fix-it-now checklist

If your site has never been audited for accessibility, start with the high-impact, low-effort fixes. This list is ordered by impact-to-effort ratio:

• Week 1 — Alt text audit: Review every image on your top 20 pages. Add descriptive alt text to meaningful images and empty alt to decorative images. Time: 2-4 hours. Impact: addresses the most common screen reader complaint.
• Week 1 — Color contrast: Run your color palette through a contrast checker. Fix any text/background combination below 4.5:1 for body text or 3:1 for large text. Time: 1-3 hours (design system update). Impact: affects 83% of users who view your site in any suboptimal lighting condition.
• Week 2 — Form labels: Add proper<label> elements to every form field. Add aria-describedby for error messages. Test with VoiceOver. Time: 2-4 hours. Impact: directly affects conversion — unlabeled forms are unusable for screen reader users.
• Week 2 — Skip navigation link: Add a skip-to-content link as the first focusable element on every page. Time: 30 minutes. Impact: transforms the keyboard navigation experience for your entire site.
• Week 3 — Keyboard navigation: Tab through every page. Ensure all interactive elements are reachable, have visible focus indicators, and are operable with keyboard alone. Fix any keyboard traps. Time: 4-8 hours depending on complexity. Impact: makes your site usable for all non-mouse users.
• Week 3 — Document language: Add lang="en" (or appropriate language) to your <html> element. Time: 30 seconds. Impact: screen readers use this to determine pronunciation — without it, they may announce your content in the wrong language.
• Week 4 — Heading structure: Ensure headings are properly nested (H1, then H2s, then H3s under the relevant H2). Don't skip levels. Use only one H1 per page. Screen reader users navigate by heading — broken hierarchy breaks their navigation.

After completing these basics, run axe DevTools on your key pages and address anything it flags. Then do manual screen reader testing on your top 5 user flows. This systematic approach gets you to a reasonable accessibility baseline within a month, without requiring a complete redesign.

The real standard

WCAG compliance is a checklist. Real accessibility is a mindset. The checklist gets you to legal safety and basic usability. The mindset gets you to a product that works for everyone — regardless of how they access it, what device they use, what abilities they have, or what environment they're in.

The best accessible websites don't feel like they were "made accessible." They just feel easy to use. That's because accessibility and usability are not separate disciplines — they're the same discipline applied with different lenses. When you make a button easier to click for someone with motor impairments, you also make it easier for someone using a phone on a moving train. When you make content readable for someone with a cognitive disability, you also make it readable for someone who's tired and distracted.

Start with the checklist. Fix the low-hanging fruit. Run the automated tools. Test with a screen reader. Then, gradually, let the mindset take over — and watch your site become better for everyone who uses it.