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 I sit down with design teams, color contrast almost always dominates the accessibility conversation. It's understandable contrast is visible, measurable, and feels like a clear pass or fail. But here's what I've learned after auditing hundreds of interfaces: teams that fixate on contrast alone while ignoring the other 48+ WCAG success criteria end up shipping products that fail real users in equally painful ways.

A user with protanopia might breeze through your 7:1 contrast ratio, only to get trapped in a keyboard navigation loop they can't escape. Someone using a screen reader might see your perfectly contrasted buttons labeled "submit," "submit," and "submit" with no way to distinguish them. A person with vestibular disorders might collapse on the floor because your auto-playing video with motion effects triggered vertigo.

WCAG 2.2 is not a color-contrast standard wearing a lot of hats. It's a framework for building products that work for humans with different bodies, brains, and ways of interacting with technology. In this guide, I'll walk through the major categories of success criteria, explain what they actually protect against, and show you how to think about accessibility as a system rather than a checklist.

Understanding the WCAG framework

WCAG stands for Web Content Accessibility Guidelines, published by the World Wide Web Consortium (W3C). The standard is organized into four principles known by the acronym POUR:

Under these four principles sit 13 guidelines, and under those guidelines sit the 50+ success criteria. Each criterion has a conformance level: A (minimum), AA (widely expected standard), or AAA (enhanced accessibility). Most organizations target AA compliance as a baseline.

The critical insight: color contrast belongs to the Perceivable principle, but Perceivable is only one-quarter of the framework. Ignoring Operable, Understandable, or Robust creates gaps that affect different users—sometimes more severely than poor contrast.

Let me break down what matters beyond color.

Perceivable criteria: beyond contrast alone

Yes, color contrast is here. But Perceivable covers much more.

WCAG 1.4.3: Contrast (minimum) is what most teams know—text must hit a 4.5:1 ratio for normal text, 3:1 for large text, against its background. This protects users with low vision and color vision deficiency when combined with other non-color cues.

But Perceivable also includes:

1.4.5: Images of text — If you're using images or screenshots to convey information (like embedding text inside a graphic), you must provide an actual text alternative. I see this constantly in onboarding flows where teams screenshot their interface and call it a day. That image is invisible to screen readers and unsearchable. If the text is purely decorative, fine. If it communicates something, convert it to actual HTML text.

1.4.11: Non-text contrast — This is newer (added in WCAG 2.1) and catches teams off guard. Your UI components, icons, and graphical elements need a 3:1 contrast ratio against adjacent colors. A light gray icon on white? Fails. A barely-visible form field border? Fails. This goes beyond color: it's about visual distinction. The good news is that when you nail this, you help users with low vision, astigmatism, and older age-related vision changes—not just CVD.

1.4.13: Content on hover — When a user hovers over an element and additional content appears (tooltips, menus, popovers), that content must remain visible until the user dismisses it, moves to a different control, or leaves the interaction. This seems obvious, but flaky hover states that disappear on their own strand users with tremors or mobility challenges who might need extra time to read the revealed content.

1.1: Text alternatives — Every image, icon, and piece of visual information needs a text alternative. This is where many teams stumble. Alt text is not a box to check; it's a moment to ask: "What is this image communicating? What would I say if I were describing this to someone who couldn't see it?" For decorative images, leave alt text empty (alt=""). For charts, provide a data table or summary. For logos, name the company. For CVD users specifically, alt text + non-color indicators together ensure information isn't lost.

Operable criteria: the second-generation accessibility barrier

Operable is where keyboard navigation, focus management, and input flexibility live. It's also where I find the most egregious failures in otherwise "modern" products.

2.1.1: Keyboard — Every function available via mouse must also be available via keyboard. This means: all buttons, links, and form inputs must be reachable with Tab and Shift+Tab. All interactions must be triggerable with Enter, Space, or arrow keys. No mouse-only tooltips. No drag-and-drop without a keyboard alternative.

I watched a design system that was pixel-perfect on contrast fail a keyboard-only audit miserably. A carousel component had visible focus indicators (great!) but the Tab order jumped backward through the slide thumbnails, then forward through the slide title, then backward through the navigation arrows. A keyboard user would spend two minutes tabbing through a six-slide carousel. That's not usable; that's hostile.

