WCAG success criteria beyond color contrast: A holistic approach to accessibility

YYYY-03-Mar 16, 2026 · Jamie Chen

WCAG success criteria beyond color contrast: A holistic approach to accessibility

When I talk to designers about accessibility, I usually hear the same thing: "We checked the contrast ratios, so we're good." Color contrast matters absolutely. But it's like saying a car is safe because it has working brakes. That's one critical system among many.

The Web Content Accessibility Guidelines (WCAG) 2.2 contain 93 success criteria across four principles: perceivable, operable, understandable, and robust. Only a handful address color directly. The rest cover text sizing, motion, keyboard navigation, language clarity, error handling, focus management, and dozens of other dimensions of usability that determine whether your product actually works for everyone.

This is where most teams get stuck. They nail contrast, run an automated audit, and miss the accessibility gaps that actually affect real users every single day.

I want to walk you through the landscape of WCAG beyond color. Not to overwhelm you, but to show you which criteria matter most, why they matter, and how to implement them without turning accessibility into a second job.

Why color contrast alone isn't enough

Let's start with why this conversation matters.

About 253 million people globally experience some form of vision impairment. Of those, fewer than half have color vision deficiency. The rest live with low vision, refractive errors, or complete blindness. They use screen readers, magnification software, keyboard-only navigation, and browser zoom. None of those assistive technologies care about your contrast ratio.

Then there are people with cognitive disabilities, motor impairments, hearing loss, and neurological conditions that affect how they process motion, flashing, rapid color changes, or complex interfaces. These users might not need color adjustments at all — they need stable layouts, predictable navigation, and clear language.

And then there are people with multiple disabilities at once. A user might have both color blindness and low vision. Another might navigate by keyboard and use a screen reader. When you design only for color contrast, you're optimizing for one small slice of the accessibility picture.

The good news: WCAG success criteria are designed to address this entire spectrum. But they require a different mindset than contrast checking does.

The four principles: A framework for thinking about accessibility

WCAG is organized around four foundational principles — acronymized as POUR.

Perceivable means users can see, hear, or otherwise sense your content. This covers contrast, but also text size, captions, alt text, and distinguishing information without relying on color alone.

Operable means users can navigate and interact with your product using whatever input method they have — keyboard, mouse, voice, switch control, or eye-tracking. This includes keyboard navigation, focus management, and avoiding traps that lock users into infinite loops.

Understandable means your content is clear and predictable. This covers language clarity, consistent navigation, error messages that explain what went wrong, and instructions that don't require prior knowledge.

Robust means your code works across browsers, assistive technologies, and assistive technology versions — past, present, and future. This is about semantic HTML, ARIA roles, and not breaking compatibility.

Every WCAG success criterion maps to at least one of these principles. Understanding the framework helps you see why certain criteria matter, not just what they require.

Perceivable: Beyond color contrast

Color contrast is part of perceivable. But it's just the beginning.

Distinguishing information without color alone (WCAG 1.4.1)

This criterion says: if you use color to communicate information, you must also use another visual indicator — shape, text, position, or pattern.

Example: a form field outline that turns red when there's an error. Red alone won't work for users with color blindness. But red plus a clear error icon and error text will. The user perceives the error state whether they see the red or not.

Same principle applies to charts, graphs, maps, and status indicators. If your chart only uses color to distinguish lines, a user with protanopia (red-blindness) won't see the difference between red and green. But if each line also has a different pattern — solid, dashed, dotted — that user now has a path to understand the data.

This doesn't require redesigning. It requires a second thought: "Is there any way someone could misunderstand this if they couldn't see this specific color?" If yes, add a backup.

Text alternatives for images (WCAG 1.1.1)

Every non-decorative image needs alt text. Not for SEO. For users who can't see the image. This includes people using screen readers, people on slow connections, and people whose browser failed to load the image.

Good alt text isn't "image of chart" or "screenshot." It's the content of the image, conveyed in text. For a chart showing quarterly revenue, the alt text should describe what the data shows — not just "bar chart." For a screenshot of an error state, describe what the user is seeing and what it means.

The specificity matters because alt text isn't always visible. A screen reader user has to trust your alt text to make decisions. If your alt text is vague or missing, that user loses access to critical information.

Captions and transcripts for audio and video (WCAG 1.2.1, 1.2.2, 1.2.3)

If you have video, you need captions — synchronized text that captures both dialogue and relevant sound cues (music swells, doors slamming, ambient noise that carries meaning). Not just for deaf and hard-of-hearing users, but for people watching in noisy environments, people in offices without speakers, and people learning English as a second language.

Audio-only content needs transcripts. Podcasts, recorded webinars, background audio — transcripts make that content searchable and accessible to deaf users and users in quiet spaces.

