How to Fix the 10 Most Common WCAG Violations (with Code)

Most accessibility failures are not exotic. They cluster. In 2026, 95.9% of the top one million home pages had detectable WCAG 2 failures, and the average page carried 56.1 of them (WebAIM Million, 2026). Six error types alone account for 96% of everything detected, and they have been the same six for seven years running (WebAIM Million, 2026).

That is good news for anyone holding a scan report. You don't need to learn a hundred fixes. You need to learn about ten, because those ten cover the overwhelming majority of what a tool like axe-core will flag. This guide gives you the exact fix for each, with before-and-after code you can paste and adapt. It's a spoke of our developer's guide to web accessibility testing; read that for the full testing workflow, and use this when you have violations in hand and want them gone.

TL;DR: The ten most common WCAG violations are low-contrast text, missing alt text, unlabelled form fields, empty links, skipped heading levels, empty buttons, a missing lang attribute, a missing page title, colour-only links, and no skip link. Nine of the ten are a one-attribute or one-element fix, not a redesign. Automated tools catch about 57% of issues by volume (Deque, 2021), so fix these first, then test the rest by hand.

Why Fix These 10 Violations First?

Because they are where the failures actually are, and because they carry legal weight. In 2025, federal website accessibility lawsuits in the US reached 3,117 filings, up 27% from 2,452 the year before (Seyfarth Shaw, 2026). Most complaints cite the same handful of failures listed below.

Automated detection has limits worth stating up front. Of the 55 WCAG 2.2 AA success criteria, only about 13% can be flagged with high accuracy, and 42% can't be automatically detected at all (Accessible.org, 2025). By raw issue volume the coverage is higher, around 57% (Deque, 2021). The ten violations here sit squarely inside that machine-detectable zone, which is exactly why fixing them is the fastest way to clear a scan.

Here is the full lineup, ranked by 2026 prevalence where WebAIM measures it, each mapped to the axe-core rule that catches it and the WCAG success criterion it fails.

Citation capsule: Six error types (low-contrast text at 83.9%, missing alt text at 53.1%, missing form labels at 51%, empty links at 46.3%, skipped heading levels at 41.8%, and empty buttons at 30.6%) account for the bulk of the 96% of failures concentrated in the most common categories across the top one million home pages (WebAIM Million, 2026). Each maps to a single axe-core rule with a direct code fix.

The 10 Most Common WCAG Violations and Their Fixes

Each fix below shows the failing pattern first, then the corrected version. The rule ID in each heading is what axe-core reports, so you can match a scan line straight to its section.

1. Low-Contrast Text (color-contrast, WCAG 1.4.3 AA)

Low contrast is the single most common failure, present on 83.9% of pages in 2026, with an average of 34 distinct instances per page (WebAIM Million, 2026). Normal text needs a contrast ratio of at least 4.5:1 against its background; large text (24px, or 19px bold) needs 3:1.

<!-- ❌ Fails: #999 on #fff is only 2.85:1 -->
<p style="color: #999999; background: #ffffff;">Subtle grey caption text</p>

<!-- ✅ Passes: #595959 on #fff is 7:1 -->
<p style="color: #595959; background: #ffffff;">Subtle grey caption text</p>

Pick colours with a contrast checker before you commit them, not after. One caveat axe's text rule won't catch: icons, input borders, and focus rings fall under WCAG 1.4.11 Non-text Contrast and need 3:1 against their surroundings. Contrast is deep enough to deserve its own guide, so treat this as the fast fix, not the whole story.

2. Missing Image Alt Text (image-alt, WCAG 1.1.1 A)

In 2026, 53.1% of pages had at least one image missing its alt attribute (WebAIM Million, 2026). Screen readers announce an image with no alt by reading its file name, which is useless. Every <img> needs an alt attribute, even when the value is empty.

<!-- ❌ Fails: no alt attribute -->
<img src="/revenue-2026.png">

