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

2026-03-16 · Jamie Chen

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

When most people think about accessibility, they think about color. And understandably so the color contrast conversation has dominated design conversations for years. But here's what I've learned after auditing hundreds of SaaS interfaces: designers who fixate on contrast ratios while ignoring everything else are building digital experiences that feel accessible on a spreadsheet but fail real users in the field.

The Web Content Accessibility Guidelines (WCAG) include 93 distinct success criteria across three levels: A, AA, and AAA. Exactly five of those directly concern color. The other 88? They're the scaffolding that holds inclusive design together.

This post is about what most accessibility conversations leave out. It's about perception, motor control, cognitive load, and the interconnected web of design decisions that either include or exclude people. I'm going to walk through the WCAG framework beyond color contrast, show you why each piece matters, and give you a practical system for building designs that work for everyone—not just the people with typical vision.

Why color contrast misses half the picture

Let me start with an honest statement: color contrast is necessary but nowhere near sufficient.

A design can pass WCAG AA contrast standards and still be completely inaccessible to people with motor disabilities, cognitive differences, hearing loss, or vestibular disorders. I've seen designs with perfect 7:1 contrast ratios fail users because the interactive elements were 12×12 pixels, required simultaneous multi-key presses, or triggered seizure-inducing motion.

The problem is that accessibility is not a single slider you adjust once and ship. It's a system. Text contrast is one thread in a larger tapestry that includes:

When you design for one dimension only, you optimize for no one. When you design holistically, you build for everyone.

The WCAG framework: what it actually says

WCAG 2.2 (the current standard adopted by most government accessibility regulations, including Section 508 in the US and the European Accessibility Act) is structured around four principles: Perceivable, Operable, Understandable, and Robust (POUR).

Let me break down what each principle demands and why color contrast is just one small piece of the puzzle.

Perceivable: information must be accessible to at least one sensory channel

Perceivable success criteria require that all information be available through at least one sense—not just vision, not just hearing.

Color contrast (WCAG 1.4.3, 1.4.11) is here: text and UI components must have a contrast ratio of at least 4.5:1 for normal text, 3:1 for large text (18pt+), and 3:1 for graphics and UI components (AA level).

But Perceivable goes much further:

Notice the pattern? Perceivable doesn't mean "visible to everyone." It means "accessible through at least one channel."

Operable: users must be able to interact with your interface

This is where the conversation shifts from sensory access to motor control and cognitive tempo.

Keyboard accessibility (2.1.1, 2.1.2) requires that all functionality be operable via keyboard. Not just focusable—actually operable. That means your custom dropdown menu, your image carousel, your drag-and-drop interface must work with Tab, Arrow keys, Enter, and Escape. This is WCAG Level A (the bare minimum).

But there's more:

Operable accessibility is about respect for user agency. It says: I don't know how you interact with the web, so I'm building something that works with your tools, your pace, and your needs.

Understandable: the interface must make cognitive sense

Understandable criteria focus on language clarity, predictability, and error recovery.

Robust: your code must work with assistive technology

Robust is about structure, semantics, and compatibility.

How these criteria interconnect: a real example

Let me show you how WCAG criteria work together by walking through a real interface pattern: a form with validation.

The design: A sign-up form with email, password, and confirmation fields. Required fields are marked with a red asterisk (*).

What goes wrong if you only think about color contrast:

The holistic fix:

One design pattern. Seven WCAG criteria. None of them about color contrast alone.

Building a WCAG-first design system

So how do you operationalize this? How do you move from understanding these principles to actually building accessible interfaces?

Step 1: Establish semantic foundations

Start with HTML. Not design tokens, not spacing systems—HTML semantics.

Semantic HTML is the lowest-cost, highest-impact accessibility investment you can make. It means:

When your HTML is semantic, you get keyboard support, screen reader support, and focus management for free. You're not layering accessibility on top of bad structure—you're building accessibility into the foundation.

Step 2: Establish contrast requirements (but do it right)

Yes, measure contrast. But do it as part of a larger color palette audit, not in isolation.

Create a contrast matrix that shows:

Use a tool like the WCAG contrast checker to verify ratios, then test those same palettes for color blindness accessibility. A 5:1 contrast ratio is useless if the colors look identical in deuteranopia.

Step 3: Define focus management and keyboard patterns

Document exactly how keyboard users will interact with each component type:

Write these patterns down. Test them. Build them consistently. When keyboard behavior is predictable, cognitive load drops and confidence rises.

Step 4: Build in motion restraint

Auto-playing videos, parallax scrolling, infinite scrolls, spinning loaders—these are beautiful and engaging. They're also inaccessible to people with vestibular disorders, certain types of epilepsy, and ADHD.

