Back to Blog

WCAG Accessibility Compliance: What Every Website Owner Needs to Know

10 min read Nick Ashkar

In 2025, WebAIM tested one million homepages for accessibility failures. 96.3% had detectable WCAG errors. The most common: low-contrast text, missing image alt attributes, and unlabeled form fields — problems that take hours to fix but take years to show up in a lawsuit.

ADA web accessibility lawsuits have risen over 300% since 2018. Courts have consistently ruled that websites are "places of public accommodation" under Title III of the ADA, which means the same obligations that apply to physical storefronts apply online.

But this isn't just about litigation risk. Roughly 1 in 4 adults in the US has a disability. That's customers, clients, and users who can't access your content if your site fails basic accessibility standards.

What WCAG Is (and Who Makes the Rules)

WCAG stands for Web Content Accessibility Guidelines. It's published by the W3C (World Wide Web Consortium) — the same organization that sets HTML and CSS standards. The current version is WCAG 2.2, published in October 2023.

WCAG isn't a law in itself. It's a technical standard that laws reference. The US Department of Justice uses WCAG 2.1 AA as its benchmark for ADA compliance. The EU's Web Accessibility Directive requires WCAG 2.1 AA for public sector sites. Section 508 in the US federal procurement space also references WCAG.

In practice: if you meet WCAG 2.1 AA, you meet the legal standard in most jurisdictions. WCAG 2.2 builds on 2.1 with nine additional criteria, mostly focused on mobile and cognitive accessibility.

The Three Levels: A, AA, and AAA

Level A — The Floor