<!-- ✅ Passes: describes what the image conveys -->
<img src="/revenue-2026.png" alt="Revenue grew 42% from Q1 to Q4 2026">

<!-- ✅ Also passes: decorative image, explicitly empty alt -->
<img src="/divider-flourish.svg" alt="">

Write alt text that carries the image's meaning, not its appearance. A chart's alt should state the takeaway. A decorative flourish gets alt="" so screen readers skip it cleanly.

3. Unlabelled Form Inputs (label, WCAG 1.3.1 / 4.1.2 A)

Form fields without labels appeared on 51% of pages in 2026 (WebAIM Million, 2026). A placeholder is not a label: it vanishes on input and many screen readers ignore it. Associate a real <label> with every field.

<!-- ❌ Fails: placeholder is not a label -->
<input type="email" placeholder="Email address">

<!-- ✅ Passes: label linked by matching for/id -->
<label for="email">Email address</label>
<input id="email" type="email">

<!-- ✅ Also passes: wrapped input needs no id -->
<label>Email address <input type="email"></label>

When a visible label genuinely can't fit, such as a search field with only an icon, use aria-label="Search" on the input. A visible label is still better for everyone, including people with cognitive disabilities.

4. Empty Links (link-name, WCAG 2.4.4 / 4.1.2 A)

Empty links, meaning links a screen reader can't name, sat on 46.3% of pages in 2026 (WebAIM Million, 2026). The usual culprit is an icon-only link with no text inside it. A screen reader announces "link" and nothing more.

<!-- ❌ Fails: icon only, no accessible name -->
<a href="/cart"><svg><!-- cart icon --></svg></a>

<!-- ✅ Passes: visually hidden text names the link -->
<a href="/cart">
  <svg aria-hidden="true"><!-- cart icon --></svg>
  <span class="visually-hidden">View cart</span>
</a>

The visually-hidden class hides the text on screen while keeping it available to assistive technology. An aria-label="View cart" on the <a> works too, but visible-when-focusable text is more resilient. Mark the decorative SVG aria-hidden="true" so it isn't announced twice.

5. Skipped Heading Levels (heading-order, WCAG 1.3.1 A)

Skipped heading levels turned up on 41.8% of pages in 2026, roughly one in every 25 headings (WebAIM Million, 2026). Screen reader users navigate by jumping between headings, so a jump from <h1> to <h4> reads like two levels of content went missing.

<!-- ❌ Fails: h1 jumps straight to h4 for styling -->
<h1>Pricing</h1>
<h4>Starter plan</h4>

<!-- ✅ Passes: sequential levels, styled with CSS -->
<h1>Pricing</h1>
<h2>Starter plan</h2>

Never pick a heading level for its default size. Choose the level that reflects the document's structure, then style it with CSS. If you want an <h2> to look smaller, that's a class, not an <h4>.

One catch worth knowing: axe-core tags heading-order as a best-practice rule, not a WCAG rule. A scan scoped to wcag2a and wcag2aa tags won't flag it unless you also enable best-practice rules in your config.

6. Empty Buttons (button-name, WCAG 4.1.2 A)

Buttons with no discernible text appeared on 30.6% of pages in 2026 (WebAIM Million, 2026). Like empty links, these are usually icon buttons. Voice-control users can't say "click" a button that has no name, and screen reader users hear only "button".

<!-- ❌ Fails: icon button with no name -->
<button><svg><!-- close icon --></svg></button>

<!-- ✅ Passes: aria-label names the action -->
<button aria-label="Close dialog">
  <svg aria-hidden="true"><!-- close icon --></svg>
</button>

Name the action, not the icon: "Close dialog" beats "X". If the button already has visible text, you don't need aria-label at all, and adding a conflicting one can override the visible text for screen readers.

7. Missing Document Language (html-has-lang, WCAG 3.1.1 A)

A missing lang attribute affected 13.5% of pages in 2026, down from 15.8% the year before (WebAIM Million, 2026). Without it, a screen reader may read English content using another language's pronunciation rules. The fix is one attribute on one element.

