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

YYYY-03-Mar 17, 2026 · Jamie Chen

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

I spent last week auditing a SaaS dashboard that passed every color contrast test on the market. The designer had nailed WCAG AA ratios across the entire interface. When I tested it with screen reader users, though, the experience fell apart. Form labels weren't properly associated with inputs. Focus indicators were invisible. Animated alerts disappeared before users could read them.

This is the trap that catches most teams: treating color contrast as the whole accessibility story.

WCAG compliance is not a checkbox game where you optimize for contrast ratios and call it done. The Web Content Accessibility Guidelines cover 50 different success criteria across 13 principles. Color contrast is one of them important, yes, but genuinely optional if you design without relying on color at all. Meanwhile, the criteria that actually break the experience for millions of users get overlooked.

In this guide, I'm walking through WCAG beyond color contrast: the success criteria that matter for motor accessibility, cognitive load, attention spans, and screen reader navigation. I'll show you where teams drop the ball, how to test for it, and what it actually looks like to build something accessible from the ground up.

Understanding the WCAG framework: more than just contrast

WCAG 2.2 is organized into four principles: perceivable, operable, understandable, robust (POUR for short).

Perceivable means users can perceive the information through at least one sense—sight, hearing, or touch. Yes, color contrast lives here. But so do:

Operable means users can actually navigate and use the interface. This includes:

Understandable means the language, structure, and behavior are clear:

Robust means the code works across assistive technologies:

Color contrast addresses perceivable 1.4.3 (AA) and 1.4.11 (enhanced contrast). Important. But operability, understandability, and robustness failures will lock out far more users than a poorly contrasted button will.

The operability gap: why keyboard navigation still gets ignored

I audited a fintech platform last month. Beautiful interface, perfect contrast ratios, smooth animations. I pulled up my keyboard—no Tab focus, no Skip Link, no way to navigate to the main content without using a mouse. The submit button wasn't keyboard-accessible. Three of the nine interactive elements on the page couldn't be reached with keyboard alone.

WCAG 2.1.1 (AA) requires all functionality to be available via keyboard. This isn't a nice-to-have for power users. It's table stakes.

Roughly 8% of people who use keyboards exclusively aren't "disabled" in the way most designers picture it. That includes:

When you build for keyboard, you also get voice control almost free. Voice control software uses your keyboard implementation to navigate.

Testing keyboard accessibility

Open any website you're building. Put the mouse down. Literally move it off your desk if you have to. Use only:

Can you reach every form field? Can you submit the form? Can you close a modal? Can you skip past repetitive navigation to get to the main content?

If any of those fail, you've violated WCAG 2.1.1.

The fix usually involves:

  1. Skip links: A hidden link at the very top that jumps directly to main content, visible when focused via keyboard.
<a href="#main-content" class="skip-link">Skip to main content</a>

<style>
  .skip-link {
    position: absolute;
    top: -40px;
    left: 0;
    background: #000;
    color: #fff;
    padding: 8px;
    text-decoration: none;
    z-index: 100;
  }

  .skip-link:focus {
    top: 0;
  }
</style>
  1. Focus indicators: Never remove the default outline with outline: none; unless you replace it with something more visible. Custom focus styles should have a 3:1 contrast ratio and be at least 2px wide (WCAG 2.4.7).
button:focus-visible {
  outline: 3px solid #0066ff;
  outline-offset: 2px;
}

  1. Semantic HTML: Use <button> for buttons, <a> for links, <label> for form labels. Don't build a button out of a <div>.

  2. ARIA when semantic HTML isn't possible: If you must use a <div> as a button (you shouldn't, but if you must), add role="button" and tabindex="0" and implement keyboard handlers for Enter and Space.

Managing cognitive load and attention span

Here's something that doesn't get enough attention in accessibility discussions: people with ADHD, dyslexia, dyscalculia, and autism navigate the web differently than the "typical user." They're affected by:

Animation and motion: understanding prefers-reduced-motion

Autistic users, users with vestibular disorders, and users prone to migraines often report that animation, parallax scrolling, and autoplay videos cause physical discomfort, dizziness, or nausea. This isn't hyperbole—it's a documented physiological response.

WCAG 2.3.3 (AAA) requires you to respect prefers-reduced-motion. Most users don't set this preference unless they have a real reason. When they do, you should:

  1. Remove or significantly reduce animation
  2. Disable autoplay
  3. Pause carousels by default
  4. Remove parallax effects
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

This isn't about making the interface boring. It's about respecting that some people's brains literally cannot process the motion without distress.

Text complexity and readability

WCAG 3.1.5 (AAA, optional) recommends reducing text to no lower than lower-secondary education level. That's roughly 8th-grade reading level in US terms. But even at AA level, you can make a massive difference:

A fintech app I tested used "aggregate transaction reconciliation" when they meant "add up all your transactions." That one phrase locked out users with cognitive disabilities, ESL users, and people in a hurry.

Sensory accessibility beyond vision

Color vision deficiency is just one sensory accessibility issue. There are others that WCAG addresses that most teams ignore.

