The Complete Guide to WCAG: Making the Web Accessible for Everyone

Figure 1: WCAG Touchpoints

Why Web Accessibility Is No Longer Optional

Imagine building a beautiful storefront with a grand staircase at the entrance, but no ramp. It’s probably a lawsuit waiting to happen and is ethically indefensible at best. Yet, this is the reality for millions of websites that fail to accommodate users with disabilities.

The Web Content Accessibility Guidelines (WCAG) exist to change that. Developed by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI), WCAG is the globally recognised standard for making digital content accessible to people with visual, auditory, physical, speech, cognitive, and neurological disabilities.

As of 2024, approximately 1.3 billion people worldwide live with some form of disability. If your website or application isn’t built with accessibility in mind, you’re not just shutting out a significant portion of your audience; you’re potentially violating the law in many jurisdictions, including the Americans with Disabilities Act (ADA) in the US and the European Accessibility Act in the EU.

This guide breaks down everything you need to know about WCAG: what it is, how it’s structured, what each guideline means in practice, and how to implement it effectively.

A Brief History of WCAG

Figure 2: WCAG Timeline

The W3C published the first version of WCAG, WCAG 1.0, in 1999. It was a starting point, but it was largely HTML-centric and quickly showed its age as the web evolved.

WCAG 2.0 arrived in 2008, introducing a framework built around four core principles that apply regardless of the underlying technology, whether HTML, a native mobile app, a PDF, or a kiosk. It remains the baseline requirement in most legal and regulatory contexts today.

WCAG 2.1, published in 2018, extended 2.0 with 17 new success criteria, addressing mobile accessibility, low vision, and cognitive and learning disabilities.

WCAG 2.2, released in October 2023, added 9 new criteria with a focus on cognitive accessibility and removing the now-outdated “Parsing” criterion. It’s the current recommended standard.

WCAG 3.0 is still in development and represents a major structural rethink, but it’s years away from wide adoption.

The Four Core Principles: POUR

Figure 3: WCAG Principles of Accessibility

Every version of WCAG 2.x is organised around four principles, summarised by the acronym POUR. All content must be:

Perceivable. Users must be able to perceive the information being presented. It can’t be invisible to all of their senses.

Operable. Users must be able to operate the interface. It can’t require interactions that the user cannot perform.

Understandable. Users must be able to understand both the information and the interface. It can’t be beyond their comprehension.

Robust. Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. As technologies evolve, content should remain accessible.

These four principles cascade into 13 guidelines, which are then further broken down into testable success criteria.

Conformance Levels: A, AA, and AAA

Each success criterion is assigned one of three conformance levels:

Figure 4: WCAG Conformance Levels

Level A is the minimum level of accessibility. Failing to meet Level A criteria creates barriers that make it impossible for some users to access content at all. These are non-negotiable.

Level AA is the target for most organisations and is what most accessibility laws and policies refer to. Meeting Level AA means your content is accessible to the vast majority of users with disabilities under most circumstances.

Level AAA represents the gold standard. Not all content can satisfy every Level AAA criterion, and the W3C doesn’t recommend it as a blanket target for entire sites. It’s aspirational, applicable where feasible and appropriate.

Most legal requirements, including Section 508 in the US, EN 301 549 in the EU, and various government procurement policies globally, mandate WCAG 2.1 Level AA compliance.

Principle 1: Perceivable

Guideline 1.1: Text Alternatives

Every non-text content item must have a text alternative that serves the equivalent purpose. This allows assistive technologies like screen readers to convey information to users who cannot see images, charts, or icons.

What this means in practice: Every <img> element needs a descriptive alt attribute. Decorative images should have an empty alt="" so screen readers skip them. Complex images like charts need a longer description either in the surrounding text or through a aria-describedby reference. Icons used as buttons need accessible labels.

A good alt text for a product image isn't just "shoe", it's "Nike Air Max 270 in black and white, side view." Context matters.

Key success criteria:

• 1.1.1 Non-text Content (Level A) → Provide text alternatives for all non-text content.

