8 Things Developers Get Wrong About WCAG

WCAG is not a checklist you sprinkle onto UI at the end. It's a specification for building web content that works for people with disabilities—and most of it is satisfied by correct semantics, predictable interaction, and robust structure. Developers who treat WCAG as a late-stage audit requirement miss the point and create more work for themselves.

WCAG is mostly satisfied by fundamentals. WebAIM's 2024 Million report found the most common failures are low contrast (81% of pages), missing alt text (54%), missing form labels (48%), and empty links (45%). These aren't exotic edge cases requiring deep accessibility expertise. They're basic HTML and CSS patterns that any developer can implement correctly. The prevalence of these issues across 95.9% of tested home pages suggests widespread misconceptions about what accessibility requires.

Most WCAG failures aren't exotic—they're repeated fundamentals. The developer who believes accessibility is complicated often overlooks the simple truth: use semantic HTML, label your forms, provide text alternatives, and ensure keyboard operability. Master these basics and you've addressed the majority of issues. The rest involves specific interaction patterns where the ARIA Authoring Practices Guide provides clear patterns to follow.

Key Takeaways

Understanding common WCAG misconceptions helps developers build accessible code from the start.

• Automation isn't sufficient – Lighthouse green doesn't mean compliant; automated tools catch 30-40% of issues at best
• ARIA isn't magic – Wrong ARIA causes more problems than no ARIA; native HTML is the better default
• WCAG covers more than screen readers – Keyboard users, low-vision users, cognitive accessibility, and motor impairments all matter
• Focus outlines serve real users – Removing them for aesthetics breaks keyboard navigation for many people
• Accessibility is implementation, not inspection – It happens during development, not after; QA verifies, engineers own

Misconception #1: "If Lighthouse Is Green, We're Compliant"

The most dangerous misconception is that automated tools provide complete coverage.

What Automation Actually Catches

Automated accessibility tools (Lighthouse, axe-core, WAVE) detect issues that can be identified through DOM analysis:

+----------------------------+--------------------------------------+
|         Detectable         |                 Why                  |
+----------------------------+--------------------------------------+
|   Missing alt attributes   |   Attribute presence is verifiable   |
+----------------------------+--------------------------------------+
|    Missing form labels     |   Label association is verifiable    |
+----------------------------+--------------------------------------+
|     Contrast failures      |     Color values are computable      |
+----------------------------+--------------------------------------+
|        Invalid ARIA        |   Attribute validity is checkable    |
+----------------------------+--------------------------------------+
|    Heading order issues    |       Structure is analyzable        |
+----------------------------+--------------------------------------+

These are valuable catches. Automation eliminates high-volume, high-confidence issues efficiently.

What Automation Misses

Automation cannot evaluate:

+-----------------------------------+------------------------------------------+
|           Not Detectable          |                   Why                    |
+-----------------------------------+------------------------------------------+
|          Alt text quality         |   Requires understanding image purpose   |
+-----------------------------------+------------------------------------------+
|   Keyboard interaction patterns   |       Requires behavioral testing        |
+-----------------------------------+------------------------------------------+
|    Focus management correctness   |       Requires state understanding       |
+-----------------------------------+------------------------------------------+
|          Content clarity          |     Requires comprehension judgment      |
+-----------------------------------+------------------------------------------+
|      Error recovery usability     |       Requires flow understanding        |
+-----------------------------------+------------------------------------------+

W3C conformance understanding explicitly states that testing involves a combination of automated testing and human evaluation. Digital.gov guidance similarly recommends using both manual and automated methods.

The 30-40% Reality

Industry estimates suggest automated tools catch roughly 30-40% of WCAG issues. A green Lighthouse score means the detectable issues are addressed—not that the site is accessible. Real compliance requires human testing with assistive technology.

Misconception #2: "ARIA Fixes Accessibility"

Developers learn about ARIA and assume it's the solution to accessibility. It's not.

The First Rule of ARIA

The W3C ARIA specification states: "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

Native HTML is the primary accessibility tool. ARIA is for cases where HTML can't express what you need.

How ARIA Goes Wrong

