How to Fix the 6 Most Common WCAG Failures on Any Website
Nearly 96% of the top one million websites have detectable WCAG failures — and the same six issue types account for the vast majority of those errors year after year. This guide breaks down each failure with concrete, code-level fixes so you can make a real dent in your accessibility debt today.
<p>Open any of the top million websites right now and there is a 96-in-100 chance you will find a WCAG violation that an automated scanner can catch in seconds. <cite index="1-16">Across one million home pages, 56,114,377 distinct accessibility errors were detected — an average of 56.1 errors per page.</cite> What makes this especially striking is that <cite index="1-24,1-25">96% of all detected errors fall into just six categories, and those six most common error types have remained the same for the last seven years.</cite> That means fixing a handful of well-understood problems would dramatically improve accessibility across the entire web — and it starts with your site.</p>
<h2>Why the Same Six Failures Keep Appearing</h2>
<p>You might wonder how, in an era of sophisticated development tooling and growing legal scrutiny, the same errors persist at scale year after year. The answer is systemic. <cite index="7-11,7-12,7-13,7-14">This density of errors reflects how deeply inaccessibility has been built into web development practices. Template problems multiply across every page. Component failures repeat throughout sites. Without deliberate attention to accessibility, standard development workflows produce systematically inaccessible results.</cite></p>
<p>There is also a false sense of progress driven by automation. <cite index="5-8,5-9">Automated testing catches only 30–40% of potential WCAG failures. Sites passing automated tests may still have significant keyboard navigation, screen reader, or cognitive accessibility issues.</cite> This means that even the small percentage of sites that appear compliant on paper are likely falling short in practice.</p>
<p>The legal stakes are real and rising. <cite index="8-13,8-14">According to Seyfarth Shaw, 8,800 ADA Title III federal lawsuits were filed in 2024, with approximately 2,452 specifically targeting web accessibility. E-commerce sites face disproportionate risk — 77% of web accessibility lawsuits target online retail.</cite> Compliance is no longer a nice-to-have. It is a business continuity issue.</p>
<p>The encouraging flipside? <cite index="7-35,7-36,7-37">This concentration has practical implications. Organizations can address the majority of their accessibility issues by focusing on a handful of problem types. Comprehensive WCAG compliance requires attention to all 78 criteria, but the highest-impact improvements come from fixing these common failures.</cite> So let us work through each one, with practical fixes you can implement today.</p>
<h2>Failure #1 — Low Contrast Text (WCAG 1.4.3)</h2>
<p><cite index="7-15,7-16">Low contrast text — text that does not have sufficient color differentiation from its background — appears on 83.6% of homepages studied. This is the most common WCAG failure, affecting more than four in five websites.</cite> WCAG 1.4.3 (Contrast Minimum) is brutally straightforward: normal text must achieve a contrast ratio of at least 4.5:1 against its background, and large text (18pt or 14pt bold) must reach at least 3:1.</p>
<p><cite index="7-17,7-18,7-19">Contrast failures often stem from design decisions that prioritize aesthetics over readability. Light gray text on white backgrounds looks sophisticated to designers with perfect vision. To users with low vision, older users, or anyone reading on a screen with glare, it is illegible.</cite> Secondary labels, form placeholders, footer text, and disabled button states are the usual culprits — they get styled to look subtle and end up being invisible to a significant portion of your audience.</p>
<p>The fix is almost always a CSS adjustment. Run your color pairs through a contrast checker such as WebAIM's contrast tool or the browser DevTools accessibility panel, then nudge the foreground or background value until it passes. Here is a common pattern that fails and how to correct it:</p>
<pre><code>/* Failing — ratio approximately 2.3:1 */
.secondary-label {
color: #aaaaaa;
background-color: #ffffff;
}
/* Passing — ratio approximately 7:1 */
.secondary-label {
color: #595959;
background-color: #ffffff;
}</code></pre>
<p>For placeholder text, remember that WCAG treats it as real text — not a decorative hint — so it must also meet the 4.5:1 threshold. Avoid relying solely on placeholder text to convey instructions; pair it with a visible <code><label></code> element regardless. If you use images of text, you cannot fix contrast with CSS — you need to regenerate those images, which is yet another reason to prefer live HTML text over text baked into graphics.</p>
<h2>Failure #2 — Missing Image Alternative Text (WCAG 1.1.1)</h2>
<p><cite index="7-22,7-23">Images without alternative text appear on 58.2% of homepages. When images lack alt text, screen reader users encounter either silence or meaningless file names where meaningful content should be.</cite> This problem is not new. <cite index="4-9,4-10">Alt text has been a fundamental accessibility requirement since WCAG 1.0 in 1999. Twenty-five years later, most websites still fail to implement it consistently.</cite></p>
<p>The reason it persists is a workflow gap, not a knowledge gap. <cite index="7-27,7-28,7-29,7-30">This failure rate points to systematic gaps in content workflows. Writers and editors often do not know alt text is needed. Content management systems do not always prompt for it. Quality assurance does not catch the absence.</cite> The fix therefore has two layers: a technical one and a process one.</p>
<p>On the technical side, every meaningful image needs an <code>alt</code> attribute that conveys the same information the image conveys. Decorative images — purely visual flourishes that add no information — should receive an empty <code>alt=""</code> so screen readers skip them entirely. Getting this distinction right matters as much as adding the attribute at all. <cite index="9-34,9-35,9-36">A large percentage of images have missing or inaccurate alt text. Some meaningful images have no descriptions at all, while decorative images are often treated as meaningful content. Both issues break WCAG conformance for perceivable content.</cite></p>
<pre><code><!-- Meaningful image: describe what it conveys -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />
<!-- Decorative image: empty alt, no role needed -->
<img src='wave-divider.svg' alt='' />
<!-- Linked image: describe the destination, not the image -->
<a href='/pricing'>
<img src='pricing-icon.svg' alt='View pricing plans' />
</a></code></pre>
<p>On the process side, update your CMS templates to make the alt field required for content images, and train anyone uploading assets. Automated tools like Accsible can detect images with missing or empty alt text site-wide, giving your team an auditable list to work through systematically.</p>
<h2>Failure #3 — Missing Form Input Labels (WCAG 1.3.1, 3.3.2)</h2>
<p><cite index="2-14">48.6% of websites have missing form input labels.</cite> This failure is particularly damaging because forms are where users actually do things — sign up, check out, make contact, submit support requests. <cite index="9-45,9-46">Many forms lack accessible labels, rely only on placeholders, fail to expose instructions and error messages, or do not support keyboard-only use. Because forms are essential to most digital experiences, these failures create serious usability barriers.</cite></p>
<p>The most common mistake is using placeholder text as a substitute for a <code><label></code>. Placeholders disappear once a user starts typing, leaving anyone with a short-term memory impairment — or simply someone who gets distracted mid-form — with no idea what the field is for. Screen readers vary in how they handle placeholders, and none of the approaches is as reliable as a proper label association.</p>
<p>The correct pattern is to use a <code><label></code> element linked to its input via matching <code>for</code> and <code>id</code> attributes. If a visible label is not possible for design reasons, use <code>aria-label</code> or <code>aria-labelledby</code> — but do not reach for ARIA when you could just use a <code><label></code>.</p>
<pre><code><!-- Correct: explicit label association -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />
<!-- Wrong: placeholder only -->
<input type='email' placeholder='Email address' />
<!-- Acceptable when label must be visually hidden -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' /></code></pre>
<p>Error messages must also be programmatically associated. When a form validates and finds an error, the message should be linked to the field using <code>aria-describedby</code>, and ideally focus should be moved to the first invalid field. <cite index="17-21,17-22">Form validation errors should be efficient, intuitive, and accessible — the error must be clearly identified, quick access to the problematic element provided, and the user must be able to easily fix the error and resubmit the form.</cite></p>
<h2>Failure #4 — Empty Links and Buttons (WCAG 2.4.4, 4.1.2)</h2>
<p><cite index="2-17">44.6% of websites have empty hyperlinks.</cite> <cite index="3-7,3-8,3-9">Empty buttons were found on almost 30% of pages, and this number increased from the previous year. That means blind or low-vision users will not understand the purpose of buttons such as submit, reset, filter, or search.</cite> Together, empty links and buttons represent one of the most frustrating experiences for screen reader users — encountering interactive elements with no name is like pressing a door handle with no label and no idea where it leads.</p>
<p>Empty links most commonly occur when an icon or image is the only child of an <code><a></code> tag, and no text alternative is provided. Empty buttons happen when icon-only buttons — hamburger menus, close icons, social share buttons — lack any accessible name. Both are straightforward to fix.</p>
<pre><code><!-- Empty link — fails -->
<a href='/dashboard'><svg>...</svg></a>
<!-- Fixed with aria-label -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>
<!-- Empty button — fails -->
<button><svg>...</svg></button>
<!-- Fixed with visually hidden text -->
<button>
<svg aria-hidden='true'>...</svg>
<span class='visually-hidden'>Close menu</span>
</button></code></pre>
<p>Note the <code>aria-hidden='true'</code> on the SVG in each fixed example. When you provide a text alternative via <code>aria-label</code> or visually hidden text, you want to suppress the SVG from the accessibility tree — otherwise screen readers may announce both the label and the SVG's own title or description, creating a confusing double-announcement. Ambiguous link text — phrases like "click here," "read more," or "learn more" — is a related failure. <cite index="3-4,3-5,3-6">Other hyperlink issues such as ambiguous link text were found on almost 14% of home pages, an increase from the previous year. Hyperlinks with proper text are important so that users know where a link will take them.</cite> Each link's accessible name should make sense out of context because screen reader users frequently navigate by pulling up a list of all links on a page.</p>
<h2>Failure #5 — Missing Document Language (WCAG 3.1.1)</h2>
<p>This one might seem minor compared to contrast or alt text, but <cite index="3-10">about 16% of pages are missing a set document language</cite> — and the impact on screen reader users is immediate and jarring. <cite index="3-14,3-15">If a screen reader user has the specific language pack installed, the content will be voiced correctly. Otherwise it will sound like a bad accent and may not be understandable.</cite></p>
<p>The fix is a single HTML attribute — literally one line of code — and there is no excuse for missing it. Add the <code>lang</code> attribute to your <code><html></code> element with the appropriate BCP 47 language tag. If sections of your page are in a different language than the page as a whole, add a <code>lang</code> attribute to those specific elements as well.</p>
<pre><code><!-- Missing: no lang attribute -->
<html>
<!-- Correct: English page -->
<html lang='en'>
<!-- Correct: French page -->
<html lang='fr'>
<!-- Inline language switch within a page -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p></code></pre>
<p>If you use a CMS or static site generator, the <code>lang</code> attribute should be set in your base template. Check your template once, fix it once, and every page on your site is immediately corrected. This is perhaps the highest return-on-effort fix on this entire list — a single template change eliminates the problem across your entire domain.</p>
<h2>Failure #6 — Inaccessible Keyboard Navigation and Focus Management (WCAG 2.1.1, 2.4.7)</h2>
<p>Keyboard accessibility is where the gap between automated testing and real-world usability is widest. Automated tools can detect some keyboard failures — like interactive elements built from non-semantic tags — but they cannot simulate tab order, focus trapping, or the experience of navigating a dropdown menu with only arrow keys. <cite index="5-17">Sites frequently remove default focus indicators without providing alternatives, making keyboard navigation nearly impossible.</cite> This affects not just users with motor disabilities but anyone who prefers keyboard navigation, power users, and people using switch devices.</p>
<p>The most common keyboard failures are: custom interactive components built from <code><div></code> or <code><span></code> tags that never receive focus; CSS rules that strip the browser's default focus ring with <code>outline: none</code> or <code>outline: 0</code> without replacing it with something equally visible; modal dialogs that do not trap focus (so keyboard users can tab behind the overlay); and carousels or accordions that cannot be operated without a mouse.</p>
<pre><code><!-- Keyboard-inaccessible custom button — fails -->
<div class='btn' onclick='doSomething()'>Submit</div>
<!-- Correct: use a real button -->
<button type='button' onclick='doSomething()'>Submit</button>
<!-- Removing focus styles — fails WCAG 2.4.7 -->
* {
outline: none; /* never do this globally */
}
<!-- Better: style focus visibly while preserving aesthetics -->
:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 2px;
}
</code></pre>
<p>The <code>:focus-visible</code> pseudo-class is your best friend here. It shows focus styles when a user navigates by keyboard, but suppresses them for mouse clicks — giving you clean aesthetics without sacrificing accessibility. For modals and drawers, use a focus-trapping utility that constrains tab navigation to within the dialog while it is open, and returns focus to the triggering element when it closes. <cite index="9-40,9-41">Pop-ups often appear without proper focus management, without labels, or without support for keyboard navigation. This causes significant disruptions, especially in critical user flows like sign-ups, logins, and checkout processes.</cite></p>
<p>Beyond individual components, consider adding a skip navigation link — a visually hidden link that becomes visible on focus and allows keyboard users to jump past repetitive navigation to the main content. <cite index="5-18">Skip links allowing users to bypass repetitive navigation are missing on the majority of sites.</cite> It is three lines of HTML and a small CSS snippet, and it makes a profound difference for anyone navigating a content-rich page by keyboard.</p>
<pre><code><!-- Place this as the very first element inside <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>
<!-- Then in your CSS -->
.skip-link {
position: absolute;
left: -9999px;
}
.skip-link:focus {
left: 0;
top: 0;
z-index: 9999;
}</code></pre>
<h2>A Note on ARIA: Use It Carefully</h2>
<p>Many teams reach for ARIA (Accessible Rich Internet Applications) attributes as a quick fix for accessibility gaps. The data suggests this backfires more often than it helps. <cite index="3-16,3-17">Approximately 79% of evaluated home pages used ARIA, an increase from the previous year. Home pages with ARIA had more than twice as many errors as pages without ARIA.</cite> <cite index="3-18,3-19,3-20">ARIA itself is not the issue — it is usually misuse or incorrect ARIA. Many well-meaning developers think they are making content more accessible by adding ARIA, when in fact they often make it less so.</cite></p>
<p>The guiding principle is simple: use semantic HTML first. A <code><button></code> is better than a <code><div role='button'></code>. A <code><nav></code> is better than a <code><div role='navigation'></code>. Native HTML elements come with built-in keyboard behavior, focus management, and implicit ARIA roles that custom markup requires you to replicate manually — and that manual replication is where the errors creep in. Reserve ARIA for cases where HTML genuinely cannot express the semantic you need, such as live regions, complex composite widgets, or dynamic state changes.</p>
<h2>Building Accessibility Into Your Workflow</h2>
<p>Fixing existing violations is necessary, but preventing new ones from appearing is what separates mature accessibility programs from one-off compliance sprints. <cite index="13-10,13-11">Accessibility is not a one-time fix. Every content update, design change, or code deployment can introduce new issues.</cite> The six failure categories covered in this guide tend to be template-level problems — fix the header, footer, and shared components and you eliminate the issue across hundreds of pages simultaneously.</p>
<p>Integrate automated scanning into your CI/CD pipeline so violations are caught before they reach production. Tools like axe-core can be embedded into unit tests and end-to-end test suites. Pair that with periodic manual keyboard walkthroughs and screen reader testing — VoiceOver on macOS and iOS, NVDA on Windows — because <cite index="6-8">automated testing can detect common accessibility errors, but manual testing helps to fill in the gaps.</cite> For teams that need a faster on-ramp, an accessibility overlay widget like Accsible can surface and remediate a significant class of issues at the rendering layer while longer-term code-level fixes are planned and deployed.</p>
<p>Finally, address the biggest leverage point in your codebase: your templates. <cite index="13-3,13-4,13-5">Most websites use templates — a header, footer, navigation, and page layout that repeat on every page. Issues in these templates multiply across your entire site. Fix them first for maximum impact.</cite> A single corrected base template can turn 10,000 WCAG failures into zero with one deployment.</p>
<h2>Key Takeaways</h2>
<ul>
<li><strong>Six issue types dominate the landscape.</strong> Low contrast text, missing alt text, unlabeled form inputs, empty links and buttons, missing document language, and broken keyboard navigation account for the overwhelming majority of WCAG failures. Fixing these six categories delivers outsized results relative to effort.</li>
<li><strong>Most fixes are CSS or one-line HTML changes.</strong> Adding <code>lang='en'</code> to your <code><html></code> tag, replacing <code>outline: none</code> with <code>:focus-visible</code> styles, and associating labels with inputs are hours of work, not months — yet they eliminate failures that affect every user with a disability who visits your site.</li>
<li><strong>Templates are the highest-leverage fix location.</strong> Accessibility bugs in shared components and page templates replicate across your entire site. Audit your header, footer, navigation, and forms first — fixing them there fixes them everywhere.</li>
<li><strong>ARIA is a tool of last resort, not a first response.</strong> Sites that rely heavily on ARIA without a strong semantic HTML foundation tend to have significantly more accessibility errors, not fewer. Prefer native HTML elements wherever possible.</li>
<li><strong>Automated scanning catches less than half the real issues.</strong> Complement your tooling with manual keyboard walkthroughs and screen reader testing to find the failures that no scanner will surface, including focus traps, logical tab order problems, and dynamic content that fails to announce changes.</li>
</ul>