2.4.3: Focus order — The sequence in which elements receive focus via keyboard must follow a logical, intuitive order. Usually, that's left-to-right, top-to-bottom. Avoid CSS tricks that visually reorder elements without updating the DOM order—screen reader users and keyboard users follow the code order, not the visual order.

2.4.7: Focus visible — Users must always know which element has keyboard focus. This means a visible indicator: an outline, a border, a background color change—something with at least a 3:1 contrast ratio against the background. Removing the browser's default focus ring (via outline: none) without providing a replacement is an instant accessibility failure. I've seen it in 40% of the design systems I audit.

/* Bad */
button:focus {
  outline: none; /* You've hidden focus. Users can't see where they are. */
}

/* Good */
button:focus-visible {
  outline: 3px solid #0066cc; /* Clear, visible indicator */
  outline-offset: 2px;
}

2.5.1: Pointer gestures — If your interface requires swiping, pinching, or multi-finger gestures, you must provide a keyboard or single-pointer alternative. Carousel swiping? Offer Previous/Next buttons. Pinch-to-zoom? Offer a zoom button or let the browser handle it. This protects users with motor disabilities, arthritis, and anyone using voice control or switch access.

2.5.4: Motion actuation — If shaking or tilting a device triggers an action (like undo via device motion), there must be a UI control alternative. Most web apps don't hit this, but mobile-first designs can stumble here.

2.3.3: Animation from interactions — Here's where motion-triggered accessibility comes in. If an interaction produces animation, that animation cannot flash more than three times per second (the seizure threshold). Additionally, users must be able to pause or disable animations via prefers-reduced-motion. This is critical. Vestibular disorders cause dizziness and nausea from motion. Photosensitive epilepsy is triggered by flashing. Respect both.

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

Understandable criteria: clarity as accessibility

Understandable criteria focus on making sure users can comprehend your interface and know what to do next.

3.1.1: Language of page — Declare the language of your page in the HTML lang attribute. Screen readers use this to apply the correct pronunciation rules. If your page is English but you don't declare it, a screen reader might stumble over basic words.

<html lang="en">

3.1.4: Abbreviations — The first time you use an abbreviation or acronym, expand it. "WCAG compliance" on first mention should be "Web Content Accessibility Guidelines (WCAG) compliance." Users with cognitive disabilities and non-native speakers need that clarity.

3.3.1: Error identification — When a user makes an error (invalid email, missing required field), tell them clearly: what went wrong and how to fix it. Don't rely on red color alone—add error text with an icon or symbol. "Password must include one number" is better than a red border with no explanation.

3.3.2: Labels or instructions — Form inputs must have associated labels. Never rely on placeholder text as a label; placeholders disappear when the user starts typing. Use proper <label> elements tied to inputs via for and id attributes.

<!-- Good -->
<label for="email">Email address</label>
<input id="email" type="email" required />

<!-- Bad (placeholder-only) -->
<input type="email" placeholder="Email address" />

3.3.4: Error prevention — For high-stakes actions (deleting data, submitting payments, changing settings), provide confirmation dialogs or undo capability. Users with tremors, cognitive disabilities, or those using voice control need a safety net.

3.3.5: Help and documentation — Users should have access to help. This might be inline instructions, FAQs, tooltips, or support links. Keep instructions close to where they're needed.

Robust criteria: future-proofing and assistive tech

Robust is about ensuring your code works with assistive technologies and browsers—now and in the future.

4.1.2: Name, role, state — Every interactive element must have a name (what it does), a role (what type of element it is), and a state (its current condition). This information lives in HTML semantics and ARIA attributes, which assistive technologies parse to understand your interface.

For a button, the name might be "Delete account," the role is "button," and the state might be "disabled" if the user hasn't confirmed yet. A screen reader user will hear: "Delete account, button, disabled." They'll know exactly what it is and whether it's interactive.

<!-- Good: semantic HTML + ARIA -->
<button aria-label="Close menu" aria-expanded="false">×</button>

<!-- Bad: generic div with no semantics -->
<div onclick="closeMenu()">×</div>

4.1.3: Status messages — When you update the page without a full reload (like a form submission success message), announce that update to assistive technologies using aria-live regions. A screen reader user has no visual cue that something changed; you must tell them programmatically.