+-----------------------------------------------+----------------------------------------------------+
|                    Pattern                    |                      Problem                       |
+-----------------------------------------------+----------------------------------------------------+
|          `role="button"` on a `<div>`         | Doesn't make it keyboard focusable or activatable  |
+-----------------------------------------------+----------------------------------------------------+
|   `aria-hidden="true"` on focusable element   |         Hidden to AT but can receive focus         |
+-----------------------------------------------+----------------------------------------------------+
|         Incorrect `aria-live` regions         | Announces things at wrong times or too frequently  |
+-----------------------------------------------+----------------------------------------------------+
|            Made-up ARIA attributes            |              AT ignores them silently              |
+-----------------------------------------------+----------------------------------------------------+
|             Conflicting ARIA roles            |           Confuses assistive technology            |
+-----------------------------------------------+----------------------------------------------------+

Wrong ARIA is often worse than no ARIA. AT expects ARIA to mean something; when it lies, users get confused.

When ARIA Is Appropriate

ARIA helps when:

• Building custom widgets that don't exist in HTML (combobox, tree view)
• Providing relationships HTML can't express (aria-describedby, aria-controls)
• Managing dynamic content announcements (aria-live regions)
• Indicating states (aria-expanded, aria-pressed, aria-selected)

For these cases, follow the ARIA Authoring Practices Guide patterns exactly. Don't improvise ARIA.

Misconception #3: "WCAG Is About Screen Readers Only"

WCAG addresses multiple disability categories, not just blindness.

What WCAG Actually Covers

+-------------------------+----------------------------------------------------+
|   Disability Category   |                   WCAG Concerns                    |
+-------------------------+----------------------------------------------------+
|    Visual (blindness)   |  Screen reader compatibility, alt text, semantics  |
+-------------------------+----------------------------------------------------+
|   Visual (low vision)   |       Contrast, text resizing, zoom support        |
+-------------------------+----------------------------------------------------+
|          Motor          |     Keyboard operability, target sizes, timing     |
+-------------------------+----------------------------------------------------+
|        Cognitive        |  Predictability, error prevention, clear language  |
+-------------------------+----------------------------------------------------+
|         Auditory        |     Captions, transcripts, visual alternatives     |
+-------------------------+----------------------------------------------------+

Building "for screen readers" addresses part of WCAG. Building for all disability categories addresses WCAG fully.

WCAG 2.2 Expansions

WCAG 2.2 added criteria that emphasize non-screen-reader needs:

• Focus Appearance (2.4.11, 2.4.13) – Focus indicators must be visible and meet minimum size/contrast
• Target Size (2.5.8) – Interactive elements need minimum 24×24px target area
• Dragging Movements (2.5.7) – Alternatives required for drag operations
• Consistent Help (3.2.6) – Help mechanisms in consistent locations
• Redundant Entry (3.3.7) – Don't require users to re-enter information
• Accessible Authentication (3.3.8) – Cognitive function tests shouldn't be required

These criteria address motor, cognitive, and low-vision users specifically.

Misconception #4: "We Can Remove Focus Outlines for Aesthetics"

Developers often add `outline: none` to remove the "ugly" default focus indicator. This breaks accessibility for keyboard users.

Why Focus Indicators Matter

Keyboard users navigate by pressing Tab. Without a visible focus indicator, they can't see where they are on the page. It's equivalent to hiding the mouse cursor for sighted users.

What WCAG Requires

WCAG 2.2 has explicit focus visibility requirements:

• 2.4.7 Focus Visible (Level AA): Focus indicator must be visible
• 2.4.11 Focus Not Obscured (Minimum) (Level AA): Focus indicator not hidden by other content
• 2.4.12 Focus Not Obscured (Enhanced) (Level AAA): Focus indicator fully visible
• 2.4.13 Focus Appearance (Level AAA): Minimum size and contrast for focus indicator

What to Do Instead

Don't remove focus outlines. Style them appropriately:

/* Bad */
*:focus { outline: none; }

/* Good */
*:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

Use `:focus-visible` to show focus only for keyboard navigation (not mouse clicks) in browsers that support it. This addresses the aesthetic concern while preserving accessibility.

Misconception #5: "Alt Text Is Easy—Just Add Something"

Developers know images need alt text. They don't always know what that alt text should be.

Alt Text Is Contextual

The same image needs different alt text depending on context:

+-------------------------------------+-------------------------------------------------+
|               Context               |               Appropriate Alt Text              |
+-------------------------------------+-------------------------------------------------+
|       Product photo on listing      |         "Blue cotton t-shirt, crew neck"        |
+-------------------------------------+-------------------------------------------------+
|    Same image as link to product    |        "View blue cotton t-shirt details"       |
+-------------------------------------+-------------------------------------------------+
|    Same image as decorative hero    |           `alt=""` (empty, decorative)          |
+-------------------------------------+-------------------------------------------------+
|   Same image illustrating article   |   "Example of our best-selling t-shirt style"   |
+-------------------------------------+-------------------------------------------------+