Guideline 1.2: Time-based Media

Audio and video content must have alternatives, e.g., captions, audio descriptions, and transcripts.

What this means in practice: Pre-recorded videos need closed captions for the deaf and hard of hearing. Audio-only content (like podcasts) needs transcripts. Videos with important visual information that isn’t conveyed by the dialogue need audio descriptions, e.g., a narrator describes what’s happening on screen during pauses.

For live audio and video, real-time captions are required at Level AA.

Key success criteria:

• 1.2.1 Audio-only and Video-only → Pre-recorded (Level A)
• 1.2.2 Captions → Pre-recorded (Level A)
• 1.2.3 Audio Description or Media Alternative → Pre-recorded (Level A)
• 1.2.4 Captions → Live (Level AA)
• 1.2.5 Audio Description → Pre-recorded (Level AA)

Guideline 1.3: Adaptable

Create content that can be presented in different ways without losing information or structure. This is about ensuring that the semantic meaning of content survives when its presentation changes.

What this means in practice: Use proper HTML semantics. A heading should be a <h1> through <h6>, not just bold text. A list should be a <ul> or <ol>. Form fields should have associated <label> elements. Tables should use <th> for header cells and scope attributes where appropriate.

If a user turns off CSS, or uses a screen reader, or reads on a narrow mobile screen, the information should still flow logically and meaningfully.

Key success criteria:

• 1.3.1 Info and Relationships (Level A)
• 1.3.2 Meaningful Sequence (Level A)
• 1.3.3 Sensory Characteristics (Level A): Don’t use shape, colour, size, location, or sound as the only way to convey information. (“Click the green button” fails this criterion for colorblind users.)
• 1.3.4 Orientation (Level AA, added in 2.1): Content shouldn’t be locked to portrait or landscape mode.
• 1.3.5 Identify Input Purpose (Level AA, added in 2.1): Use HTML autocomplete attributes for common input fields so browsers and assistive technologies can assist users.

Guideline 1.4: Distinguishable

Make it easier for users to see and hear content by separating foreground from background.

What this means in practice: This is one of the most far-reaching guidelines with several important criteria.

Colour contrast is the big one. The minimum contrast ratio between text and its background is 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold) at Level AA. At Level AAA, these requirements tighten to 7:1 and 4.5:1, respectively. Tools like the WebAIM Contrast Checker make this easy to verify.

Colour alone can’t be used to convey information, think error messages that are only red, or charts that rely solely on colour to distinguish data series. You need secondary cues like icons, patterns, or labels.

Text resizing: Users must be able to resize text up to 200% without loss of content or functionality. This is a core criterion because many users with low vision increase browser font sizes.

Text spacing: Users must be able to override line height, letter spacing, word spacing, and paragraph spacing without breaking content.

Reflow (added in WCAG 2.1): Content should reflow to a single column when zoomed to 400% on a 1280px-wide screen, without requiring horizontal scrolling. This directly benefits low-vision users who zoom significantly.

Key success criteria:

• 1.4.1 Use of Colour (Level A)
• 1.4.2 Audio Control (Level A) → Audio that plays automatically for more than 3 seconds must be pausable or mutable.
• 1.4.3 Contrast (Minimum) (Level AA)
• 1.4.4 Resize Text (Level AA)
• 1.4.5 Images of Text (Level AA) → Use actual text rather than images of text where possible.
• 1.4.10 Reflow (Level AA, added in 2.1)
• 1.4.11 Non-text Contrast (Level AA, added in 2.1) → UI components and graphic elements need at least a 3:1 contrast ratio.
• 1.4.12 Text Spacing (Level AA, added in 2.1)
• 1.4.13 Content on Hover or Focus (Level AA, added in 2.1) → Tooltip-like content that appears on hover must be dismissible, hoverable, and persistent.

Principle 2: Operable

Guideline 2.1: Keyboard Accessible

All functionality must be operable via a keyboard alone.

