Practical fixes for the WCAG violations found on the vast majority of websites.
According to the WebAIM Million report, which analyzes the homepages of the top 1,000,000 websites, over 95% of homepages have detectable WCAG failures. The average page has over 50 errors. The good news: the most common issues are well-understood and straightforward to fix. Addressing just these 10 issues will resolve the majority of accessibility problems on most websites.
WCAG 1.1.1 — Non-text Content (Level A)
Missing or inadequate alt text is the single most common accessibility issue. Screen readers rely on the alt attribute to describe images to users who cannot see them. Without it, the screen reader either skips the image entirely or reads the file name, which is rarely helpful.
Add a descriptive alt attribute to every <img> element:
<!-- Bad: no alt text -->
<img src="chart.png">
<!-- Good: descriptive alt -->
<img src="chart.png" alt="Bar chart showing 30% revenue growth in Q1 2026">
<!-- Decorative image: empty alt -->
<img src="decorative-divider.png" alt="">For decorative images (borders, spacers, background patterns), use alt="" so screen readers skip them. Never omit the alt attribute entirely.
WCAG 1.4.3 — Contrast (Minimum) (Level AA)
Low contrast between text and its background makes content difficult or impossible to read for users with low vision, color blindness, or even users in bright sunlight. This is the second most common violation found across the web.
Ensure text meets minimum contrast ratios:
<!-- Bad: light gray on white (contrast ~2:1) -->
<p style="color: #aaaaaa; background: #ffffff">Hard to read</p>
<!-- Good: dark gray on white (contrast ~7:1) -->
<p style="color: #333333; background: #ffffff">Easy to read</p>WCAG 1.3.1 — Info and Relationships (Level A)
Form inputs without programmatically associated labels are unusable for screen reader users. The user hears “edit text” but has no idea what the field is for. Placeholder text is not a substitute for a label — it disappears when the user starts typing and is not reliably announced by all screen readers.
<!-- Bad: no label -->
<input type="email" placeholder="Your email">
<!-- Good: explicit label -->
<label for="email">Email address</label>
<input type="email" id="email">
<!-- Also good: aria-label for visual hiding -->
<input type="email" aria-label="Email address">WCAG 2.4.1 — Bypass Blocks (Level A)
Keyboard users must tab through every navigation link on every page before reaching the main content. On a site with 20+ navigation links, this is extremely tedious. A “skip to content” link at the top of the page lets them jump directly to the main content area.
<!-- Add as the first element in body -->
<a href="#main-content" class="skip-link">Skip to main content</a>
<!-- Style to show only on focus -->
<style>
.skip-link {
position: absolute;
top: -40px;
left: 0;
background: #000;
color: #fff;
padding: 8px;
z-index: 100;
}
.skip-link:focus { top: 0; }
</style>
<main id="main-content">...</main>WCAG 2.1.1 — Keyboard (Level A)
Dropdown menus that open on hover but not on focus are completely inaccessible to keyboard users. Custom dropdown components often lack proper ARIA attributes, making them opaque to screen readers.
Ensure dropdowns open on both hover and focus/keyboard interaction. Use proper ARIA attributes:
<button aria-expanded="false" aria-haspopup="true">
Products
</button>
<ul role="menu" hidden>
<li role="menuitem"><a href="/product-a">Product A</a></li>
<li role="menuitem"><a href="/product-b">Product B</a></li>
</ul>Toggle aria-expanded and the hidden attribute with JavaScript on both click/Enter and focus events.
WCAG 2.4.7 — Focus Visible (Level AA)
Many designers remove the default browser focus outline (outline: none) because they consider it visually unappealing. Without a visible focus indicator, keyboard users cannot tell which element is currently selected.
<!-- Bad: removing focus with no alternative -->
<style>
*:focus { outline: none; }
</style>
<!-- Good: custom focus style -->
<style>
*:focus-visible {
outline: 2px solid #4f46e5;
outline-offset: 2px;
}
</style>Using :focus-visible instead of :focus shows the outline only for keyboard navigation, not mouse clicks, satisfying both designers and accessibility requirements.
WCAG 1.4.2 — Audio Control (Level A)
Audio or video that plays automatically can be disorienting for screen reader users (it talks over their screen reader) and distressing for users with cognitive disabilities. If auto-play is used, audio must be muted by default or a mechanism to stop it must be provided within the first 3 seconds.
<!-- Good: muted autoplay -->
<video autoplay muted>
<source src="hero.mp4" type="video/mp4">
</video>
<!-- Better: no autoplay -->
<video controls>
<source src="hero.mp4" type="video/mp4">
</video>WCAG 2.4.4 — Link Purpose (Level A)
Links that say “Click here,” “Read more,” or “Learn more” without context are meaningless to screen reader users who navigate by pulling up a list of all links on the page. Each link’s purpose must be clear from its text alone or its surrounding context.
<!-- Bad -->
<a href="/report">Click here</a>
<!-- Good -->
<a href="/report">Download the 2026 accessibility report</a>
<!-- Also good: aria-label for visual brevity -->
<a href="/report" aria-label="Download the 2026 accessibility report">
Download report
</a>WCAG 1.3.1 — Info and Relationships (Level A)
Screen reader users navigate long pages by jumping between headings. When headings skip levels (h1 directly to h3), use headings purely for styling (h4 used because it’s small, not because it’s a fourth-level heading), or are missing entirely, the page structure becomes confusing and navigation breaks down.
<!-- Bad: skipped levels -->
<h1>Page Title</h1>
<h3>Section</h3> <!-- h2 skipped -->
<!-- Good: sequential hierarchy -->
<h1>Page Title</h1>
<h2>Section</h2>
<h3>Subsection</h3>Use CSS for visual sizing, not heading levels. Every page should have exactly one <h1>.
WCAG 1.1.1, 1.3.1, 2.4.2 — Multiple Criteria
PDFs are often scanned images with no text layer, making them completely invisible to screen readers. Even text-based PDFs frequently lack proper structure tags, reading order, and alt text for images.
AccessCheck by NormSuite automatically detects 7 of these 10 issues (alt text, contrast, labels, focus, headings, links, and page structure) in a 60-second scan. Start with an automated scan to identify the low-hanging fruit, then follow up with manual testing for dropdowns, skip navigation, and PDFs.
Scan for Accessibility Issues FreeThe most common issues are: missing alt text on images, low color contrast, missing form labels, no skip navigation link, inaccessible dropdown menus, missing focus indicators, auto-playing media, non-descriptive link text, missing heading hierarchy, and inaccessible PDF documents.
Add an alt attribute to every img element. For informative images, describe the content (alt="Chart showing 30% revenue growth"). For decorative images, use an empty alt (alt="") so screen readers skip them.
WCAG 2.1 AA requires a minimum 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt or 14pt bold). Use a contrast checker tool to verify your color combinations meet these minimums.
No. Automated tools catch about 30–50% of WCAG issues, primarily structural ones like missing alt text, low contrast, and missing labels. Manual testing with keyboard and screen readers is needed to catch interaction and context issues.