Alt text conveys the image's purpose in context, not a literal description.

The Three Categories

MDN's accessibility guidance distinguishes:

• Decorative images – Add visual interest but no information; use `alt=""`
• Informative images – Convey information; alt text describes that information
• Functional images – Serve as controls; alt text describes the action

An icon button needs alt text describing what it does ("Close dialog"), not what it looks like ("X icon").

Common Alt Text Mistakes

+-------------------------------+---------------------------------------------+
|            Mistake            |                   Problem                   |
+-------------------------------+---------------------------------------------+
|         "image of..."         |   Redundant; AT already announces "image"   |
+-------------------------------+---------------------------------------------+
|        File name as alt       |         "IMG_2847.jpg" means nothing        |
+-------------------------------+---------------------------------------------+
|   Same alt for all products   |    Generic text doesn't distinguish items   |
+-------------------------------+---------------------------------------------+
|    Alt on decorative images   |      Adds noise for screen reader users     |
+-------------------------------+---------------------------------------------+
|      Missing alt entirely     |      AT announces file path or nothing      |
+-------------------------------+---------------------------------------------+

Misconception #6: "Accessibility Is QA's Responsibility"

Treating accessibility as something QA catches at the end fails consistently.

Why the Model Fails

When accessibility is QA's job:

• Issues are found late, after code is written
• Context has faded; fixes are more expensive
• Backlog grows faster than remediation
• Engineering doesn't learn accessible patterns
• Same mistakes repeat across features

Engineering Owns Implementation

Accessibility is implemented in code:

• Semantic HTML choices
• Keyboard event handlers
• Focus management logic
• ARIA attribute values
• Component API design

These are engineering decisions made during development, not QA findings discovered after.

QA Verifies, Engineering Implements

+-----------------+----------------------------------------------------+
|       Role      |                   Responsibility                   |
+-----------------+----------------------------------------------------+
|   Engineering   | Implement accessible patterns; respond to lint/CI  |
+-----------------+----------------------------------------------------+
|      Design     | Specify keyboard behavior, focus states, error patterns |
+-----------------+----------------------------------------------------+
|        QA       |        Verify with AT; report issues found         |
+-----------------+----------------------------------------------------+
|     Product     |       Include accessibility in requirements        |
+-----------------+----------------------------------------------------+

W3C guidance on planning accessibility emphasizes integrating accessibility throughout the production process. It's everyone's responsibility, with engineering owning implementation.

Misconception #7: "WCAG Issues Are Page-by-Page Problems"

Developers often think of accessibility issues as page-specific bugs. Most issues are component-level.

Component-Level Reality

WebAIM's common failures map to components:

+-------------------------+----------------------------------------+
|      Common Failure     |             Component Root             |
+-------------------------+----------------------------------------+
|   Missing form labels   |          Form input component          |
+-------------------------+----------------------------------------+
|      Empty buttons      |      Button/icon button component      |
+-------------------------+----------------------------------------+
|       Empty links       |             Link component             |
+-------------------------+----------------------------------------+
|       Low contrast      |       Design system color tokens       |
+-------------------------+----------------------------------------+
|     Missing alt text    |   Image component + content workflow   |
+-------------------------+----------------------------------------+

The Multiplier Effect

A broken form input component creates broken forms everywhere:

• Used in checkout? Checkout is broken.
• Used in signup? Signup is broken.
• Used in contact form? Contact is broken.

Fix the component once, and all instances improve. Fix page by page, and you're fixing forever.

Component-First Remediation

When audit findings arrive:

1. Identify which component is responsible
2. Fix the component (not individual pages)
3. Add tests to the component
4. Add lint rules if applicable
5. Verify instances inherit the fix

This produces 10x-100x return on effort compared to page-by-page remediation.

Misconception #8: "We'll Do It Later"

"Later" is how accessibility debt accumulates to unmanageable levels.

Why "Later" Fails

WebAIM's 2024 Million report shows 95.9% of home pages failing accessibility. These aren't sites that never heard of accessibility. They're sites where accessibility was deferred.

+-------------------------------------+----------------------------------------------------+
|          What Gets Shipped          |                 What Gets Deferred                 |
+-------------------------------------+----------------------------------------------------+
|     Features that drive revenue     |   Accessibility that "doesn't affect most users"   |
+-------------------------------------+----------------------------------------------------+
|   Bug fixes that cause complaints   |      Accessibility without internal advocates      |
+-------------------------------------+----------------------------------------------------+
|      Work with clear deadlines      |         Accessibility with vague timelines         |
+-------------------------------------+----------------------------------------------------+

