Top accessibility mistakes (and how to fix them)
Every year, WebAIM (Web Accessibility In Mind) conducts a large-scale evaluation of the top 1 million home pages on the web. The WebAIM Million report is based on automated accessibility scans and provides insight into the current state of accessibility.
The 2025 report marks the seventh consecutive year of this study. This year, like every year, WebAIM highlighted 5 of the most common accessibility issues across the web. Also like every year, these most common issues have been the same for the last 5 years.
Let’s dive into the 5 most common accessibility issues detected by the million report to learn what they are, why they happen, and how each role in the SDLC can fix them.
Quick links:
1. Low Contrast Text
What this issue means
Low contrast text doesn’t provide enough visual difference between the text and its background. This makes it difficult—or impossible—for people with low vision, colour blindness, or even those using screens in bright environments to read the content.
How it may happen
Designers may be going for a “minialist” look, choosing subtle colour palettes that inadvertently don’t have enough colour contrast (like light grey on a white background).
Sometimes, brand colours like yellow, orange, or light blue are used directly for text or important UI elements without checking whether they meet contrast requirements. These colours may look vibrant and on-brand, but when placed against a light background—like white or pale grey—they often don’t provide enough contrast to be legible, especially for users with low vision or colour blindness.
In this mock website, the low-contrast version features the brand colours used as text. By comparison, use the brand colours as decorative accents to preserve the text contrast.
In other cases, design elements may have been overlooked and left to developers to improvise. Focus and hover states may not have been specified. Or, a maintenance banner might need to be quickly thrown together without a prior design. If a developer chooses colours arbitrarily (like using CSS “red”) or copies colours from the design system without context, it’s easy to end up with unreadable content.
What to do instead
Product / Business Analyst (BA):
Include contrast requirements in user stories or acceptance criteria.
Prioritise accessibility in early product discussions, instead of addressing it “later.”
Design:
Use tools like Figma’s built in colour contrast checker or the WCAG Contrast Checker to test colours.
Use brand colours with weak contrast as accents rather than primary text or UI elements.
Include the focus and hover states in designs, making sure they meet contrast requirements.
Development:
Use tools like a colour contrast checker if you’re required to create a design on the fly.
Ask for focus and hover states in the designs.
Testing:
Use tools like a colour contrast checker if you’re required to create a design on the fly.
Do manual spot-checks for text on images, gradients, or coloured backgrounds.
2. Missing Alternative Text for Images
What this issue means
Alternative text (alt text) provides a textual description of images for people using screen readers. Without it, users may miss important information conveyed by visuals.
How it may happen
Who decides what the alt text of an image is?
It’s an area in the process that can be overlooked, or get passed on to the next person in the workflow to decide on. CMS users may forget to fill it in on upload, and during a web/app build devs might not have the right context to write a good alt text.
What to do instead
Product / BA:
If images have already been selected by this stage, provide alt text.
Include alt text as a requirement in stories - be specific (e.g. Image x has the alt text of y).
In a CMS, set standards for content image uploads (e.g. alt text is mandatory).
Design:
Use annotations to identify the appropriate alt text:
Decorative images: null alt
Informative image: state what the alt text should be
Icons and graphics with no text: describes the function of the icon
Icons and graphics with text: null alt
Interactive images (can be clicked on): describes the function of the link
This mock-up provides the alt text based on the nature of the image. Only the first instance of an image or icon is annotated.
Development:
Always include an alt attribute on images:
Decorative images: <img alt=“null”>
Informative image: describes what the image looks like (ask product/design/BA for an accurate alt text)
Icons and graphics with no text: describes the function of the icon
Icons and graphics with text: <img alt=“null”>
Interactive images (can be clicked on): describes the function of the link
Use “title” attribute on SVG images to provide an alt text equivalent.
Testing:
Use screen readers or other tools to verify that images are properly labeled (see development above for expected outputs).
Check for missing, redundant, or inaccurate alt text.
3. Missing Form Input Labels
What this issue means
Form input labels are essential for telling users what information is being requested. A label must be visible to all users. That means visually visible for sighted users and programmatically detectable for assistive technology users.
Without visual and programmatic labels, users won’t know what an input field is for.
How it may happen
Minimalist designs can sometimes mean forgoing important information for the sake of white space. Placeholder text is not considered sufficient as a label (or as hints), since it disappears when the user inputs information.
Programmatic issues with labels most often happen because of poor HTML implementation.
What to do instead
Product / BA:
Define form requirements with accessibility in mind.
Include validation, error handling, and label guidance in documentation.
Design:
Always include visible labels in form designs.
Avoid using placeholder text as the only method of conveying input purpose.
Development:
Use the <label> attribute for a label, and connect it to its corresponding <input> via the for/id method.
Grouped elements should use <fieldset> and <legend> to properly label the group.
Call out designs where placeholder text is used as the only label.
Testing:
Check that all forms have visual labels that are always visible, even when you enter text into the field.
Use screen readers or other tools to verify that input fields are programmatically connected to their labels.
4. Empty Links and Buttons
What this issue means
Empty links and buttons are interactive elements that don’t have a programmatic name to them. For screen reader users, this means hearing “link” or “button” and that’s it. For speech activation users, they won’t be able to call on a button or link since it has no programmatic name.
How it may happen
This is most commonly connected to the lack of alt text. When an image/icon is interactive (ie, clickable) but that image or icon has no alt text, it means that the button or link it is meant to represent also has no name.
What to do instead
See actions under alt text. Pay particular attention to images and icons that are clickable.
In addition, developers should avoid implementing the content of buttons or links (like words or icons) using methods that are invisible to assistive technology, like CSS. For example, pseudo-selectors ::before or ::after aren’t picked up by assistive tech.
5. Missing Document Language
What this issue means
The “lang” attribute on the HTML document or element tells screen readers how to pronounce the content. Without it, users may hear robotic or incorrect pronunciation, especially if the content isn’t in the user’s default language.
How it may happen
Developers might forget to add “lang” to the HTML document, use a language value that is invalid, or forget to change the value when a site is translated. CMS-generated pages may default to no language setting.
What to do instead
Product / BA:
Specify the expected document language in the specs. This is usually done universally and doesn’t need to be specified with every story or component, unless that element has a different language to the main page
If the page is internationalised, include the expected document language in the specs.
Development:
Make sure document language is specified
Use the appropriate value for the attribute. English is “en”.
Add a lang attribute on in-body text that differs from the document language: <p lang=“fr”>Bonjour!</p>
Testing:
Use dev tools or screen reader settings to check for correct pronunciation.
Final Thoughts
Accessibility issues are often unintentional, but they can have a significant impact on people’s ability to use your website. The good news is that many of these issues—like the five above—are preventable with a little attention at each stage of the development lifecycle. By focusing on these five issues alone, you can make significant gains in the accessibility of your website or app.
Find out more about Aleph Accessibility's auditing, training and consulting services. Or get in touch to start or accelerate your accessibility journey.