The barrier isn't cost anymore. Automated captioning exists. Human review is still better, but automation gets you 80% of the way there.

Operable: Keyboard navigation and focus management

This is where a lot of interfaces break, especially modern web apps.

Keyboard accessibility (WCAG 2.1.1, 2.1.2)

Every interactive element must be accessible by keyboard. Not mouse-only, not touch-only. Keyboard.

This includes people who are blind or have severe motor impairments. It also includes people with repetitive strain injuries who can't use a mouse, users of adaptive switches, and voice control users (who navigate via keyboard commands).

The implementation is straightforward: semantic HTML (<button>, <a>, <input>) handles this out of the box. If you're building custom buttons in <div> elements, you've already broken keyboard accessibility — and you'll have to bolt it back on with JavaScript and ARIA roles, which is harder and more fragile.

Focus indicators (WCAG 2.4.7)

When a user navigates by keyboard, there must be a visible indicator showing which element has focus. The default browser outline (a blue ring around interactive elements) is often the first thing designers hide with outline: none in CSS. Don't do that.

If you need a custom focus style for visual consistency, replace it with something equally visible — a different color, border width, background color, or shadow. The WCAG criterion doesn't specify what it has to look like, only that it must be there and it must have sufficient contrast.

Users navigating by keyboard rely on focus indicators to know where they are. Without them, they're essentially blind.

Tab order and focus traps (WCAG 2.4.3)

The tab order — the sequence in which elements receive focus as a user presses Tab — should follow a logical, predictable pattern. Usually this means left-to-right, top-to-bottom on the page. If you reorder elements visually with CSS but leave the DOM unchanged, the focus order will feel broken and confusing.

A focus trap is worse: a situation where a user navigates to an element and then can't navigate away using the keyboard. Modal dialogs are common culprits. If your modal doesn't trap focus inside the modal (and prevent focus from going to the background page), a keyboard user will escape it accidentally. If it does trap focus but doesn't have an obvious way to close it or navigate within it, the user is stuck.

Understandable: Language, predictability, and error handling

This principle often gets overlooked because it's "soft" compared to technical criteria. But it's where accessibility meets usability.

Language clarity (WCAG 3.1.3, 3.1.5)

Jargon, unnecessary complexity, and unclear instructions create barriers as real as missing alt text. This is especially true for people with cognitive disabilities, people learning your language, and people under stress.

The criterion is vague by design: "Use clear, simple language." There's no pass/fail test. But the principle is solid. If your error message says "CSRF token validation failed," a user with a cognitive disability (or just a user who's tired) won't know what went wrong or how to fix it. "We couldn't save your changes. Try refreshing the page and try again" is infinitely clearer.

Same with instructions, help text, and UI labels. "Submit" is clear. "Finalize transaction" is less clear. "Save changes to this document?" is clearest.

Consistent navigation (WCAG 3.2.3, 3.2.4)

If the main navigation menu appears at the top on one page and the sidebar on another, a user has to relearn your interface on each page. If buttons behave differently depending on context, users can't build a mental model of how to interact with your product.

Consistency matters most for screen reader users and users with cognitive disabilities, who rely on patterns to navigate efficiently. But it benefits everyone.

Error messages and recovery (WCAG 3.3.1, 3.3.4)

When something goes wrong — a form submission fails, an upload times out, a search returns no results — your error message needs to:

"Error" doesn't do any of that. "Your password must be at least 8 characters long. You entered 7. Try again." does.

For users with cognitive disabilities, unclear error messages can be demoralizing and lead to abandonment. For screen reader users, error messages that are buried in the page or read out of order can be missed entirely.

Robust: Semantic HTML and ARIA

The last principle is about ensuring your code works across browsers and with assistive technologies.

Semantic HTML (WCAG 4.1.1, 4.1.2)

Use <button> for buttons, not <div onclick>. Use <nav> for navigation regions, not <div class="navigation">. Use <form>, <label>, <input>, and <fieldset> for forms. Use heading hierarchy (<h1>, <h2>, etc.) to structure content.

Semantic HTML does three things: it gives meaning to content, it provides assistive technology hooks, and it triggers browser defaults (focus management, keyboard events, etc.) so you don't have to reinvent them.

If you start with semantic HTML, you're 70% of the way to accessibility. If you start with unstyled <div> elements and bolt accessibility on afterward, you're fighting the platform.

ARIA roles and attributes (WCAG 4.1.2, 4.1.3)

ARIA (Accessible Rich Internet Applications) lets you add semantic meaning to non-semantic HTML when you absolutely must use it. aria-label adds a label that screen readers can read. aria-expanded tells screen readers whether a collapsible section is open or closed. aria-live announces dynamic content changes.