Implement prefers-reduced-motion media queries:

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

And respect it. A lot of designers see reduced motion as an exception to their design vision. It's not. It's a core audience segment.

Step 5: Plan for content clarity

Before you write microcopy, button labels, form instructions, or error messages, establish a content standard:

This isn't just accessible—it's better design. Clearer language benefits everyone.

Step 6: Test with real assistive technology

Contrast ratio checkers, color blindness simulators, and automated audits are starting points. Real accessibility testing requires:

Tools are cheap. Real user feedback is priceless.

Common WCAG misconceptions that cost you

After 8+ years of audits, I've seen these beliefs derail accessibility work repeatedly.

"If we pass automated testing, we're compliant."

Automated tools catch about 30% of WCAG violations. The remaining 70% require human judgment: Is the heading hierarchy logical? Is the error message clear? Does the keyboard experience make cognitive sense? Automation is a foundation, not a finish line.

"We only need to meet Level AA."

WCAG AA is the industry baseline and is legally required in many contexts (Section 508, ADA). But AA isn't "accessible." It's the minimum accessible. AAA criteria (7:1 contrast, enhanced focus, captions for all audio, plain language) dramatically improve real user experience. If your product serves millions, you can afford AAA.

"Accessibility is a feature we can add later."

Retrofitting accessibility is 5–10x more expensive than building it from the start. If your entire component library uses <div role="button"> instead of <button>, you'll rewrite every component. Build accessibility into the foundation.

"Accessibility is the developer's job."

Accessibility is a product decision, not a developer feature. Designers choose colors, define component sizes, decide whether animations are required or decorative. Developers implement those decisions. If the decision is inaccessible, implementation won't fix it.

Frequently asked questions

Does WCAG 2.2 replace WCAG 2.1?

Yes. WCAG 2.2 is the current standard (released in October 2023). It includes all of WCAG 2.1 plus nine new criteria focused on hidden content, accessible authentication, and accessible names for form fields. If you're currently audited against WCAG 2.1, plan to migrate to 2.2 by end of 2025.

What's the difference between WCAG and Section 508?

Section 508 is a US federal accessibility law. It requires government agencies and federal contractors to comply with WCAG 2.0 (or 2.1 in some cases). WCAG is the standard that Section 508 references. If you work for or with government, you need Section 508 compliance. Most other organizations default to WCAG AA.

Do I need to support all four principles equally?

Not always. Your product's specific users determine priority. If your product is audio-heavy (podcasts, music), invest in Understandable and Operable criteria. If it's visual (data visualization, design software), emphasize Perceivable and Robust. But ignore any principle and you'll exclude entire user groups.

Can I use color as one of the ways to convey information?

Yes. That's the entire point of criterion 1.4.1 (color independence). Use red for error and include text, an icon, or a shape. Use green for success and include a checkmark. Color should reinforce meaning, never be the only way to express it.

What's the difference between ARIA and semantic HTML?

Semantic HTML is preferred. <button> is always better than <div role="button">. ARIA (Accessible Rich Internet Applications) is for situations where semantic HTML can't express your interaction pattern—like a custom menu, a tree view, or a complex drag-and-drop interface. Use semantic HTML first. Use ARIA to fill the gaps.

How do I know if my accessibility effort is working?

Measure it:

The holistic accessibility mindset

Here's what I want to leave you with: accessibility isn't a series of boxes to check. It's a design philosophy that says: I'm building this for humans who interact with the world in different ways—and I'm respecting that.

When you shift from "compliance" to "inclusion," your decision-making changes. You stop asking, "Does this pass WCAG?" and start asking, "Who can't use this, and what can I change?" You stop thinking of accessibility as a tax on development and start seeing it as a feature that makes your product better for everyone.

A form with clear error messages is better for everyone. A video with captions is better for everyone (captions help non-native speakers, people in loud environments, and people who want to mute audio). Keyboard navigation is better for everyone (trackpad users, people with mouse allergies, people on laptops without mice). Readable typography is better for everyone.

That's holistic accessibility. It's not a ramp bolted onto the side of a building. It's a building designed so the front door works for everyone.

Start with semantic HTML. Add keyboard support. Test with real tools and real users. Build motion restraint and readable content. Then measure it. Iterate. That's the system.

And before your next design sprint or accessibility audit, spend 15 minutes reviewing your current interface through multiple WCAG lenses—not just color contrast. You'll see what I've learned: the real accessibility work happens in the places people rarely look.

To test how your designs perform across different color vision types and accessibility standards, try our free WCAG contrast checker and CVD simulator — no account needed, works on any website or image.

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.