Web accessibility means building sites that people with disabilities can actually use, including those who navigate with a screen reader, a keyboard instead of a mouse, voice control, or a screen magnifier. It’s the difference between a site that works for everyone and one that quietly locks out a large share of your audience.
Most of the confusion around accessibility comes from the alphabet soup: WCAG, POUR, A, AA, AAA, ADA. This guide explains what those standards actually are, what conformance levels mean, and how to approach accessibility as something you build in rather than bolt on. Where the topic touches law, we’ll point you to authoritative sources rather than pretend to give legal advice.
WCAG: the standard everyone points to
The core standard is the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative. When someone says a site should be “accessible,” they almost always mean it should conform to WCAG. It’s the reference point that most policies, procurement requirements, and design systems build on.
WCAG has evolved over time. WCAG 2.0 was published in 2008, WCAG 2.1 in 2018 (adding criteria for mobile, low vision, and cognitive accessibility), and WCAG 2.2 was published as a W3C Recommendation in October 2023, adding a further set of success criteria. WCAG 2.2 is the current stable version and is backward-compatible: a site that meets 2.2 also meets 2.1 and 2.0. If you’re setting a target today, 2.1 or 2.2 at Level AA is the practical benchmark most organizations aim for.
The four principles: POUR
WCAG is organized around four principles, remembered by the acronym POUR. They’re a genuinely useful mental model even if you never read the spec:
- Perceivable — users must be able to perceive the content. Text alternatives for images, captions for video, and sufficient color contrast all live here.
- Operable — users must be able to operate the interface. Everything works by keyboard, nothing traps focus, and users have enough time to act.
- Understandable — content and operation must be understandable. Predictable navigation, readable text, and clear error messages.
- Robust — content must work with current and future tools, including assistive technologies. This is largely about clean, standard, well-structured code.
Under those four principles sit specific, testable “success criteria.” That structure is why inclusive design isn’t guesswork, and it maps closely to the guidelines for inclusive web design that should shape a project from the start.
Conformance levels: A, AA, and AAA
WCAG defines three levels of conformance, and knowing the difference matters because targets and policies are usually written in terms of them.
- Level A is the minimum. These criteria address the most basic barriers; failing them makes a site unusable for some people entirely.
- Level AA is the level most organizations target and that most policies reference. It covers the barriers that affect the largest range of users, including color-contrast minimums and consistent navigation. When people talk about “meeting WCAG,” they almost always mean AA.
- Level AAA is the highest and strictest. The W3C itself notes that AAA conformance isn’t recommended as a general policy for entire sites because some content can’t meet all AAA criteria. Teams typically apply AAA selectively where it matters most.
For most projects, the sensible goal is WCAG 2.1 or 2.2, Level AA. It’s ambitious enough to remove real barriers and realistic enough to actually achieve and maintain.
Accessibility and the law
This is where teams get anxious, and where you should be careful about who you take advice from. In the United States, web accessibility is frequently discussed in the context of the Americans with Disabilities Act (ADA) and, for federal agencies and their contractors, Section 508 of the Rehabilitation Act. Section 508 standards were updated in 2017 to incorporate WCAG 2.0 Level AA by reference.
The important nuance: WCAG is a technical standard, not a law in itself, but it’s the yardstick that laws, regulations, and settlements repeatedly point to. Requirements differ by country, sector, and the specific rules that apply to your organization, and they change over time. So the honest guidance is this: treat WCAG 2.1/2.2 AA as your engineering target, and consult a qualified professional for the legal obligations that apply to your specific situation. Two solid, non-legal starting points for the standards themselves are the W3C WAI overview of WCAG and the U.S. government’s Section508.gov (both accessed 2026). For a broader look at how this maps to your obligations, our overview of resources for understanding web accessibility laws is a useful next stop.
Where to actually start
You don’t have to memorize every success criterion to make real progress. A handful of fixes address the most common barriers and cover a lot of WCAG at once.
Text alternatives and structure
Give meaningful images descriptive alt text, and use real headings (H1, H2, H3) in a logical order rather than styling text to look like a heading. Screen reader users navigate by headings, so structure is navigation. This connects directly to how you approach website design and services from the ground up.
Keyboard operability
Try navigating your site with only the Tab, Enter, and arrow keys. Can you reach every link, button, and form field? Is the focus indicator visible? Does anything trap you? Keyboard access is foundational, and it’s also the fastest revealing test you can run yourself.
Color and contrast
Ensure text has enough contrast against its background, and never rely on color alone to convey meaning (a red field with no error text is invisible to someone who can’t distinguish it). Contrast is one of the most commonly failed criteria and one of the easiest to fix.
Forms and errors
Label every field properly, associate error messages with the field they describe, and make instructions clear. Accessible forms help everyone, not just assistive-technology users, which is why they overlap so heavily with conversion and usability work.
Testing: tools plus humans
Automated checkers are a good first pass. They’ll catch missing alt text, contrast failures, and structural problems quickly, and there’s a rundown of options in website accessibility testing tools. But automated tools only detect a portion of issues. They can’t tell you whether your alt text is meaningful, whether the tab order makes sense, or whether a screen reader announces things in a way that’s actually usable.
That’s why real testing combines automated scans, manual checks (keyboard navigation, testing with an actual screen reader), and, ideally, feedback from people who rely on assistive technology day to day. Mobile deserves its own pass, too, since touch, screen size, and gestures introduce their own barriers, as covered in best practices for mobile accessibility compliance.
Frequently asked questions
What is the difference between WCAG A, AA, and AAA?
They’re conformance levels. A is the minimum and addresses the most severe barriers, AA covers a broad range of common barriers and is the level most organizations and policies target, and AAA is the strictest. The W3C doesn’t recommend AAA as a blanket requirement for whole sites because some content can’t satisfy every AAA criterion.
Which version of WCAG should I follow?
WCAG 2.2 is the current stable W3C Recommendation (published October 2023) and is backward-compatible with 2.1 and 2.0. Aiming for WCAG 2.1 or 2.2 at Level AA is the practical target for most projects. Check whether any standard specific to your sector or region names a particular version.
Is my site legally required to be accessible?
It depends on where you operate, your sector, and the rules that apply to your organization, and those requirements change over time. WCAG is the technical standard that many laws and settlements point to, but WCAG itself isn’t a statute. For your specific obligations, consult a qualified professional and refer to authoritative government sources rather than general blog posts.
Can I make my site accessible with an overlay or plugin?
Automated overlays and plugins can help with some issues, but they don’t reliably deliver full conformance and can’t fix underlying structural or content problems. Durable accessibility comes from building it into your markup, design, and content, then testing with both tools and real users, not from a single script.