11 Accessibility Issues You Need to Fix (And How)

The internet was designed to connect us — but for millions of people with disabilities, that connection is full of barriers. 

Despite years of advocacy and clear technical standards like the Web Content Accessibility Guidelines (WCAG), most websites continue to fall short. WebAIM’s 2024 analysis of the top 1 million homepages found that 94.8% contain detectable accessibility errors — a marginal improvement from previous years but still a glaring reminder of how far we have to go.

Here’s the twist: Many of these issues don’t result from bad intentions. They’re often caused by simple oversights — or by designers or developers not knowing the latest best practices without fully understanding how accessibility actually works. 

Whether it’s missing alt text, poor color contrast, or confusing keyboard navigation, some of the most common accessibility barriers are easy to fix once you know what to look for. But they’re also easy to miss — especially when you assume your website is already accessible.

Below, we’ll break down some of the most common web accessibility issues seen on websites when trying to enhance accessibility — and how to avoid them so your digital content is truly accessible and usable for everyone.

Identifying Accessibility Issues

Accessibility issues are any issues or barriers that prevent people with disabilities from using a website as easily and effectively as someone without a disability. These can range from missing image descriptions for screen reader users to interactive elements that can’t be accessed with a keyboard. And while some issues are obvious, many are subtle — hidden in the structure or behavior of a site that seems functional on the surface. 

So, how do you identify accessibility issues on your site?

The Role of Accessibility Tools and People

The first step to finding accessibility issues is knowing where your site falls short. That’s where accessibility testing tools come in. These automated tools — like AudioEye’s Web Accessibility Checker — provide a great starting point for enhancing accessibility as they flag common WCAG violations, including missing form labels, poor color contrast, or non-descriptive link text.

However, technology can only get you so far. Most automated tools can only catch common accessibility issues, leaving numerous others hidden on your site. Those require human judgment. For example, an automated tool may be able to tell if an image has alt text, but it can’t determine the quality of the alt text and if it’s actually helpful. Or if a screen reader experience is intuitive, or if information is presented in a logical order. 

More simply, usability questions or issues often go unnoticed by automated tools. Accessibility audits or testing by real users can help you identify and resolve those issues, making your digital content more usable by people with disabilities.

When Good Intentions Go Wrong

Many accessibility issues stem from a well-meaning desire to be accessible — but without the right knowledge, those efforts can backfire. For example, adding image descriptions is great in theory, but if every decorative image is described in detail, it clutters the experience for screen reader users. Or take the use of ARIA (Accessible Rich Internet Applications): intended to enhance accessibility, but when misused, it can actually create problems for assistive technologies instead. 

These kinds of accessibility problems highlight an important truth: digital accessibility isn’t just about adding features — it’s about getting the details right. That’s why it’s crucial to combine both automated and expert testing. Otherwise, even the most thoughtful efforts can unintentionally exclude the very people they’re meant to help.

A stylized website, with a magnifying glass hovering over an image on the page.

11 Common Accessibility Issues and Solutions

Once you start looking, it’s easy to see how small missteps in design and development can add up to big accessibility issues. Even websites or mobile apps built with accessibility in mind often fall short in a few key areas — usually not out of neglect, but because details were overlooked or misunderstood.

Below, we’ll discuss some of the most common accessibility issues on websites. Understanding these pitfalls is the first step towards creating a better, more accessible experience for users.

1. Inaccessible Navigation Links

Your navigation is the backbone of your website — but if users can’t access it with a keyboard or screen reader, it’s a major roadblock. One major mistake is using non-semantic HTML (like <div>s or <span>s) for clickable menu items instead of proper <a> tags. Without the correct markup, assistive technologies may not recognize links as links at all. 

Other issues include drop-down menus that don’t respond to keyboard input or lack focus indicators, leaving users unsure where they are on the page. Accessible navigation isn’t just about labeling links correctly — it’s about ensuring users can find, understand, and move through the site reliably.

Best practice: Always test navigation with a keyboard (no mouse) and check that links are properly labeled for screen readers. ARIA roles can help, but they’re not a substitute for correct HTML structure.

2. Tables and Infographics Incompatible with Assistive Technology