<!-- ❌ Fails: no language declared -->
<html>

<!-- ✅ Passes: BCP 47 language tag -->
<html lang="en">

Use a valid tag such as en, en-GB, or fr. In a framework, set it once at the root. In Next.js, that's the <html lang="en"> in your root layout. Get this right and it fixes the whole page in a single line.

8. Missing Page Title (document-title, WCAG 2.4.2 A)

A missing or empty <title> is one of axe-core's most commonly flagged issues, because the title is the first thing a screen reader announces on load and the label users see in browser tabs and history. An untitled page leaves people unsure which page they even landed on.

<!-- ❌ Fails: no title, or a generic one on every page -->
<title></title>

<!-- ✅ Passes: unique, descriptive, page-specific -->
<title>Pricing — a11yFlow</title>

Give every page a distinct title that names the content first and the site second. In Next.js, the Metadata API handles this: export metadata with a title per route rather than hardcoding one title in the layout.

9. Colour-Only Links (link-in-text-block, WCAG 1.4.1 A)

Links inside a paragraph that are distinguished from surrounding text by colour alone fail WCAG 1.4.1. This one is easy to miss because it looks fine to most people, but readers with colour blindness can't tell the link from the prose. axe flags it when the colour difference is the only cue.

/* ❌ Fails: colour is the only signal */
p a { color: #1a6; text-decoration: none; }

/* ✅ Passes: a non-colour cue as well */
p a { color: #1a6; text-decoration: underline; }

An underline is the simplest fix and the one users already expect on links. If your design system strips underlines, add another non-colour signal such as a bottom border or bold weight. Reserving underline for links only, and never for emphasis, keeps the cue unambiguous.

As with heading-order, axe-core treats link-in-text-block as a best-practice rule, so enable best-practice rules in your config if you want it caught in CI rather than only in a manual review.

10. No Skip Link (bypass, WCAG 2.4.1 A)

Pages with no way to bypass repeated navigation fail WCAG 2.4.1, and axe reports this via its bypass rule. Keyboard and screen reader users otherwise have to tab through every nav item on every page before reaching the content. A skip link and a <main> landmark solve it together.

<!-- ✅ First focusable element on the page -->
<a href="#main" class="skip-link">Skip to main content</a>
<nav><!-- navigation --></nav>
<main id="main">
  <!-- page content -->
</main>

/* Visually hidden until it receives keyboard focus */
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
}

The link stays out of the way until a keyboard user tabs to it, then appears so they can jump straight past the menu. Wrapping your content in a <main> landmark also gives screen reader users a one-key jump to the same place.

What we see: The same six failure categories have topped the WebAIM Million for seven consecutive years (WebAIM Million, 2026). That consistency tells you something useful. This is not a knowledge gap about obscure rules. It is a backlog of one-attribute fixes that never got a gate to stop them, which is why catching them in CI matters more than memorising them.

How Do You Catch These Before They Ship?

Run axe-core in your pipeline so a new violation fails the build instead of reaching users. axe-core is the engine behind most of the fixes above, and wiring it into continuous integration turns this whole list into an automatic check. Fixing an issue in development instead of production can cost up to 30 times less (Microsoft, 2023).

The setup is short: run a Playwright test with @axe-core/playwright, assert the violations array is empty, and gate your pull requests on it. Our step-by-step walkthrough covers the full workflow in how to set up accessibility testing in GitHub Actions. If you're deciding which engine to run where, axe vs Lighthouse vs WAVE vs pa11y compares them by layer.

Citation capsule: Automated tools detect only about 13% of the 55 WCAG 2.2 AA success criteria with high accuracy and cannot detect 42% at all (Accessible.org, 2025), while still catching about 57% of real-world issues by volume (Deque, 2021). The ten most common violations sit inside that detectable zone, so a CI gate running axe-core stops the majority of them before they reach production.

What About the Issues Automation Can't Catch?

The 43% of issues that automation misses by volume are the ones that need a human (Deque, 2021). Keyboard operability, focus order, meaningful alt text quality, and screen reader flow can't be judged by a rule engine. A tool can tell you an image has alt text; only a person can tell you the alt text is any good.

This is also why accessibility overlays don't work: they promise to automate the part that can't be automated. We cover the evidence in why accessibility overlays fail. One more thing automation won't do for you is prove compliance on paper. For the regulatory side, the WCAG 2.2 compliance checklist maps criteria to what you actually have to document.

ARIA problems deserve a mention here too. In 2026, ARIA was present on 82.7% of pages, and pages using it averaged 59.1 errors against 42 on pages without it (WebAIM Million, 2026). Misused ARIA often makes things worse, not better. It's a big enough topic that we're giving it separate coverage rather than squeezing it into this list.

Frequently Asked Questions

What is the most common WCAG violation?

Low-contrast text is the most common by a wide margin. In 2026 it appeared on 83.9% of the top one million home pages, with an average of 34 distinct instances per page (WebAIM Million, 2026). The fix is choosing text and background colours that meet a 4.5:1 contrast ratio for normal text.

Can I fix all WCAG violations automatically?

No. Automated tools catch about 57% of accessibility issues by volume (Deque, 2021) but flag only about 13% of the 55 WCAG 2.2 AA success criteria with high accuracy (Accessible.org, 2025). The ten violations here are detectable and fixable programmatically. Keyboard flow, focus order, and alt text quality still need manual review.

Which WCAG level do these violations fail?

Nine of the ten fail WCAG Level A, the minimum conformance level, and low-contrast text fails Level AA. Both are what most laws reference, including the European Accessibility Act. In 2026, 95.9% of top home pages failed at least one such criterion (WebAIM Million, 2026). Our web accessibility compliance guide maps levels to legal obligations.

What tool reports these violation names?

The rule IDs in this guide, such as color-contrast, image-alt, and link-name, come from axe-core, the open-source engine Deque measured catching 57% of accessibility issues by volume (Deque, 2021). It powers browser extensions, CI integrations, and scanning APIs including a11yFlow. See our accessibility testing tools comparison for how the engines differ.

How long does it take to fix these?

Most are minutes, not hours. Nine of the ten are a single attribute or element change: add a lang, add an alt, add a <label>. The bigger saving is timing: fixing in development instead of production can cost up to 30 times less (Microsoft, 2023). The slow part is finding every instance, which is what a scanner automates for you.

The Bottom Line

Ten violations cover the overwhelming majority of what an accessibility scan will throw at you, and nine of them are a one-line fix. Low-contrast text, missing alt text, and unlabelled form fields alone appear on more than half of all pages (WebAIM Million, 2026), and each has a fix you can apply today.

Work the list top to bottom, because it's ordered by how often each one actually occurs. Then put a gate around your progress so the fixes stick: wire axe-core into CI as shown in our GitHub Actions tutorial, and read the developer's guide to web accessibility testing for the parts of the job automation can't do. Fix the common ten first, gate them, then test the rest by hand.

Sources

• WebAIM, The WebAIM Million 2026 Report, retrieved 2026-07-06, https://webaim.org/projects/million/
• Deque Systems, Automated Testing Study Identifies 57% of Digital Accessibility Issues, retrieved 2026-07-06, https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/
• Accessible.org, Automated Scans and WCAG Success Criteria, retrieved 2026-07-06, https://accessible.org/automated-scans-wcag/
• Seyfarth Shaw (ADA Title III blog), Federal Court Website Accessibility Lawsuit Filings Bounce Back in 2025, retrieved 2026-07-06, https://www.adatitleiii.com/2026/03/federal-court-website-accessibility-lawsuit-filings-bounce-back-in-2025/
• Microsoft, Shifting Left to Get Accessibility Right at Microsoft, retrieved 2026-07-06, https://www.microsoft.com/insidetrack/blog/shifting-left-to-get-accessibility-right-at-microsoft/