Captions and audio descriptions

WCAG 1.2.2 (AA) requires captions for all pre-recorded audio and video content. Not a nice-to-have. Not "if budget allows." Required for AA compliance.

Same with audio descriptions for video content (1.2.3 AA, 1.2.5 AAA). A Deaf user can read captions. But a Blind user needs to know what's happening on screen via a separate audio track or transcript.

If your product has video—demo videos, tutorials, training content, testimonials—and you haven't added captions, you're in violation of WCAG AA and probably cutting off 5–10% of your potential user base.

Color as a secondary indicator

Even though color contrast gets all the attention, WCAG 1.4.1 (A) actually says: "Color is not used as the only means of conveying information." That means you need a non-color indicator as well.

Example of a violation:

Example of compliance:

Users with any form of color vision deficiency—and people looking at phones in bright sunlight, or using grayscale mode, or watching on an old CRT monitor—need to understand your interface without relying on color alone.

Information structure and semantic HTML

This is where WCAG 1.3.1 (perceivable, structure and relationships) separates amateur accessibility work from professional work.

When you use semantic HTML—<h1>, <h2>, <nav>, <main>, <button>, <label>—screen readers build a model of your page structure. Users can navigate by heading levels. They know what's a button and what's a link. Form fields are properly associated with their labels.

When you use a bunch of styled <div> elements, screen reader users get:

I've audited sites with entire navigation bars marked up as <div> tags. Users on screen readers had to wade through 40+ items with no structure.

Semantic HTML checklist

This is the foundation. Everything else builds on it.

Time and interactions: giving users breathing room

WCAG 2.2.1 (A) covers timing: "For each time limit... at least one of the following is true: the user is allowed to turn off the time limit... extend the time limit... or turn off auto-updating content."

Translated: don't force users into time-dependent interactions unless absolutely necessary.

This affects:

I audited a medical system where forms timed out after 10 minutes. A user with motor disabilities took 15 minutes to complete it because they had to switch input methods between fields. They lost all their data when the form timed out.

WCAG 2.2.1 would have required either a warning, an extension mechanism, or no timeout at all.

Testing for WCAG compliance beyond color contrast

A free WCAG contrast checker tells you about one success criterion. True WCAG compliance requires testing across multiple domains.

Automated testing gets you 30% of the way there

Tools like Axe DevTools, WAVE, and Lighthouse catch:

These are quick wins and you should fix them first. But they miss:

Manual testing is where the real insights happen

Get on a keyboard. Use a screen reader (NVDA on Windows, VoiceOver on Mac). Test with prefers-reduced-motion enabled. Have an actual user with motor disabilities or a screen reader dependency test your product. Nothing replaces that.

FAQ: WCAG holistic accessibility

What's the difference between WCAG AA and AAA? AA is the legal standard in most countries and is considered "good accessibility." AAA is stricter and used for government and medical sites. Start with AA; AAA is a bonus. Contrast ratios are stricter at AAA (7:1 vs 4.5:1), and some features like audio descriptions are AAA-only.

Can color contrast be "good enough" if everything else is accessible? No. Color contrast is the floor, not the ceiling. WCAG 1.4.3 is mandatory at AA level. But if you skip keyboard navigation or semantic HTML, your site is not WCAG AA compliant—period. All criteria matter equally.

How do I get keyboard navigation working on a custom component? Use semantic HTML first (<button>, <select>, <input>). If you must build custom, use tabindex="0" to make it focusable, handle keyboard events (Enter, Space, Arrow keys), and style the :focus-visible state clearly. Test with a keyboard only—no mouse.

Does accessibility affect performance? No, and often it improves it. Semantic HTML is less markup to parse. Respecting prefers-reduced-motion reduces animation rendering. Smaller alt text descriptions reduce file size. Accessibility and performance are usually aligned.

Who actually uses these features? Hundreds of millions of people globally. Roughly 1 in 7 adults have some form of disability (physical, sensory, or cognitive). But also temporary users: someone with a broken arm, someone in bright sunlight who can't see the screen, someone on a slow internet connection. You're not building for "disabled people." You're building for humans.

The bigger picture: accessibility as good design

I started this post talking about a dashboard that nailed color contrast but failed screen reader users. The inverse is also true: I've seen sites with poor contrast but excellent keyboard navigation because the designer started with structure first and styled later.

The difference between an accessible product and an inaccessible one isn't compliance checklist completion. It's whether you asked "Can this person navigate?" in the design phase, not the audit phase.

WCAG gives you the criteria. Color contrast, keyboard navigation, semantic HTML, captions, motion preferences—these are the tools. But the mindset is: Can someone with a different body, different senses, or different cognitive processing use this product? And if the answer is "I don't know," that's the moment to test.

When you take WCAG holistically—not as a contrast ratio game, but as a framework for perceivable, operable, understandable, robust design—you stop thinking of accessibility as a feature. You start thinking of it as the baseline.

Related Articles

Test your contrast ratios and keyboard accessibility in one place with our WCAG contrast checker and CVD simulator—no signup required.

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.