Most Common Accessibility Issues (and How to Avoid Them)

Accessible websites are an essential part of everyday life for many people. Without accessibility, users may be unable to access services and information that others take for granted. This article draws on my experience in accessibility testing across a wide range of websites—from e-commerce platforms to government portals—to highlight the most common accessibility mistakes developers make. It also explores why accessibility is often overlooked, how European legislation has made it a critical requirement, and why accessibility matters from ethical and business perspectives.

What’s accessibility, and why should you care about it?

Digital accessibility means designing and building websites, applications, and digital products so that people with permanent or temporary disabilities can use them effectively. This includes users with visual, hearing, motor, and cognitive disabilities, as well as situational limitations such as poor lighting, temporary injuries, or noisy environments.

• Visual accessibility supports users who are blind or have low vision. This includes sufficient color contrast, meaningful alternative text for images, and content that works well with screen readers.
• Hearing accessibility supports users who are deaf or hard of hearing. Videos and audio content should include accurate captions, transcripts, or live subtitles where applicable.
• Motor accessibility supports users with limited movement or coordination, including those who rely on keyboards, switch devices, or speech recognition software instead of a mouse.
• Cognitive accessibility supports users with learning disabilities or neurological conditions. Clear structure, readable fonts, consistent navigation, and adequate spacing all help reduce cognitive load.

Accessibility benefits everyone, not only people with disabilities, and improves overall usability, clarity, and product quality.

The importance of accessible design and WCAG recommendations

The Web Accessibility Initiative (WAI) maintains the Web Content Accessibility Guidelines (WCAG), the global technical standard for digital accessibility. WCAG provides testable success criteria organized under four principles: content must be Perceivable, Operable, Understandable, and Robust.

The issues discussed below are among the most common WCAG 2.1 and 2.2 failures found during accessibility audits. Most of them are preventable when accessibility is considered early in design and development.

WCAG 1.4.3 and 1.4.11 - Insufficient contrast between element and background

Let’s start with an issue that anyone who relies on visual design can easily relate to: color contrast. One of the most common accessibility mistakes on websites and applications is insufficient contrast between elements and their background.

• WCAG 1.4.3 (Minimum contrast) requires that text stands out clearly against its background, particularly for users with low vision or color vision deficiencies. 
• WCAG 1.4.11 (Non-text contrast) extends this requirement to essential non-text elements, such as buttons, icons, and focus indicators, ensuring that users can perceive interactive components and understand what is happening on the screen.

In practice, designers often prioritize aesthetics over usability, resulting in visually appealing but difficult-to-read interfaces. Common issues include light gray text on white backgrounds or relying on color alone to communicate meaning.

The good news is that fixing contrast issues is relatively simple and can have a significant impact. The example below illustrates the difference clearly.

High contrast between text and background is essential not only for readability but also for perceiving visual elements accurately. In the high-contrast example, the text remains readable even for users with reduced eyesight. By comparison, low-contrast text can be difficult to perceive—even for users with near-perfect vision.

For example, with −1.5 eyesight, I can read the high-contrast text without glasses, while the low-contrast version is nearly impossible to read.

WCAG 1.3.2 - Meaningful sequence

Some WCAG recommendations can be challenging for sighted users to understand because their effects are only apparent when using a screen reader or similar assistive technology. Sighted users can infer the logical order of content visually, but screen reader users rely entirely on the order in which text and elements are announced.

In the example above, the text order does not follow a logical sequence, making it confusing for users navigating with a screen reader. To address this, the content structure in the code should reflect the intended reading order, ensuring elements appear sequentially rather than jumping between sections. Additionally, proper use of headings and semantic markup helps ensure that screen readers announce content in a meaningful and understandable way.

WCAG 1.4.4 - Resize text

Another important visual accessibility recommendation is allowing text to be resized up to 200% without loss of functionality. Many modern websites appear visually robust and feature-rich at their default size, but when text is increased, layouts often break, navigation becomes difficult, and some content may become inaccessible.

Resizing text without breaking the layout requires careful coordination between design and development. Text scaling affects not only the content itself but also images, interactive elements, and page structure.

Designers should use flexible layouts, responsive units, and scalable components to ensure readability at larger sizes. Websites that cannot accommodate a 200% text increase are failing a critical accessibility requirement, which can significantly impact users with low vision.

WCAG 2.1.1 - Keyboard