What this means in practice: Some users can’t use a mouse. They navigate entirely by keyboard using Tab to move forward, Shift+Tab to move backwards, Enter or Space to activate controls, and arrow keys to navigate within components. Every interactive element must be reachable by keyboard and usable without a mouse.

This means no keyboard traps (situations where you can Tab into something but can never Tab out). It means custom widgets like dropdowns, date pickers, and modals must follow established keyboard interaction patterns from the ARIA (Accessible Rich Internet Applications) Authoring Practices Guide.

Key success criteria:

• 2.1.1 Keyboard (Level A)
• 2.1.2 No Keyboard Trap (Level A)
• 2.1.4 Character Key Shortcuts (Level A, added in 2.1) → If single-character keyboard shortcuts are implemented, users must be able to remap or disable them to avoid conflicts with assistive technology.

Guideline 2.2: Enough Time

Give users enough time to read and use content.

What this means in practice: Session timeouts are the most common issue here. If your application will time out a user’s session, you must warn them before it happens and give them the ability to extend or turn off the timeout. For content that auto-updates or scrolls, users must be able to pause, stop, or hide it.

Key success criteria:

• 2.2.1 Timing Adjustable (Level A)
• 2.2.2 Pause, Stop, Hide (Level A)

Guideline 2.3: Seizures and Physical Reactions

Don’t design content in a way that causes seizures or physical reactions.

What this means in practice: Nothing on your page should flash more than three times per second. Rapidly flashing content can trigger photosensitive epileptic seizures in susceptible individuals. This is a life-safety issue.

Key success criteria:

• 2.3.1 Three Flashes or Below Threshold (Level A)

Guideline 2.4: Navigable

Provide ways to help users navigate, find content, and determine where they are.

What this means in practice: This is a rich guideline with many practical implications.

Get Lettie’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Skip navigation links: A “Skip to main content” link at the top of each page lets keyboard users bypass repetitive navigation menus and jump straight to the page’s main content. It should be the first focusable element on the page and can be visually hidden until focused.

Page titles must be meaningful and descriptive. “Page 3” fails. “Checkout” succeeds.

Focus order must be logical and follow the visual reading order of the page.

Link purpose must be determinable from the link text alone, or from the link text plus its surrounding context. “Click here” and “Read more” are accessibility failures. “Read our 2024 annual report” is not.

Breadcrumbs, headings, and multiple means of navigation give users orientation within complex sites.

Focus visible (Level AA in 2.1, Level A in 2.2): Keyboard focus must always be visually visible. If you’ve removed the browser’s default focus outline via CSS (a common but harmful practice), you must replace it with an equivalent or better custom indicator.

Key success criteria:

• 2.4.1 Bypass Blocks (Level A)
• 2.4.2 Page Titled (Level A)
• 2.4.3 Focus Order (Level A)
• 2.4.4 Link Purpose in Context (Level A)
• 2.4.5 Multiple Ways (Level AA)
• 2.4.6 Headings and Labels (Level AA)
• 2.4.7 Focus Visible (Level AA)
• 2.4.11 Focus Not Obscured (Minimum) (Level AA, added in 2.2)
• 2.4.12 Focus Not Obscured (Enhanced) (Level AAA, added in 2.2)

Guideline 2.5: Input Modalities (Added in WCAG 2.1)

Make it easier for users to operate functionality through various inputs beyond keyboard.

What this means in practice: Touch targets must be large enough to tap accurately; the minimum target size is 24x24 CSS pixels at Level AA in WCAG 2.2 (and 44x44px at Level AAA). Drag-and-drop actions need alternative, simpler pointer gestures or keyboard equivalents. Motion-based input (like shaking a device) must have an alternative.

Key success criteria:

• 2.5.1 Pointer Gestures (Level A)
• 2.5.2 Pointer Cancellation (Level A)
• 2.5.3 Label in Name (Level A)
• 2.5.4 Motion Actuation (Level A)
• 2.5.7 Dragging Movements (Level AA, added in 2.2)
• 2.5.8 Target Size (Minimum) (Level AA, added in 2.2)