When data tables, charts, and infographics are not designed with accessibility, they leave out valuable information for assistive technology users. Common issues include missing table headers, poor use of scope attributes, or charts presented solely as images with no alternative text.

Screen readers rely on proper markup to interpret tables and associate data with headers. And for infographics, context is key: if the entire message of your chart is visual, screen reader users are left in the dark with a clear text equivalent.

Best practice: Use proper table markup (<th>, <scope>, etc.) and provide text summaries or data tables as alternatives to charts and graphics. Avoid relying solely on color or layout to convey meaning as well.

3. Color Contrast Errors

Color is a powerful design tool, but poor contrast between text and background colors is one of the most widespread — and easily fixable — accessibility issues (WebAIM found that 79.1% of homepages had color contrast levels below recommended WCAG levels).

WCAG 2.1 standards recommend a minimum color contrast ratio of 4.5:1 for normal text and 3:1 for large text so those with low vision or color blindness can easily distinguish between elements. However, many brands unintentionally violate these guidelines by prioritizing aesthetic choices over website accessibility.

Best practice: Use a color contrast checker (like this one from AudioEye) to test your color combinations before going live. If you’re unsure, err on the side of clarity — your content should be easy to read in any context.

Example of poor alt text for an image of a menu (simply saying menu) vs alt text that describes the menu (food, available toppings)

4. Missing or Non-Descriptive Alternative Text

Missing or non-descriptive alt text is one of the most common web accessibility issues. WebAIM found that of the 58.6 million images in the sample, 18.5% of all home pages (11 per page on average) had missing alt text. An additional 13.4% of images that did have alt text were questionable or repetitive alt text.

Alt text helps those using screen readers understand the content of images — but it only works if it’s present and meaningful. Missing alt text leaves users guessing while vague descriptions like “image123.jpg” or “graphic” don’t add any value.

Best practice: Provide concise, relevant descriptions that explain the image’s purpose. If an image is decorative, use “alt=”” to skip it. Both help enhance image accessibility and improve the user experience.

5. Unintuitive or Illogical Focus Order for Interactive Elements

Keyboard users — including many people with motor disabilities, cognitive disabilities, and blind users — navigate web pages using the ‘tab’ key to move between focusable elements. If the focus order doesn’t follow the visual layout or jumps around unpredictably, users can quickly lose track of where they are or miss important content altogether.

This often happens when elements are dynamically added, absolutely positioned, or arranged in a way that doesn’t reflect the order in the underlying HTML. It’s not always visible in design tools, which is why developers need to test the real experience. 

Best practice: Use keyboard-only testing to ensure a logical, intuitive focus order that matches the visual layout of your content.

6. WAI-ARIA Attributes

When sighted people browse a web page, they see visual cues and status messages that convey information without disrupting the user experience.

These elements need to be properly identified and announced for people using screen readers — or else they may go unnoticed. One way to do this is by assigning ARIA (Accessible Rich Internet Applications) roles — such as button, link, or tab — to each status message element, so that a screen reader can read them aloud.

ARIA roles provide semantic meaning to elements on a page (opens in a new tab), allowing screen readers to present and support interaction in a way consistent with user expectations. For example, a link tag with the added role of “button” will be treated as a button, not a link.

Missing WAI-ARIA Attributes

Custom components like modals or tabs often need ARIA to work properly with assistive tech. Users may not know when a modal opens or what its purpose is without it.

Example of poor alt text for an image of a menu (simply saying menu) vs alt text that describes the menu (food, available toppings)

Redundant WAI-ARIA Attributes

Sometimes developers add ARIA roles and labels to elements that don’t need them — like assigning role=”button” to an actual <button>. This can create a lot of confusion and frustration for users, who are left to decipher whether the page is poorly built or if there are multiple links next to each other.

Assuming Screen Readers Require ARIA Labels

Some developers make the mistake of adding an ARIA role to every object on a page, thinking that screen readers do not read elements without an ARIA label.

In the examples below, an ARIA-level attribute and value have been (incorrectly) added to each element:

<h2 aria-label="wish you were here heading">Wish You Were Here!</h2>

<a href="/cookie-policy" aria-label="Link to View our cookie policy">View our cookie policy</a>

<button id="verification" aria-label="Submit button">Submit</button>

Assuming Screen Readers Require ARIA Labels