Level A covers the most critical failures — the ones that make content completely inaccessible to some users. Examples: images without alt text, video without any audio alternative, keyboard traps (where keyboard users can't navigate past an element).

If your site fails Level A, it's likely legally non-compliant and practically unusable for large portions of users with disabilities. This is where most ADA lawsuits originate.

Level AA — The Target

Level AA is what the law requires in most contexts. It includes everything in Level A plus additional requirements: minimum contrast ratios (4.5:1 for body text), visible focus indicators, error identification in forms, consistent navigation, and more.

This is the standard your site should aim for. Meeting WCAG 2.1 AA doesn't eliminate all litigation risk, but it demonstrates a good-faith effort to comply — which courts consider when evaluating damages and settlements.

Level AAA — Beyond the Requirement

Level AAA is the highest level and not required by any major law or regulation. It includes things like sign language alternatives for audio content and enhanced contrast ratios (7:1). The W3C itself notes that Level AAA conformance can't be achieved for entire sites in most cases — it's aspirational.

The Four Principles (POUR)

All WCAG success criteria map back to four core principles. Understanding these makes the guidelines less arbitrary and easier to reason about.

Perceivable

Information and interface components must be presentable to users in ways they can perceive. Content can't be invisible to all of a user's senses.

This covers: alt text for images, captions for video, sufficient color contrast, and not relying on color alone to convey meaning. A red error message that's only red — no icon, no text label — fails Perceivable for colorblind users.

Operable

User interface components and navigation must be operable. Users can't be required to interact in ways they physically can't.

Everything on your site must be keyboard-accessible. Drag-and-drop interfaces with no keyboard alternative fail here. Time limits that users can't pause or extend also fail Operable. Seizure warnings for flashing content fall under this principle too.

Understandable

Information and operation of the UI must be understandable. Users can't be expected to guess what things do.

This covers: readable text at appropriate language levels, predictable navigation (menus that behave consistently), and error messages that tell users what went wrong and how to fix it. "Invalid input" fails Understandable. "Please enter a valid email address (e.g., [email protected])" passes.

Robust

Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This means valid, parseable HTML and proper ARIA roles where needed.

If your site relies on JavaScript that assistive technologies can't read, or uses non-semantic HTML that screen readers misinterpret, it fails Robust. This is often where technically impressive sites fall down — the code looks fine in a browser but breaks with a screen reader.

The Most Common WCAG Failures

WebAIM's 2025 report identified the same six failure categories appearing in over 80% of sites:

  • Low contrast text (83.6% of sites): Body text with less than 4.5:1 contrast ratio against its background. Light gray text on white is the most common offender.
  • Missing alt text (55.4%): Images without descriptive alt attributes. Screen readers skip them or read the filename instead.
  • Missing form labels (48.6%): Input fields without associated <label> elements. Placeholder text doesn't count — it disappears when users start typing.
  • Empty links (44.6%): Links with no descriptive text. "Click here" and icon-only links without accessible labels are the common examples.
  • Missing document language (28.7%): The <html> tag without a lang attribute. Screen readers use this to determine pronunciation.
  • Empty buttons (26.9%): Buttons (often icon-only close or menu buttons) with no accessible name — neither visible text nor an aria-label.

These aren't obscure edge cases. They're the baseline failures that appear on the majority of websites, including professionally designed ones. Most can be fixed in a single day of focused development.

How to Audit Your Site

Automated Tools (Start Here)

Automated accessibility checkers catch roughly 30-40% of WCAG issues. They're fast, free, and essential — but they can't catch everything. Use them as a first pass, not as a final answer.

  • WAVE (wave.webaim.org): Browser extension and web tool. Overlays issues directly on your page with visual indicators. Best for understanding the page context of each failure.
  • Axe DevTools: Browser extension from Deque. More technical detail, integrates with developer workflows. Used by major accessibility-focused teams.
  • Google Lighthouse: Built into Chrome DevTools. Includes an Accessibility score under the audit tab. Identifies common issues and links to remediation guidance.

A good automated audit workflow: run WAVE on your homepage, top landing pages, and any pages with forms or interactive elements. Note every error category. Fix them. Run again.

For WordPress sites, Cirv Guard can monitor your site for accessibility regressions — flagging when new content or plugin updates introduce failures that weren't there before.

Manual Testing (Necessary for Full Coverage)

The 60-70% of issues automated tools miss require manual review. Three methods cover most ground:

  • Keyboard navigation: Unplug your mouse. Tab through every interactive element on the page. Can you reach and activate everything? Is the focus indicator always visible? Does any element trap you?
  • Screen reader testing: Use NVDA (free, Windows) or VoiceOver (built into macOS and iOS). Navigate your key pages and listen to how they're read. Are headings logical? Do images have meaningful descriptions? Do forms make sense?
  • Zoom to 200%: Browser zoom to 200% in a 1280px viewport. No content should overlap, truncate, or require horizontal scrolling. This covers WCAG 1.4.4 (Resize Text).

Quick Wins: What to Fix First

If you're starting from scratch, prioritize these fixes. They have the largest impact, cover the most common failures, and can typically be implemented within a few days.

  1. Fix contrast ratios. Run your color palette through a contrast checker. Body text needs 4.5:1; large text (18px+ or 14px+ bold) needs 3:1. Adjust your CSS variables — this is usually a one-line change per color.
  2. Add alt text to all images. Descriptive text for meaningful images. Empty alt (alt="") for decorative images. Be specific: "Team working in a modern office" is better than "photo."
  3. Label every form field. Use HTML <label for="field-id"> paired with id on the input. Never rely on placeholder text alone.
  4. Add the language attribute. Your <html> tag should include lang="en" (or the appropriate language code). This is a one-line fix.
  5. Add accessible names to icon buttons. Hamburger menus, close buttons, and social icons need aria-label if they have no visible text.
  6. Ensure visible focus styles. Remove outline: none from your CSS unless you've replaced it with a custom focus indicator. Keyboard users need to see where they are.

The Business Case Beyond Legal Risk

The legal risk argument gets the attention, but the business case stands on its own.

The global disability market represents over $1.9 trillion in disposable income (Return on Disability Group, 2024). Accessible sites capture that market. Inaccessible sites explicitly exclude it.

Accessibility improvements correlate with better SEO. Alt text is image SEO. Semantic heading structure is content structure for both screen readers and search crawlers. Faster, simpler page architectures that pass WCAG audits also tend to perform better in Core Web Vitals.

There's also employee and B2B access to consider. If your product, documentation, or client portal isn't accessible, you're cutting off users whose companies have accessibility requirements for vendor tools. For B2B SaaS, enterprise procurement teams increasingly check WCAG compliance as part of vendor evaluation.

What Not to Do: Accessibility Overlays

Accessibility overlay tools — plugins that add a floating widget promising "one-click WCAG compliance" — don't work. They've been explicitly rejected by the National Federation of the Blind and the American Council of the Blind. Over 400 accessibility specialists signed an open letter opposing them.

Multiple lawsuits have been filed against companies using overlays, arguing the widgets don't actually remediate the underlying code failures. Courts have not found them to be a defense.

Fix the underlying HTML and CSS. There's no shortcut that holds up to scrutiny.

Getting Compliant Without Overhauling Your Site

Full WCAG 2.1 AA compliance doesn't require rebuilding from scratch. For most sites, the critical fixes are confined to CSS (contrast, focus styles) and HTML attributes (alt text, labels, lang, aria-label).

A reasonable timeline: two focused sprints. Sprint 1 handles the six most common failures. Sprint 2 covers keyboard navigation, focus management, and error handling in forms.

After that, the work is ongoing maintenance — making sure new content and plugin updates don't reintroduce failures. A monitoring tool that catches regressions early keeps you from falling back to where you started.

Start with a WAVE scan of your homepage. If you see more than 10 errors, work through the quick wins listed above before moving to the more complex issues. Most sites can clear their critical errors within a week of focused effort.