The most common web accessibility errors include low-contrast text, missing alt text on images, missing form labels, empty links, and empty buttons. This article covers ten widespread issues, with practical solutions for fixing or avoiding each one.
Most web teams genuinely want to provide the best possible experience for users. But even at well-meaning organizations, accessibility considerations are often neglected during design and development.
The most recent WebAIM Million report, based on an automated scan of the top one million website homepages, found that 95.9% of homepages contain violations of the Web Content Accessibility Guidelines (WCAG) 2.2—with an average of 56.1 distinct accessibility errors per page.
Staying ahead of accessibility issues isn’t as complicated as you might think. According to WebAIM, the same six errors account for roughly 96% of all violations. Avoiding a handful of common pitfalls can have an outsized impact on your site’s overall usability for people with disabilities.
This article covers ten frequent web accessibility bugs, and how to address them, so you can provide a functional and enjoyable experience for more users.
Key insights
- 95.9% of the top one million homepages contain detectable WCAG 2.2 failures, averaging 56.1 errors per page.
- Six error types account for roughly 96% of all detected violations: low-contrast text, missing alt text on images, missing form labels, empty links, empty buttons, and missing document language.
- Other common issues include absent or inadequate focus indicators, lack of support for keyboard navigation, inaccessible form controls, and misuse of ARIA (Accessible Rich Internet Applications).
- Automated testing tools cannot catch all WCAG violations, making manual testing with assistive technologies an essential part of any accessibility program.
Common accessibility errors—and how to avoid them
Accessibility issues are widespread—and so are the consequences. With the number of web accessibility lawsuits filed under the Americans with Disabilities Act (ADA) increasing year-over-year, providing barrier-free experiences isn’t just about doing right by your users. It’s also critical to reducing legal risk.
Let’s explore ten of the most frequent accessibility errors made by web designers, developers, and content authors.
1. Insufficient color contrast
According to WebAIM, low color contrast between text and background elements is the most common accessibility error, affecting 83.9% of homepages. This failure is often the result of design choices that do not consider readability and accessibility.
Low-contrast text can make reading difficult for users with low vision, along with anyone trying to access content on a mobile device in bright light. Because of this, WCAG Level AA requires a color contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.
How to fix it: Always check color contrast during the design phase—before any code is written—and treat failures as blocking issues.
2. Missing alt text for images
53.1% of homepages have images with missing alt text, often because it’s treated as an afterthought rather than a requirement in development and content creation.
The alt attribute is what screen readers use to provide a text equivalent to an image. When it’s absent, screen reader users either receive no information, or get the raw file name—which rarely conveys the image’s purpose or the visual content it contains.
How to fix it: Write alt text that concisely provides an equivalent for every informative image, and use an empty alt=”” attribute on decorative ones so screen readers skip them.
3. Missing form labels
51% of homepages have unlabeled form input fields. A common culprit is using placeholder text as a substitute for a label—but placeholders disappear the moment a user starts typing. Without a programmatically associated label, screen reader users navigating a registration form or any multi-field form have no way to know what each input field is asking for.
How to fix it: The most effective method is to provide a <label> element with a matching for attribute on every form control, including text fields, checkboxes, and radio buttons.
4. Empty links
46.3% of homepages have empty links—anchor tags with no text, or image links whose images have no alt text. Vague link text like “click here” or “read more” creates a similar problem. Screen reader users may navigate by either pulling up a list of all links on a page or tab from link to link, and link text that doesn’t describe the link’s purpose makes that list useless.
How to fix it: Write descriptive link text that makes the link’s purpose clear on its own, and add aria-label to any icon-only links. You may also use aria-labelledby to associate links and relevant text.
5. Empty buttons
30.6% of homepages have empty buttons—a figure that has risen every year since 2019. Icon-only buttons such as hamburger menus, search icons, or close buttons are the most common offenders. A screen reader user reaching an empty button hears only “button,” with no indication of what it does, making interactive elements in navigation menus and dialogs challenging to use.
How to fix it: Add an aria-label to any button that lacks visible text—for example, aria-label=”Close dialog” on a close button.
6. Missing document language
13.5% of homepages are missing a lang attribute on the <html> element—an error that’s often missed because it has no visible effect on the page. Without a declared language, screen readers may apply the wrong pronunciation engine. As a result, content may be difficult or impossible to understand for users who are blind, have low vision, or rely on text-to-speech tools.
How to fix it: Add lang=”en” (or the appropriate language code) to the <html> element of every page.
7. Absent or inadequate focus indicators
Many developers remove the default browser focus outline using outline: none in CSS because it clashes with a design. This leaves users who rely on keyboard navigation without a way of knowing which interactive element currently has keyboard focus. With no visible cue showing where they are on the page, visitors may find it hard to use the page predictably.
How to fix it: Never suppress focus indicators entirely; instead, design a custom focus style that is visually distinct and meets WCAG contrast requirements.
8. Lack of support for keyboard navigation
WCAG requires that all functionality be operable through a keyboard interface without requiring specific timings for individual keystrokes. However, interactive elements built with non-semantic HTML—such as click handlers on <div> elements—are not keyboard accessible by default.
That means users who don’t navigate with a mouse—including some people with motor disabilities—may be locked out of features entirely. Users of assistive technologies that rely on keyboard support, such as screen reader users, may also find that keyboard focus becomes trapped or follows an unpredictable tab order.
How to fix it: Build interactive elements with native HTML (<button>, <a>, <input>) and test every feature using only the Tab key, arrow keys, Enter, and Escape.
9. Inaccessible form controls
Missing labels aren’t the only culprit for inaccessible forms. Beyond labeling issues, form controls are often grouped incorrectly, required fields are marked with color or a visual asterisk only, and error messages aren’t programmatically linked to the input that triggered them. Screen reader users may not know a field is required until after submitting, and error messages that appear visually near an input field may not be announced by assistive technologies.
How to fix it: Use <fieldset> and <legend> to group related controls, communicate required fields with text, and link error messages to their input using aria-describedby.
10. ARIA misuse
ARIA attributes are intended to enhance accessibility for dynamic content, but are frequently applied incorrectly—often to elements that already have native HTML equivalents. Misused ARIA can actively confuse screen reader users: roles applied without the required keyboard interaction model, aria-hidden on focusable elements, and ARIA labels that contradict visible text all create accessibility barriers that automated testing rarely catches.
How to fix it: Use semantic HTML first, incorporate ARIA only when native elements can’t do the job, and test any ARIA implementation with a real screen reader.
Web accessibility testing: Surfacing issues on your site
Free automated tools like WAVE and Google Lighthouse can detect code-level accessibility issues quickly—but automated testing only catches a portion of WCAG violations. For example, automated tools can’t judge whether alt text is meaningful, whether tab order is logical, or whether a page is understandable to someone with a cognitive disability.
The only way to get complete, reliable insight on your website’s accessibility is to combine automated tools with manual testing. Ideally, this evaluation should be performed by experts, including people with disabilities, and incorporate testing with screen readers across multiple screen sizes and devices.
Fix accessibility errors before they become liabilities
Unresolved accessibility issues cause problems for users—and create risk for businesses. On the flip side, accessible sites are clearer, more intuitive, and easier to use for everyone. Simply put, accessible design is good design.
Ready to deliver a more accessible web experience? Knowing where accessibility errors come from is the first step. Fixing them efficiently is the next. Explore the Accessibility Resolution Playbook for your complete roadmap to turning accessibility findings into real, lasting improvements.
The post 10 Common Accessibility Errors in Web Design and Development appeared first on Level Access.