The most common accessibility problems we find on websites

Introduction

Accessibility problems are often imagined as the result of unusual technical complexity: advanced applications, unfamiliar assistive technologies, or highly specialized interactions that only a small group of experts understand.

In practice, many of the barriers that appear repeatedly on websites are much more ordinary.

A button does not have enough contrast. An informative image has no useful text alternative. A heading looks correct visually but is not marked up as a heading. A form works with a mouse but becomes confusing with a screen reader. A modal opens, but keyboard focus remains somewhere behind it.

None of these patterns are exotic. They appear in everyday interfaces because websites reuse the same basic building blocks again and again.

That repetition is what makes accessibility problems especially important. A single poor decision in a shared component, design token, template, or content pattern can quietly spread across dozens or hundreds of pages.

The goal of this article is not to provide another checklist that encourages teams to fix isolated defects one by one. It is to look at some of the most common web accessibility issues, how they affect people, why they appear so frequently, and what they can reveal about the systems behind a website.

If you are new to accessibility, our introduction to web accessibility explains the broader foundation. If you want to understand the standard behind many of the requirements discussed here, see WCAG explained without the technical jargon.

Poor color contrast

Low contrast is one of the most familiar accessibility problems, but it is also easy to underestimate.

The issue is not limited to light gray body text on a white background. Contrast affects text, icons, form controls, focus indicators, states, and other visual information that people need to distinguish in order to understand or operate an interface.

A design may look elegant on a calibrated monitor in a controlled environment and still become difficult to read for someone with low vision, reduced contrast sensitivity, or simply a screen being used in bright daylight.

Problems also appear when text is placed over photography, gradients, or video. A combination that works in one part of an image may become unreadable in another.

The deeper problem is often systemic. If a low-contrast color combination is defined in a design token and then reused for secondary text, buttons, metadata, or disabled states, the same barrier can appear throughout the product.

That is why contrast should not be treated as a final visual adjustment. It belongs in the design system and should be tested in the contexts where colors will actually be used.

Missing or incorrect alt text

Images need different treatment depending on what they do.

An informative image may need alternative text because it communicates information that would otherwise be unavailable to someone who cannot see it. A decorative image may need an empty alt attribute so assistive technologies can ignore it. A functional image, such as an icon used as a control, needs an accessible name that communicates the action.

The common mistake is to treat alt text as a box that simply needs to be filled.

That can lead to descriptions that technically exist but do not help anyone. An alt such as "image123.jpg" is useless. A description that lists every visible object may be equally unhelpful if the purpose of the image is much simpler. On the other hand, leaving the alt empty for an image that communicates essential information removes that information entirely for some users.

Good alternative text depends on purpose and context, not just visual appearance.

A useful question is: if the image were unavailable, what information would someone need in order to understand the same point or complete the same task?

Broken heading hierarchy

Headings do more than make text larger.

They communicate the structure of a page. People scan headings visually to understand how content is organized, and many screen reader users navigate directly between headings to move efficiently through long pages.

Problems appear when heading levels are chosen for visual size rather than semantic structure, when text that looks like a heading is implemented as an ordinary paragraph, or when the hierarchy skips around without reflecting the relationship between sections.

A page can therefore look perfectly organized and still have a confusing underlying structure.

The goal is not to follow a mechanical rule that every page must use every heading level in order. The important point is that headings should represent the structure of the content and describe the sections they introduce.

This is one reason accessibility and content design are closely connected. Good structure helps both assistive technology users and anyone trying to scan a complex page quickly.

Inaccessible forms

Forms concentrate many accessibility problems in a small amount of interface.

A form may contain visible labels but fail to associate them correctly with the fields they describe. Required fields may be communicated only through color. Instructions may appear too late. Error messages may be difficult to find or may not explain how to correct the problem.

A user can also encounter technically accessible controls arranged in a sequence that is unnecessarily confusing.

W3C's forms guidance emphasizes clear labels, instructions, grouping, and feedback because forms are both visually and cognitively complex. Properly associated labels also allow assistive technologies to identify the purpose of controls correctly.

The most useful way to evaluate a form is not simply to ask whether every field exists in the accessibility tree. Ask whether a person can understand what information is required, enter it using their preferred interaction method, recognize when something has gone wrong, and recover from the error without losing their progress.