Principle 3: Understandable

Guideline 3.1: Readable

Make text content readable and understandable.

What this means in practice: The lang attribute on the <html> element is essential; it tells screen readers which language to use for pronunciation. If your page includes passages in another language, use lang attributes on those sections too.

At Level AAA, unusual words should be defined, abbreviations explained, and reading level addressed. While AAA requirements aren’t mandatory, they’re especially valuable for educational, government, and healthcare content.

Key success criteria:

• 3.1.1 Language of Page (Level A)
• 3.1.2 Language of Parts (Level AA)

Guideline 3.2: Predictable

Make web pages appear and operate in predictable ways.

What this means in practice: Changing focus to a form field shouldn’t trigger an automatic form submission. Selecting a checkbox shouldn’t navigate the user to a new page without warning. Repeated navigation components (like headers and footers) must appear in the same relative order throughout a site.

When something does change unexpectedly, like a live region updating, it should be announced by assistive technologies in a controlled, non-disruptive way.

Key success criteria:

• 3.2.1 On Focus (Level A)
• 3.2.2 On Input (Level A)
• 3.2.3 Consistent Navigation (Level AA)
• 3.2.4 Consistent Identification (Level AA)
• 3.2.6 Consistent Help (Level A, added in 2.2) → If help mechanisms exist (chat, phone number, FAQ), they must appear in the same location across pages.

Guideline 3.3: Input Assistance

Help users avoid and correct mistakes.

What this means in practice: Form error messages must be specific and descriptive. “Invalid input” is useless. “Please enter a valid email address in the format name@example.com” is helpful.

Error messages must be programmatically associated with the field they describe, so that screen readers can announce them. Labels and instructions must be provided before the user is expected to fill in a field, not just revealed on error, e.g., rules for creating a password

Key success criteria:

• 3.3.1 Error Identification (Level A)
• 3.3.2 Labels or Instructions (Level A)
• 3.3.3 Error Suggestion (Level AA)
• 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) → For consequential submissions, provide a review step, confirmation, or the ability to undo.
• 3.3.7 Redundant Entry (Level A, added in 2.2) → Don’t ask users to re-enter information they’ve already provided in the same session.
• 3.3.8 Accessible Authentication (Minimum) (Level AA, added in 2.2) → Don’t require cognitive tests (like transcribing distorted text) as the only authentication method. CAPTCHAs that rely solely on visual pattern recognition fail this criterion.

Principle 4: Robust

Guideline 4.1: Compatible

Maximise compatibility with current and future user agents, including assistive technologies.

What this means in practice: Valid, well-formed HTML is the foundation. While browsers are forgiving of malformed markup, screen readers and other assistive technologies often are not. Use proper element nesting, avoid duplicate id attributes, and close all tags.

ARIA roles, states, and properties must accurately describe UI components to assistive technologies. Misusing ARIA, assigning incorrect roles or failing to update aria-expanded states, is often worse than using no ARIA at all. The first rule of ARIA is: don't use ARIA if you can use a native HTML element instead.

Status messages (like “Your form has been submitted” or “3 items added to cart”) must be programmatically determinable without receiving focus, using role="status" or role="alert" as appropriate.

Key success criteria:

• 4.1.1 Parsing (Level A) → Removed in WCAG 2.2, as modern browsers handle this
• 4.1.2 Name, Role, Value (Level A)
• 4.1.3 Status Messages (Level AA, added in 2.1)

Testing for WCAG Compliance

Accessibility testing is most effective when it combines automated tools, manual testing, and user testing with people who have disabilities.

Figure 5: Comparison of WCAG Testing Tools

Automated tools can catch roughly 30–40% of accessibility issues. Popular options include axe by Deque Systems (available as a browser extension and CI/CD integration), Lighthouse in Chrome DevTools, WAVE by WebAIM, and Siteimprove. These tools are fast and excellent for catching obvious errors, but they cannot test context-dependent criteria like whether alt text is actually meaningful or whether error messages are descriptive.

