What Is WCAG? A Plain English Guide for Business Owners

You've probably seen the acronym WCAG floating around in articles about web accessibility, ADA compliance, or website lawsuits. Maybe your developer mentioned it. Maybe your lawyer did. Either way, you're here because you want to understand what it actually means without wading through pages of technical jargon.

I'm going to break it down for you. No developer background required. By the end of this article, you'll know what WCAG is, why it exists, which level applies to your business, and what you need to do about it.

WCAG in One Paragraph

WCAG stands for Web Content Accessibility Guidelines. It's a set of technical standards that define what it means for a website to be "accessible" to people with disabilities. Think of it like a building code, but for websites. Building codes tell architects how wide a doorway needs to be for wheelchair access. WCAG tells web developers how to build sites that work for people who are blind, deaf, have motor impairments, or have cognitive disabilities. It covers everything from color contrast and text size to keyboard navigation and screen reader compatibility.

That's the quick version. Now let's get into the details.

Who Created WCAG and Why

WCAG was created by the World Wide Web Consortium (W3C), the same international organization that develops the standards behind HTML, CSS, and the other building blocks of the web. Within W3C, there's a group called the Web Accessibility Initiative (WAI) that focuses specifically on making the web usable for people with disabilities.

The first version, WCAG 1.0, came out in 1999. It was a good start, but the web was a very different place back then. WCAG 2.0 arrived in 2008 and was a major overhaul. Instead of focusing on specific technologies (like HTML or Flash), it laid out broad principles that apply to any type of web content. That made it much more future-proof.

WCAG 2.1 was published in 2018, adding guidelines for mobile accessibility, people with low vision, and people with cognitive disabilities. And in October 2023, we got WCAG 2.2, the current version, which adds even more criteria focused on things like dragging interactions and consistent help patterns.

Here's the thing that surprises most business owners: WCAG isn't a law. It's a technical standard. But governments and courts around the world have adopted it as the benchmark for what "accessible" means. When someone sues you for having an inaccessible website, the court looks at WCAG to determine whether your site passes or fails.

The Four Principles Explained Simply

Everything in WCAG flows from four core principles. They go by the acronym POUR, and once you understand them, the rest of the guidelines make a lot more sense.

Perceivable

Users must be able to perceive the information on your site. This sounds obvious, but think about it from the perspective of someone who's blind. They can't see your images, so you need text alternatives (alt text) that describe what each image shows. Someone who's deaf can't hear your video's audio, so you need captions.

The perceivable principle covers text alternatives for images, captions for video and audio, sufficient color contrast between text and background, and the ability to resize text without breaking your layout. If a user can't perceive your content through at least one of their senses, it might as well not exist.

A simple analogy: imagine a restaurant that only posts its menu as a photo on a chalkboard. Someone with low vision can't read it. Perceivable means offering a menu in multiple formats so everyone can get the information.

Operable

Users must be able to operate your site's interface. The biggest requirement here is keyboard accessibility. Not everyone uses a mouse. People with motor impairments might use a keyboard, a switch device, or voice commands to navigate. Every button, link, form field, and interactive element on your site needs to be reachable and usable without a mouse.

Operable also covers things like giving users enough time to read and interact with content (no auto-advancing carousels that move too fast), not using content that flashes more than three times per second (which can trigger seizures), and providing clear ways to navigate and find content on your site.

Think of it like a physical store. If the door handle is too small to grip, or the aisles are too narrow for a wheelchair, the store is there but it isn't operable for some people.

Understandable