A form is a process, not a collection of inputs.

Missing keyboard focus

Keyboard accessibility and visible focus are related, but they are not the same thing.

An element may technically receive keyboard focus while providing almost no visible indication of where that focus is.

This often happens when a site's CSS removes the browser's default outline in order to achieve a cleaner visual style without replacing it with an equally visible alternative.

For someone navigating with Tab, that turns an otherwise operable page into a guessing exercise.

Visible focus should make the current position clear. It also needs to remain visible across different backgrounds, components, and states.

The solution is not necessarily to preserve every browser default exactly as it is. Focus indicators can be designed to fit the visual language of a product. But removing them without providing a strong replacement eliminates information that keyboard users rely on.

Keyboard traps

A keyboard trap occurs when a person can move focus into part of an interface but cannot move it out using the keyboard.

This can happen in modals, menus, embedded widgets, custom controls, or components with poorly managed JavaScript behavior.

The impact can be severe. A mouse user may simply click somewhere else. A keyboard user can become effectively stuck inside the component.

Some interfaces do need to contain focus temporarily. A modal dialog, for example, generally keeps keyboard interaction inside the dialog while it is open. That is not the same as a trap, because the user must still be able to reach all relevant controls, close the dialog, and return to a meaningful place in the underlying page.

The distinction is whether the interaction is intentionally managed or whether the user has lost control.

Accessibility barriers often appear inside ordinary interface patterns that otherwise look polished and complete.

Ambiguous links

Links should help people understand where they are going.

Text such as “click here,” “read more,” or “learn more” can make sense when someone reads the entire surrounding paragraph. But people do not always encounter links in that context.

Screen reader users may navigate through links directly. People scanning a page visually may also jump between links without reading every sentence around them.

If several links all say “Learn more,” it becomes much harder to predict which destination each one opens.

Good link text does not need to be long. It needs to communicate enough purpose that the destination or action is understandable.

This is also a content quality issue. Specific links reduce uncertainty for everyone.

Incorrect button semantics

Buttons and links may look nearly identical in a design system, but they have different purposes.

A link normally takes the user somewhere.

A button performs an action.

Problems appear when visual styling becomes more important than semantic behavior: a clickable div is styled to look like a button, a link is used to trigger an action, or a custom component is built without recreating the keyboard and accessibility behavior people expect from a native control.

For a mouse user, the interface may still appear to work.

For keyboard users and people using assistive technologies, the element may not be announced correctly, may not receive focus, or may respond to the wrong interaction.

Native HTML elements already provide a significant amount of expected behavior. Custom components can be accessible, but they require teams to understand and reproduce those expectations deliberately.

Inaccessible modals

Modals are not inherently inaccessible.

The problems usually come from how they are implemented.

When a modal opens, keyboard focus should move somewhere meaningful inside it. The user should be able to navigate its controls in a logical order, understand that a dialog has opened, and close it using expected interaction methods.

While the modal is active, focus should not wander into unrelated content behind it. When the modal closes, focus should normally return to a sensible location, often the control that opened it.

If any of those details are missed, the experience can become confusing.

A visual user sees the modal immediately because the screen changes. A screen reader or keyboard user needs equivalent structural and interaction cues.

This is a good example of why accessibility cannot be evaluated from screenshots alone. The barrier exists in behavior over time.

Missing labels and instructions

Not every control explains itself visually.

Icon-only buttons, filters, search controls, selectors, date fields, uploads, and unfamiliar custom components often depend heavily on context.

If that context is not available programmatically, assistive technology users may encounter a control with no understandable name or purpose.

Forms have a related problem when placeholder text is used instead of a persistent label. Once the user begins typing, the instruction may disappear. Placeholder text can also be visually subtle and is not a reliable substitute for a proper label.

W3C recommends that controls have labels that describe their purpose and that users receive instructions where they are needed to complete a form successfully.

This is not about adding more text everywhere. It is about making sure the interface provides enough information at the moment someone needs it.

Improper use of ARIA

ARIA — Accessible Rich Internet Applications — provides semantics that can help assistive technologies understand custom interface components and dynamic states.

It is extremely useful when native HTML cannot express what a component needs.