"Later" becomes "never" through normal prioritization pressure.

Why Now Is Cheaper

The cost of accessibility fixes increases over time:

• During development: Minutes (developer has context)
• During code review: Hours (reviewer needs context)
• During QA: Days (ticket created, assigned, scheduled)
• After release: Weeks (coordination, prioritization, scheduling)
• During remediation project: Months (project management overhead)
• After legal demand: Emergency pace with external deadlines

Fix it when you build it. That's when it's cheapest.

What Developers Should Do Instead

Correct practices produce accessible code without accessibility becoming a separate concern.

The Practical Playbook

1. Use semantic HTML – `<button>`, `<a>`, `<input>`, `<nav>`, `<main>`, `<header>`. HTML has accessibility built in.

1. Adopt accessible component primitives – Use design system components that handle accessibility. Don't rebuild from divs.

1. Add lint rules – eslint-plugin-jsx-a11y catches common JSX mistakes automatically.

1. Add CI checks – axe-core in your test suite catches issues before merge.

1. Use ARIA APG patterns – When building custom widgets, follow ARIA Authoring Practices exactly.

1. Test with keyboard – Can you use the feature with Tab, Enter, Escape, and arrow keys? If not, fix it.

1. Test with screen reader – VoiceOver (Mac), NVDA (Windows), or browser extensions give real feedback.

1. Make remediation source-first – Fix issues in source code with tests. Don't rely on runtime patches.

Making It Routine

Accessibility becomes routine when it's:

• Part of component contracts (required props)
• Enforced by lint rules (immediate feedback)
• Checked by CI (can't merge violations)
• In the definition of done (acceptance criteria)
• Verified in QA (AT testing standard)

When accessibility is routine, it doesn't require special effort. It's just how code gets written.

FAQ

How do I convince my team that accessibility matters?

Frame it in terms they care about. Legal risk: 8,800 ADA lawsuits in 2024. Market reach: 70+ million US adults with disabilities. Quality: accessible code tends to be well-structured code. SEO: semantic HTML helps search rankings. Don't make it a moral argument (though it is one); make it a practical one.

What's the minimum I should know as a frontend developer?

Semantic HTML (use the right elements), form labeling (every input needs a label), keyboard navigation (Tab, Enter, Escape work correctly), and visible focus (don't hide focus indicators). These four concepts address the majority of common issues. Add ARIA knowledge when you need custom widgets.

Should I worry about WCAG 2.2 if we're targeting 2.1?

WCAG 2.2 adds criteria; it doesn't remove any. Meeting 2.1 AA meets most 2.2 AA criteria. The new 2.2 criteria (focus appearance, target size, dragging alternatives, etc.) are good practices regardless of formal target. Implement them when feasible—they improve usability for everyone.

How do I handle accessibility in legacy code?

Prioritize by risk: critical journeys first, then high-traffic pages, then everything else. Look for component-level fixes that propagate widely. Add CI checks to prevent new issues while remediating old ones. Don't try to fix everything at once; create a sustainable reduction trajectory.

Is accessibility testing part of my job as a developer?

Yes. You test that your code works; you test that your code is accessible. Use the keyboard to verify navigation. Run axe-core to catch automated issues. Learn basic screen reader navigation to verify announcements. QA provides additional verification, but first-line accessibility testing is a development responsibility.

What resources help me learn more?

W3C ARIA Authoring Practices Guide for widget patterns. MDN accessibility documentation for fundamentals. WebAIM for practical guidance. Deque University for structured learning. Start with MDN for basics, then APG when building custom widgets.

Related Resources

Internal Links

• Why Accessibility Is a Software Engineering Problem
• The Role of CI/CD in Accessibility
• How Linting Changes Accessibility
• Accessibility in Modern JS Frameworks
• What "Shift Left" Means for Accessibility
• Accessibility Technical Debt Explained

External Sources

• W3C ARIA Authoring Practices Guide
• W3C Understanding Conformance
• W3C What's New in WCAG 2.2
• WebAIM Million 2024 Report
• MDN Accessibility Guide
• Digital.gov: Introduction to Accessibility

This article was written by TestParty's editorial team with AI assistance. All statistics and claims have been verified against primary sources. Last updated: January 2026.