Top 10 Most Common WCAG Violations and How to Fix Them
After analyzing thousands of accessibility scans, the same violations appear over and over. The good news: most of the issues that make websites inaccessible are straightforward to fix once you know what to look for.
Here are the 10 most common WCAG 2.1 AA violations we see across sites scanned with Litmus, along with what causes them and how to fix each one. For details on the contrast-specific issues, our WCAG color contrast guide goes deeper.
1. Missing image alt text (WCAG 1.1.1)
The single most common violation. Every <img> element needs an alt attribute. If the image conveys information, the alt text should describe it. If it is decorative, use alt="" (empty string, not missing entirely).
Fix: Audit every image on your site. Write concise, descriptive alt text for informational images. Add alt="" to decorative images. For complex images like charts, provide a longer description nearby or via aria-describedby.
2. Insufficient color contrast (WCAG 1.4.3)
Text must have a contrast ratio of at least 4.5:1 against its background for normal text, or 3:1 for large text (18pt regular or 14pt bold). Light gray text on white backgrounds is the most frequent offender.
Fix: Use a contrast checker to verify your color pairings. Adjust text or background colors until you meet the minimum ratios. Pay special attention to placeholder text, disabled states, and text over images.
3. Missing form input labels (WCAG 1.3.1, 4.1.2)
Every form input needs a programmatically associated label. Placeholder text alone does not count — it disappears when the user starts typing and is not reliably announced by all screen readers.
Fix: Use <label for="inputId"> for every input. If a visible label is not desired in the design, use aria-label or aria-labelledby. Never rely solely on placeholder attributes.
4. Empty links and buttons (WCAG 4.1.2, 2.4.4)
Links and buttons that contain only an icon (like a hamburger menu or social media icon) without any accessible text are invisible to screen reader users. They hear "link" or "button" with no indication of what it does.
Fix: Add aria-label to icon-only buttons and links. For example: <button aria-label="Open navigation menu">. Alternatively, add visually hidden text inside the element.
5. Missing document language (WCAG 3.1.1)
The <html> element must have a lang attribute. Without it, screen readers cannot determine the correct pronunciation rules for the page content.
Fix: Add lang="en" (or the appropriate language code) to your <html> tag. This is a one-line fix that affects your entire site.
6. Improper heading hierarchy (WCAG 1.3.1)
Headings should follow a logical descending order: h1, then h2, then h3, and so on. Skipping levels (going from h1 to h4, for example) confuses screen reader users who navigate by heading structure. Pages should have exactly one h1.
Fix: Restructure your headings to follow a logical hierarchy. If you need smaller text, use CSS to style the heading — do not pick a heading level based on visual size.
7. Missing skip navigation link (WCAG 2.4.1)
Keyboard users have to tab through every navigation link on every page to reach the main content. A "skip to content" link at the top of the page lets them bypass repetitive navigation.
Fix: Add a visually hidden (but focusable) link as the first element in your page body that jumps to the main content area: <a href="#main-content" class="sr-only focus:not-sr-only">Skip to content</a>.
8. Missing or incorrect ARIA attributes (WCAG 4.1.2)
Misused ARIA is worse than no ARIA at all. Common mistakes include aria-hidden="true" on focusable elements, invalid ARIA role values, and missing required child roles (like tabpanel without tab).
Fix: Follow the first rule of ARIA: if you can use a native HTML element instead, do so. When ARIA is necessary, validate that roles, states, and properties follow the WAI-ARIA specification.
9. Keyboard inaccessible interactive elements (WCAG 2.1.1)
Custom dropdowns, modals, tabs, and other interactive widgets built with <div> or <span> elements are not keyboard accessible by default. Users who cannot use a mouse are completely locked out of these controls.
Fix: Use native HTML elements (<button>, <select>, <details>) whenever possible. For custom widgets, add tabindex="0", keyboard event handlers (Enter, Space, Escape, Arrow keys as appropriate), and correct ARIA roles.
10. Auto-playing media without controls (WCAG 1.4.2)
Videos or audio that play automatically on page load without a visible pause or stop button create a serious barrier. Screen reader users may not be able to hear their assistive technology over the media, and some users experience sensory overload.
Fix: Do not auto-play media. If you must, provide a clearly labeled pause/stop button that is keyboard accessible and announced by screen readers. Ensure the media stops after 3 seconds if there is no user interaction.
Start finding these on your site
These 10 violations account for the vast majority of accessibility failures across the web. The encouraging part is that most of them are simple to fix once identified. The challenge is finding every instance across every page.
An automated WCAG scanner like Litmus can detect all 10 of these violation types across your entire site in minutes, with element-level detail showing exactly which HTML elements need attention. Start a free trial scan and see where your site stands — the results might surprise you.
Find accessibility issues before they find you
Litmus scans your entire website against WCAG 2.1 AA using axe-core. Get prioritized violations, element-level detail, and actionable fix guidance. Start your free 14-day trial — no credit card required.
Start Your Free Trial