ARIA is powerful, but it's a patch. The rule: "No ARIA is better than bad ARIA." If you can use semantic HTML, do that first. If you must use ARIA, use it correctly — getting role names, attribute values, and semantics right requires knowing the spec.

Beyond WCAG 2.2: Emerging considerations

WCAG 2.2 is the current standard, but accessibility isn't static. Here are criteria and considerations that matter now or are coming soon.

Motion and animation (WCAG 2.3.3, prefers-reduced-motion)

Users with vestibular disorders (inner ear issues), photosensitive epilepsy, or motion sensitivity experience nausea, disorientation, or seizures from parallax scrolling, auto-playing animations, or rapidly flashing content.

WCAG 2.2 requires that animations don't flash more than three times per second. It also requires that users can pause auto-playing animations.

But the real solution is respecting the prefers-reduced-motion media query. When a user sets their OS to "reduce motion" (a setting in macOS, iOS, Windows, and Android), your CSS should respect it:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

This doesn't mean no motion ever. It means animations should be minimal and predictable. A button transition from gray to blue on hover is fine. A full-page parallax effect is not.

Cognitive accessibility

WCAG 2.2 touches on this (clear language, error messages, predictability), but doesn't go deep. Cognitive accessibility includes:

For people with ADHD, dyslexia, autism, intellectual disabilities, or acquired brain injuries, these factors often mean the difference between using your product and abandoning it.

Text spacing and legibility (WCAG 1.4.12)

Users with low vision or dyslexia often need to adjust text spacing — line height, letter spacing, word spacing, paragraph spacing. They might use browser extensions or OS settings to customize these values. Your CSS should allow these customizations without breaking layout.

Test by increasing line-height to 1.8, letter-spacing to 0.12em, and word-spacing to 0.16em, and verify that nothing breaks.

How to audit your own product for WCAG compliance

If you're starting from scratch, here's a practical checklist.

Automated testing (catches ~30% of issues):

Manual testing (catches the rest):

Structural review:

Content review:

Common questions about WCAG compliance

Do I need to be Level AAA compliant?

No. WCAG has three levels: A (minimum), AA (the industry standard), and AAA (enhanced). Most legal requirements and accessibility policies reference AA compliance. AAA is nice-to-have but not mandatory. Focus on AA first.

My automated audit passed. Am I done?

Automated tools catch about 30% of accessibility issues — mostly contrast, missing alt text, and structural problems. You'll catch the other 70% with manual testing and real user feedback. An automated pass is a start, not a finish.

Does accessibility add a lot of cost?

Not if you build it in from the start. Retrofitting accessibility to an inaccessible product is expensive and painful. Building accessibility into your design system, component library, and development workflow adds minimal cost and catches issues early.

Can I build an accessible product with a design system?

Absolutely. If your design system components are accessible — buttons have focus states, form inputs are properly labeled, colors have sufficient contrast — then any product built with those components inherits that accessibility. This is the most scalable approach.

Is ARIA a magic fix?

No. ARIA is for marking up custom components when semantic HTML isn't an option. Too much ARIA, incorrectly used ARIA, or ARIA on top of inaccessible HTML will make things worse, not better. Start with semantic HTML.

What happens when you ignore WCAG

This isn't abstract. Here are real consequences:

A financial services company built a trading platform with keyboard navigation disabled. Their users included traders with arthritis and Parkinson's disease who couldn't use a mouse. They had to hire an IT consultant to add keyboard support six months after launch — at 10x the cost of building it in initially.

A SaaS product used color alone to indicate account status (green = active, red = suspended). A customer with red-green color blindness couldn't tell if their account was functional. They switched to a competitor.

A healthcare platform published video training for patients but no captions. Deaf and hard-of-hearing users couldn't access critical information about their treatment options.

These aren't edge cases. They're people trying to do their jobs and manage their lives. WCAG exists because this happens constantly.

Your next step

WCAG compliance isn't a checkbox. It's a commitment to building products that work for humans, not just the average human.

The barrier isn't knowledge anymore — WCAG is public, free, and well-documented. The barrier is prioritization. It's deciding that accessibility matters enough to test for it, design for it, and maintain it.

Start with keyboard navigation. Then add screen reader testing. Then audit your color usage and make sure information isn't conveyed by color alone. Layer in clear language, error messages, and predictable navigation. Respect motion preferences. Let people customize text spacing.

Each step is manageable. Together, they add up to a product that works for everyone.

Before you ship your next feature or design, run your interface through a free color blindness simulator to catch color-only patterns — then take the next step of keyboard testing and screen reader verification.

Related Articles

Test your designs against all four CVD types right now with DeficiencyView's color blindness simulator — upload any image or enter a URL and see results in seconds.