It is also easy to misuse.

An incorrect role can tell assistive technology that an element behaves differently from the way it actually behaves. An ARIA state may be declared once and then fail to update when the interface changes. An accessible name can conflict with visible text. Additional ARIA can be added to native elements that already provide the correct semantics.

The WAI-ARIA specification explicitly encourages authors to use native host-language semantics for controls whenever possible.

The practical principle is straightforward: use native HTML when it already provides the semantics and behavior you need. Use ARIA when it adds information that is genuinely necessary, and make sure the resulting behavior matches what the ARIA communicates.

More accessibility metadata does not automatically mean more accessibility.

Zoom and responsive issues

A responsive website can work beautifully at common mobile breakpoints and still fail when a user zooms the page or enlarges text.

Content may become clipped. Navigation may disappear. Fixed headers can consume most of the viewport. Dialogs may extend beyond the visible area. Controls can overlap, and horizontal scrolling may appear where it makes the page difficult to use.

These problems matter particularly to people with low vision who enlarge content in order to read it comfortably.

The key distinction is between adapting to a device and adapting to the user's presentation needs.

Responsive design should preserve meaning and functionality as available space changes. That includes changes caused by browser zoom, text resizing, orientation, and other user settings — not only the width of a phone screen.

This is why accessibility testing needs to include more than a few preset viewport sizes.

Why automated testing doesn't catch everything

Automated accessibility tools are valuable.

They can scan large numbers of pages, identify certain code-level problems consistently, and catch issues that would otherwise be easy to overlook. Used during design and development, they can help teams detect problems before those problems reach production.

But automated tools cannot evaluate the entire experience.

W3C's guidance on accessibility evaluation tools makes this limitation explicit: some checks cannot be automated and require human judgement. Tools can assist with accessibility evaluation; they cannot determine accessibility on their own.

A scanner may be able to identify an image with no alternative text. It is much less capable of deciding whether existing alt text communicates the image's actual purpose.

It may detect some contrast failures. It cannot reliably tell whether a multi-step process makes sense.

It may identify certain semantic errors. It cannot experience a confusing focus order in the same way a keyboard user does.

It may confirm that a button has an accessible name. It cannot always tell whether that name is useful in the surrounding context.

This distinction matters because automated scores can create false confidence. A page with a high score may still contain serious barriers that require manual interaction to discover.

A meaningful accessibility review therefore combines automation with manual testing, keyboard use, zoom and reflow checks, assistive technology testing, content review, and — where possible — research involving people with disabilities.

Automated tools can identify important accessibility problems, but they cannot evaluate the entire human experience.

Fix the pattern, not just the page

The most useful moment in an accessibility review often comes after several individual issues have been documented.

Patterns begin to appear.

The same low-contrast button exists on twenty pages.

Every form uses the same error component that fails to communicate errors clearly.

Multiple modals inherit the same focus-management problem.

Every card component contains the same ambiguous “Learn more” link.

At that point, the website does not really have twenty unrelated button failures or ten unrelated modal failures. It has a shared pattern that is producing the same barrier repeatedly.

Fixing individual pages may remove visible instances of the problem, but it does not necessarily prevent the problem from returning.

The stronger solution is often to identify the source.

That source might be:

• a design token;
• a reusable component;
• a CMS template;
• an editorial rule;
• a development convention;
• a third-party integration;
• or a gap in the team's review process.

This is why accessibility audits are most useful when they do more than produce a list of defects. Individual findings matter, but teams also need to understand which findings share the same underlying cause.

When an inaccessible typographic choice is built into a shared pattern, the same barrier can spread across every interface that reuses it.

A design system can make this relationship especially visible. Shared components and tokens multiply decisions across a product. If those decisions are accessible, the system can help good patterns scale. If they contain barriers, those barriers scale too.

This is also why accessibility should be part of web design from day one. Preventing a problem in the component or pattern is usually more sustainable than finding every instance after the product has grown.

Finding individual accessibility issues is useful. Understanding why they keep appearing is more valuable.

A thorough accessibility review should identify both: the barriers people encounter and the components, patterns, and processes that are producing them.

That is how accessibility work moves from repeatedly repairing pages toward improving the system that creates them.