Some developers make the mistake of adding an ARIA role to every object on a page, thinking that screen readers do not read elements without an ARIA label.

In the examples below, an ARIA-level attribute and value have been (incorrectly) added to each element:

Best practice: Use semantic HTML wherever possible, and apply ARIA thoughtfully to avoid unintended side effects. 

7. Lack of Keyboard Accessibility

A website isn’t truly accessible if it can’t be used without a mouse. Many interactive elements — like sliders, dropdown menus, and modal dialogs — are either not focusable or not operable via keyboard, which makes them completely inaccessible to users who rely on keyboard navigation.

This is often due to using non-semantic HTML, skipping focus states, or forgetting to add keyboard event listeners. It’s a foundational part of accessibility that’s easy to overlook during design and development.

Best practice: Ensure all website elements are fully accessible and usable by keyboard alone. Test it with real users or keyboard-only tools.

8. Missing or Confusing Link Text

Descriptive link text is essential for users who rely on screen readers, since many of them navigate by jumping from link to link. Missing or confusing link text is common, as many content creators use phrases like “Click here” or “Read more.” These phrases don’t provide enough context on their own, especially when separated from the surrounding content, which can be confusing to users. Even if the link appears clear visually, assistive technologies often remove it from its context, which means the text needs to stand alone. 

Best practice: Use link text that clearly describes the destination or action — and avoid vague or generic phrases that leave users guessing. For example, ‘Click here to learn more about WCAG’ or ‘Download the PDF on accessible design best practices’ provide more context about where a link will take users. 

9. Inaccessible Forms

Forms are a common point of failure for accessibility. Issues like unlabeled form fields, unclear error messages, or missing instructions can prevent users from completing important tasks — like signing up, submitting feedback, or purchasing.

Even when labels are visually present, they may not be programmatically associated with their fields, which leaves screen reader users without guidance. And when errors occur, many forms fail to alert users or explain what went wrong.

Best practice: Always use <label> elements correctly, associate them with form controls, and provide clear, accessible error messages and instructions.

10. Inaccessibility of Non-HTML Content (PDFs, Documents, etc.)

Accessibility requirements aren’t limited to HTML. Many organizations share critical content — like annual reports, application forms, or instructions — as PDFs or other document types that aren’t accessible by default. These online documents often lack headings, tags, alt text, and a logical reader order, making them virtually inaccessible to users with disabilities. And because many accessibility checkers focus on web pages, these issues often go undetected. 

Best practice: Fix documents to meet PDF/UA and WCAG standards, or offer the same content as accessible web pages when possible.

Example of a website that provides people using screen readers with too much instruction, i.e. tab to navigate

11. Providing Unnecessary Navigation Instructions

Sometimes, websites include detailed instructions like “Use the Tab key to navigate this page” or “Press Enter to activate a button " in an effort to be helpful. While well-intentioned, these kinds of instructions are usually unnecessary and can actually hinder the experience for users who rely on assistive technologies.

Screen reader users already know how to navigate, and their tools are designed to interpret standard HTML elements correctly. Over-explaining can clutter the experience and even create confusion if the instructions don’t align with how assistive tech actually works.

Best practice: Focus on building interfaces that follow accessibility best practices so users don’t need extra guidance. Let the technology do its job — and trust users to know how to use their tools.

How to Get Accessibility Right with AudioEye

The accessibility issues mentioned above clearly show that digital accessibility is not easy. There’s a lot around accessibility to keep in mind. Plus, the size of the internet and the speed of content creation make it that much harder to follow accessibility best practices. This can lead organizations to temporary or ineffective fixes (such as widgets or overlays). That’s where AudioEye comes in.

AudioEye is changing how organizations think about accessibility, making it fast, easy, and cost-effective to implement accessibility best practices at the start of the content creation process. We do this by taking a three-pronged approach to accessibility, combining automation and audits from accessibility experts and real users with disabilities. Plus, with accessibility testing throughout the development process, developers can proactively address issues before they impact users, minimizing the need for costly retroactive fixes.

The result: Accessible content usable for all — in half the time and half the cost.

Curious to see how many accessibility issues on your site? Use AudioEye’s free Web Accessibility Scanner to start your path to more accessible content today. 

Want to see what more AudioEye can do? Schedule a demo now.