Keyboard accessibility is another recommendation that is often overlooked by developers. It ensures that all content and functionality can be accessed using only a keyboard—critical for users who cannot use a mouse due to a motor disability or situational limitations.

WCAG 2.1.1 (Keyboard) requires that all functionality be operable via keyboard, while related criteria include:

• 2.1.2 (No keyboard trap): Users must be able to navigate freely without getting stuck on any page or component.
• 2.1.4 (Character key shortcuts): Keyboard shortcuts should not trigger unintended actions and must be easily disabled if necessary.

In practice, 2.1.1 and 2.1.2 are the most noticeable issues during testing.

How to fix or avoid this:

• Ensure all interactive elements receive focus when navigating with the Tab or Shift+Tab keys.
• Non-interactive elements, such as plain text or static images, should not receive keyboard focus.
• Screen reader users should be able to navigate and perceive all meaningful content, whether interactive or not.
• Each interactive element should have a properly assigned name, role, and value (WCAG 4.1.2), which ensures assistive technology can accurately convey its purpose to users.

WCAG 4.1.2 - Name, role, value

Another common screen reader issue occurs when elements are missing a defined name, role, or value. Without this information, assistive technology cannot accurately convey the purpose of an element, making navigation confusing and inefficient for users.

As shown in the example above, a button without a role or descriptive label may be announced simply as “button,” which does not provide enough context. 

The example below shows you how, by specifying the element’s role and giving it a meaningful name—such as “Add ‘Product Name’ to cart, button”—screen readers can communicate its function clearly. This ensures users understand not only the action, but also which product will be affected.

Implementing this fix is straightforward: developers should assign descriptive names, roles, and values to all interactive elements. Further accessibility considerations, such as providing updates when the cart changes, are addressed under WCAG 4.1.3 – Status Messages, which will be discussed in the next section.

WCAG 4.1.3 - Status messages

addresses how screen reader users are informed when content changes on the page, such as a form submission error or a successful save. This criterion requires that status messages be announced automatically by assistive technology without moving focus.

Many developers assume that visually updating the DOM is enough, but screen readers may not detect these changes unless they are properly marked up. Without ARIA attributes such as aria-live or role="status", important feedback can go unnoticed.

For example, as shown below, a message that is added to the page visually but lacks these attributes will not be announced to a screen reader user.

By contrast, using aria-live and aria-atomic ensures that status messages are fully and accurately communicated, as shown in the image below.

When status messages are not properly announced, users may be unaware whether an action succeeded or failed. For instance, during a registration process, an unannounced error message can prevent a user from completing the task. Correctly implemented status messages ensure that all users receive timely and critical feedback, improving accessibility and usability.

Regulations and legal requirements

Designing accessible websites is not just a best practice—it is increasingly a legal requirement. In Europe, two major regulations set minimum standards for digital accessibility:

European Accessibility Act (EAA) – Directive (EU) 2019/882

The EAA establishes accessibility requirements for a wide range of products and services, including websites, mobile apps, e-books, and financial services. Its goal is to harmonize national rules across the EU, reducing costs for businesses while ensuring equal access for people with disabilities and older adults. The Act has been in effect since June 28, 2025, with transitional periods for pre-existing products.

Web Accessibility Directive (WAD) – Directive (EU) 2016/2102

The WAD requires all public sector websites and mobile applications in the EU to meet WCAG accessibility standards. Summaries of the Directive are available in all official languages.

These regulations apply to a range of organizations, from public sector bodies to private companies providing digital services, e-commerce platforms, or essential services such as banking, transport, and telecommunications. Large enterprises are generally required to comply, while smaller micro-enterprises may be exempt.

Americans with Disabilities Act (ADA) – United States

The ADA is a civil rights law that prohibits discrimination against people with disabilities in all areas of public life, including websites and digital services. While the ADA does not explicitly reference WCAG, many courts and organizations use WCAG standards as a benchmark for compliance. Businesses operating in the U.S. are at risk of legal action if their digital products are inaccessible to people with disabilities.

The bottom line

Accessibility is no longer optional—it is a legal obligation, a business advantage, and a critical step toward digital equality. By addressing common accessibility mistakes, developers and designers can ensure that all users—including people with disabilities—can navigate websites, complete tasks, make purchases, and participate fully in online communities.

Accessible design benefits everyone: it improves usability, expands your audience, reduces legal risk, and demonstrates a commitment to inclusion and social responsibility. By following WCAG guidelines and designing with accessibility in mind from the start, teams can create digital experiences that work for everyone, regardless of ability.