<div aria-live="polite" aria-atomic="true" id="status"></div>
<script>
  document.getElementById('status').textContent = 'Your form was saved.';
</script>

Building a holistic accessibility strategy

Compliance isn't the goal; usability is. Here's how to think about WCAG as a system:

1. Audit beyond color — When you're testing accessibility, don't stop at contrast ratios. Use a keyboard to navigate the entire interface. Turn on a screen reader. Test with a switch. Try prefers-reduced-motion in your browser's dev tools. Use a WCAG contrast checker to verify ratios, but also test for non-text contrast, focus visibility, and error messaging.

2. Test with real users — WCAG criteria are a baseline, not perfection. Real users with disabilities will find edge cases, confusing patterns, and broken assumptions that no automated test catches. Include people with CVD, motor disabilities, hearing loss, and cognitive disabilities in your testing.

3. Prioritize by impact — Not all criteria affect all users equally. Keyboard navigation affects millions of users with mobility disabilities and motor conditions. Color contrast affects roughly 8% of men and 0.4% of women. Focus visibility affects everyone who uses a keyboard. Sequence your work by reach and severity.

4. Integrate accessibility into workflow — Don't bolt it on at the end. Train designers to think about keyboard navigation early. Ask developers to test focus order before merge. Add automated accessibility checks to your CI/CD pipeline. Use tools like DeficiencyView during design reviews, not after launch.

5. Document accessibility decisions — When you choose to support an AAA criterion beyond AA, or when you make an exception to a guideline, document why. This helps future team members understand your constraints and intentions.

Common misconceptions about WCAG

"WCAG is only for people with disabilities." False. Captions help users watching videos in noisy environments. Keyboard navigation helps users with touchpads or older mice. Sufficient contrast helps users with presbyopia (age-related vision changes) or viewing content on phones in sunlight. Accessible design is good design for everyone.

"WCAG AA is enough; AAA is overkill." AA is a reasonable baseline for most products. AAA is worth pursuing for content where clarity is critical: healthcare information, legal documents, educational material. You don't need AAA for everything, but know where it matters.

"Automated accessibility testing catches everything." Automated tools find about 25–30% of accessibility issues. They're excellent for catching missing alt text, poor contrast, and broken form labels. But they can't evaluate whether your error messages are clear, whether your focus order makes sense, or whether your interface logic is understandable. Human review is non-negotiable.

"Color contrast is the main accessibility issue." It's a visible, easy-to-understand problem, so it gets attention. But keyboard navigation failures, screen reader incompatibility, and confusing error messages affect more users and cause more friction. Diversify your focus.

Frequently asked questions

Q: How do I know which WCAG level to target? A: Start with AA. It's the widely adopted standard and covers the most common barriers. AAA is excellent for specialized content or if your users specifically need it. Don't claim AAA compliance unless you've audited against every AAA criterion; it's more intensive than most teams realize.

Q: Can I use an automated accessibility checker to guarantee compliance? A: No. Automated tools like Axe, Lighthouse, and WAVE are valuable for catching obvious issues (missing alt text, poor contrast), but they miss complex problems like keyboard navigation logic, screen reader compatibility, and understandability. Use them as a starting point, then conduct manual testing and involve people with disabilities in user testing.

Q: What's the most common WCAG failure I'll encounter? A: Missing or poor keyboard navigation. Hundreds of interfaces are completely unreachable via keyboard. Test this first; it's often a quick win with massive impact.

Q: Do I need to support all input methods? A: Yes, if the interface is public-facing or for general use. Support keyboard, mouse, touch, and voice input. If you're building internal tools, you might have more flexibility, but even then, keyboard support costs little and helps users with motor conditions and RSI.

Q: How does WCAG relate to other standards like Section 508 or the Accessibility Act? A: WCAG is the technical standard. Section 508 (US federal requirement) and laws in other countries often reference WCAG 2.1 AA as the compliance baseline. Building to WCAG 2.2 AA puts you ahead of most legal requirements and, more importantly, helps real users.

Related Articles

Test your interface's accessibility comprehensively with our WCAG contrast checker and CVD simulator — it takes seconds to upload a screenshot or URL and see how your design performs across multiple accessibility dimensions.

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.