Manual testing bridges the gap. This involves navigating your site using only a keyboard, testing with popular screen reader + browser combinations (NVDA with Firefox, JAWS with Chrome, VoiceOver with Safari on macOS and iOS, TalkBack on Android), checking colour contrast manually, verifying logical heading hierarchy, and reviewing form flow and error handling.

User testing with people who have disabilities is irreplaceable. Automated tools and expert manual review can identify technical violations, but only real users can tell you whether your site actually works for them in practice.

Figure 6: WCAG Tested Aspects

Common Accessibility Failures to Avoid

Missing or inadequate alt text: Empty alt attributes on meaningful images, or meaninglessly vague descriptions like “image” or the file name.

Poor colour contrast: Light grey text on white backgrounds, or low-contrast placeholder text in form fields.

Inaccessible custom components: Dropdowns, modals, carousels, and tab panels built without keyboard support or proper ARIA semantics.

Removed focus indicators: The outline: none CSS rule applied globally to remove focus rings. Always replace them with a visible alternative.

Missing form labels: Placeholder text used as a substitute for a label. Placeholders disappear when the user starts typing and are not reliably announced by all screen readers.

Auto-playing media: Video or audio that starts playing without user initiation, with no way to pause or mute it.

PDF inaccessibility: PDFs are notoriously difficult to make accessible. They should be tagged, reading-ordered, and tested with screen readers. When in doubt, offer an accessible HTML alternative.

Inaccessible third-party content: Embedded widgets, chat tools, marketing overlays, and social media buttons often introduce accessibility issues you didn’t create. You’re still responsible for them.

Building Accessibility Into Your Process

Updating an existing product for accessibility is exponentially more expensive and time-consuming than building it in from the start. The most effective approach is to treat accessibility as a design and development discipline, not a compliance checkbox.

Include accessibility requirements in your design system. Ensure component libraries are accessible by default. Train designers to consider focus states, colour contrast, and touch target sizes from the beginning. Include accessibility in your definition of “done” for each feature. Incorporate automated testing into your CI/CD pipeline so issues are caught before they reach production.

Designate an accessibility champion or team within your organisation. Conduct periodic accessibility audits, quarterly or with each major release. And importantly, create a clear feedback mechanism so users who encounter barriers can report them easily.

WCAG and the Law

In the United States, while WCAG is not explicitly written into law, courts and the Department of Justice have consistently interpreted Title III of the ADA to cover websites and apps. Organizations including Domino’s, Netflix, Harvard, and many others, have faced successful ADA accessibility lawsuits in recent years.

In the European Union, the European Accessibility Act requires that key digital products and services meet EN 301 549 (which incorporates WCAG 2.1 Level AA) by June 2025.

In Canada, the AODA (Accessibility for Ontarians with Disabilities Act) mandates WCAG 2.0 Level AA for public and large private sector websites.

Similar legislation exists or is emerging in the UK, Australia, Japan, Brazil, and elsewhere. Accessibility is rapidly becoming a global legal baseline, not just an ethical aspiration.

Final Thoughts

WCAG is comprehensive, nuanced, and at times technically demanding. But at its heart, it reflects a straightforward commitment: the web should work for everyone.

When you write meaningful alt text, ensure sufficient contrast, build for keyboard navigation, and write descriptive error messages, you’re not just satisfying a checklist. You’re making something that genuinely works better for users with disabilities, users on mobile devices, users in challenging environments, users who are ageing, and often for all users in general.

Accessibility and great user experience are not in tension. They’re the same thing.

Start with the basics: semantic HTML, good contrast, keyboard navigation, and text alternatives. Build from there. Use automated tools to catch regressions. Test with real assistive technologies. Listen to users.

WCAG gives you the roadmap. The destination is a web that works for everyone, and that’s worth building toward.

Resources for further learning:

The W3C’s official WCAG documentation at w3.org/WAI,
WebAIM’s accessibility tutorials at webaim.org,
The Deque University accessibility curriculum, and
The A11y Project community at a11yproject.com.