Users must be able to understand both the information and how the interface works. This means your text should be readable (not buried in jargon or written at a PhD level when it doesn't need to be). Your site should behave in predictable ways. Navigation should be consistent from page to page. Forms should have clear labels and helpful error messages.

A common violation: a form that says "Error" in red text at the top of the page without telling you which field has the problem or what you need to fix. That's technically visible, but it's not understandable.

Another example: if clicking a link opens a new browser window without any warning, that's a predictability problem. The user expected to stay on the same site, and now they're somewhere else with no way to hit the back button.

Robust

Your content must be robust enough to work reliably across different browsers, devices, and assistive technologies. This is the most technical of the four principles, and it mostly comes down to writing clean, valid HTML that follows web standards.

If your website uses custom-built interactive elements (dropdown menus, modals, tab panels), they need to use proper ARIA attributes so screen readers can understand what they are. A custom dropdown that looks like a dropdown to sighted users but reads as a plain <div> to a screen reader isn't robust.

The good news is that if you're using standard HTML elements (native <button>, <select>, <input>), most of this is handled for you. The problems start when developers build custom components from scratch without adding the proper semantics.

Conformance Levels: A, AA, AAA

WCAG organizes its success criteria into three levels: A, AA, and AAA. Think of them like tiers of compliance, with A being the baseline and AAA being the gold standard.

Level A: The Bare Minimum

Level A criteria represent the absolute minimum for accessibility. If your site fails these, it's likely unusable for many people with disabilities. Examples of Level A requirements:

• All images have text alternatives (alt text)
• All functionality is available from a keyboard
• Content doesn't flash more than three times per second
• Pages have descriptive titles
• Link text makes sense out of context (no "click here" everywhere)

Meeting only Level A would be like building a physical store with a ramp but no handrails, no accessible bathroom, and no signage. You've done the absolute minimum. It's not enough.

Level AA: The Practical Target

Level AA is the standard that matters most for business owners. It's the level that courts, regulators, and accessibility professionals consider reasonable and achievable. When someone says a website should be "WCAG compliant," they almost always mean Level AA.

Level AA includes everything in Level A, plus additional requirements like:

• Color contrast ratios of at least 4.5:1 for normal text and 3:1 for large text
• Text can be resized up to 200% without losing content or functionality
• Multiple ways to find pages on your site (search, sitemap, navigation)
• Consistent navigation across pages
• Form inputs have visible labels and clear error identification
• Captions for all pre-recorded video content

This is the level you should aim for. It's achievable for any website, regardless of budget or complexity. And it's the level referenced in most legal settlements and consent decrees related to web accessibility.

Level AAA: The Gold Standard

Level AAA is the highest level of conformance. It includes requirements like sign language interpretation for all video content, enhanced contrast ratios (7:1), and reading level requirements for text content. W3C itself acknowledges that it's not possible to meet Level AAA for all content on most sites. It's aspirational, not practical for most businesses.

Don't aim for AAA unless you have a specific reason (like a government health information site that serves people with cognitive disabilities). Focus your energy on solid AA conformance instead.

WCAG vs ADA: How They Relate

This is where a lot of business owners get confused. You'll see people use "WCAG compliance" and "ADA compliance" interchangeably, but they're actually different things.

The ADA (Americans with Disabilities Act) is a federal law. It prohibits discrimination against people with disabilities in places of public accommodation. Courts have increasingly ruled that websites count as places of public accommodation, meaning your website needs to be accessible under the ADA.

But the ADA doesn't tell you how to make your website accessible. It doesn't include any technical standards. It just says you can't discriminate.

WCAG fills that gap. It's the technical standard that defines what "accessible" actually means in practice. When the Department of Justice issued its final rule on web accessibility for state and local government websites in 2024, it explicitly adopted WCAG 2.1 Level AA as the standard. And courts across the country have been using WCAG 2.1 AA (and increasingly 2.2 AA) as the benchmark when deciding ADA website cases.

So here's the simple version: the ADA is the law that says you need to be accessible. WCAG is the rulebook that tells you what accessible means. You need both, because the law without the standard is vague, and the standard without the law has no teeth.

For a detailed look at how ADA lawsuits have played out and what they mean for your business, check out our article on ADA website lawsuits and what to expect.

What's New in WCAG 2.2

WCAG 2.2 was published in October 2023, and it's the version you should be targeting. It builds on WCAG 2.1, adding nine new success criteria while removing one (4.1.1 Parsing, which is no longer necessary because modern browsers handle parsing errors gracefully).

The biggest additions in 2.2 focus on:

• Focus appearance: When a user tabs to an interactive element, the focus indicator must be clearly visible with a minimum size and contrast
• Dragging movements: Any action that requires dragging (like reordering a list) must have a non-dragging alternative (like up/down buttons)
• Target size: Interactive elements (buttons, links, form controls) must be at least 24x24 CSS pixels, so people with motor impairments can tap them reliably
• Consistent help: If your site has help mechanisms (contact info, chat, FAQ links), they need to be in the same relative location on every page
• Redundant entry: If a user has already entered information in a process, don't ask them to enter it again (or auto-populate it for them)

We have a detailed breakdown of every change in our WCAG 2.2 vs 2.1 comparison article. It covers each new criterion with practical examples of what they mean for your site.

How to Check If Your Site Meets WCAG

You don't need to read through the entire WCAG specification and manually test every criterion. There are tools that automate the process.

Automated Scanning

The fastest way to start is with an automated accessibility scanner. Our free scanner checks your site against WCAG 2.2 AA standards using axe-core, the same accessibility engine used by major tech companies. You'll get a detailed report showing every issue found, organized by severity (critical, serious, moderate, minor), with specific code snippets and fix recommendations.

Automated tools can catch about 30-40% of WCAG violations. That might sound low, but it covers the most common and impactful problems: missing alt text, insufficient color contrast, empty form labels, broken heading structure, missing page language, and inaccessible interactive elements.

Manual Testing

For a more thorough evaluation, you'll need some manual testing. The two most valuable manual tests are:

Keyboard testing: Put your mouse aside and try to use your entire site with just the keyboard. Can you reach every link, button, and form field? Can you see where the focus is? Can you open and close menus? If you get stuck anywhere, that's a WCAG violation.

Screen reader testing: Turn on VoiceOver (Mac) or download NVDA (Windows, free) and listen to how your site is announced. Do images have descriptions? Are form fields labeled? Do headings make sense when read in sequence? Even ten minutes with a screen reader will reveal problems that no automated tool can catch.

For a full walkthrough on testing methods, our accessibility guide covers both automated and manual approaches step by step.

Do You Legally Need to Comply?

The short answer: yes, practically speaking.

If your business is open to the public in any way, your website almost certainly falls under ADA Title III. This covers restaurants, retail stores, hotels, healthcare providers, professional service firms, e-commerce sites, SaaS products, and pretty much every other type of business with a public-facing website.

The number of ADA website lawsuits has been climbing steadily. In 2023, over 4,600 web accessibility lawsuits were filed in the United States. Plaintiffs' attorneys have built efficient practices around finding inaccessible websites, sending demand letters, and filing suit. Settlement demands typically range from $5,000 to $150,000, depending on the size of the business.

Even if no one sues you, the DOJ has made its position clear. The final rule published in April 2024 explicitly requires state and local government websites to conform to WCAG 2.1 Level AA. While the rule technically only applies to government entities, it signals the direction of enforcement and sets the standard courts reference in private ADA cases.

Beyond the U.S., accessibility laws are tightening worldwide. The European Accessibility Act takes effect in June 2025, requiring accessibility for a broad range of products and services. Canada's Accessible Canada Act and Ontario's AODA also reference WCAG as the standard.

Bottom line: whether or not someone files a lawsuit against your specific business, WCAG AA compliance is the standard the legal system expects. The risk of non-compliance is real and growing. For a practical checklist of what you need to do, see our 2026 ADA compliance checklist.

Getting Started: Your First Steps

If you're starting from zero, here's the order I'd recommend. This isn't the only way to approach it, but it's the path that gets the most impact with the least effort.

Step 1: Get a Baseline

Run a free accessibility scan on your homepage and two or three of your most important pages (your main product/service page, your contact page, and your most-visited blog post). This gives you a clear picture of where you stand and which issues are most pressing.

Step 2: Fix the Critical Issues First

Your scan report will flag issues by severity. Start with the critical and serious ones. These are the issues most likely to block users entirely and most likely to show up in a lawsuit. Common critical issues include:

• Images with no alt text at all
• Form fields with no labels
• Buttons or links with no accessible name
• Interactive elements that can't be reached with a keyboard
• Page has no language attribute

Step 3: Address Color Contrast

Color contrast issues show up on almost every site I scan. The fix is usually straightforward: darken your text or lighten your background until you hit a 4.5:1 ratio. There are free contrast checker tools online where you can plug in your hex codes and see if they pass. For a detailed walkthrough, our color contrast fixing guide covers the most common scenarios.

Step 4: Fix Your Heading Structure

Every page should have exactly one H1 (your page title), and headings should follow a logical order without skipping levels. Don't jump from H2 to H4 because you like the font size of H4. Screen readers use heading structure to build a table of contents for the page, and skipped levels break that experience. Our common WCAG mistakes article covers heading errors in more detail.

Step 5: Test With a Keyboard

Spend ten minutes tabbing through your site. If you find places where focus disappears, elements you can't reach, or interactions that only work with a mouse, those need to be fixed. Keyboard accessibility is one of the four foundational WCAG principles, and it's one of the first things a plaintiff's attorney or an accessibility auditor will check.

Step 6: Make It Ongoing

Accessibility isn't a one-time project. Every time you add new content, install a new plugin, or redesign a page, you can introduce new issues. Build accessibility checks into your workflow. Scan new pages before they go live. Test forms after updates. Treat it the same way you treat security or performance: something you maintain continuously, not something you do once and forget.

Common Questions About WCAG

Is WCAG 2.2 backward compatible with 2.1?

Yes. WCAG 2.2 includes everything in 2.1 and 2.0, plus additional success criteria. If you meet 2.2 AA, you automatically meet 2.1 AA and 2.0 AA as well. The one exception is Success Criterion 4.1.1 (Parsing), which was removed in 2.2 because it's no longer relevant with modern browsers.

Does WCAG apply to mobile apps?

WCAG was written for web content, but its principles apply to mobile apps too. Many of the success criteria (text alternatives, color contrast, touch target size, consistent navigation) translate directly to native apps. The ADA applies to mobile apps regardless, and courts reference WCAG as the standard for mobile accessibility as well.

What about PDFs and documents?

WCAG applies to all web content, including PDFs, Word documents, and other files published on your website. If you post a PDF on your site that isn't accessible (no proper heading structure, no alt text for images, not tagged for screen readers), that's a potential violation. Many ADA lawsuits specifically cite inaccessible PDFs.

Can I use an accessibility overlay widget instead?

No. Overlay widgets (AccessiBe, UserWay, and similar products) add a toolbar to your site that lets users adjust font sizes, contrast, and other settings. They don't fix the underlying HTML issues. They don't add proper alt text, fix form labels, or make interactive elements keyboard accessible. Accessibility advocates widely recommend against them, and some overlays have actually been named as defendants in accessibility lawsuits. There are no shortcuts here. You need to fix the actual code.

How long does it take to become WCAG compliant?

It depends on your site's current state and complexity. A simple five-page business site might take a few hours to bring into compliance. A large e-commerce site with thousands of product pages, dynamic filters, and a custom checkout flow could take weeks or months. The good news is that you don't need to fix everything overnight. Start with the highest-impact issues and improve incrementally.

Do I need to hire an accessibility consultant?

For most small to mid-sized business websites, you can handle the basics yourself. Run a scan, fix the issues it identifies, test with a keyboard, and check your color contrast. If you have a large or complex site, or if you've received a demand letter and need to demonstrate compliance quickly, an accessibility consultant can be worth the investment. They'll do manual testing that automated tools can't replicate and help you build a sustainable accessibility program.

What's the difference between WCAG, Section 508, and ADA?

The ADA is a civil rights law that prohibits disability discrimination. Section 508 is a federal procurement law that requires U.S. government agencies (and contractors working with them) to make their electronic content accessible. WCAG is the technical standard that both reference. Section 508 specifically adopts WCAG 2.0 Level AA. ADA cases reference WCAG 2.1 or 2.2 Level AA as the benchmark. If you're building a website for a federal agency, you need Section 508 compliance. For everyone else, WCAG 2.2 AA under the ADA is what matters.