Common Website Accessibility Issues: What They Are and How to Fix Them

Common Website Accessibility Issues: what they are and how to fix them

Common Website Accessibility Issues affect people with visual, motor, auditory and cognitive disabilities. This article lists the typical problems, shows how to test them, and gives concrete fixes you can apply now.

Why accessibility matters

Accessible sites reach more users and reduce legal risk. Public guidance and standards include WCAG 2.1 and WCAG 2.2 at levels A and AA, WAI-ARIA for assistive technology, and laws such as the Equality Act 2010, the European Accessibility Act and Section 508 or the ADA in other jurisdictions. Use standards as your technical checklist.

Most common website accessibility issues and how to fix them

Missing or incorrect alternative text for images

What it is: Screen readers rely on alt text to describe images. Missing alt attributes leave users guessing.

How to test: Browse with a screen reader or inspect the HTML for img elements without an alt attribute or with empty alt when the image conveys meaning.

How to fix: Provide concise, informative alt text for meaningful images. Use empty alt for purely decorative images. Example: <img src=“logo.png” alt=“Brand name logo”>

Low colour contrast

What it is: Text and background colours with insufficient contrast are hard to read for low vision users.

How to test: Use a colour contrast checker. WCAG requires 4.5:1 for normal text and 3:1 for large text at level AA.

How to fix: Increase contrast by changing text or background colours or increase text size and weight.

Missing form labels and instructions

What it is: Inputs without labels or clear instructions confuse screen reader and keyboard users.

How to test: Navigate forms with a screen reader or inspect for missing label elements and missing aria-describedby for extra guidance.

How to fix: Use explicit labels and link them with for and id. Example: <label for=“email”>Email address</label><input id=“email” name=“email” type=“email”>

Keyboard and focus problems

What it is: Interactive elements must work with keyboard only. Focus should follow a logical order and be visible.

How to test: Navigate the page using Tab and Shift+Tab. Watch focus indicators. Attempt to use all controls with keyboard alone.

How to fix: Ensure all actionable elements are reachable by keyboard, do not remove native focus outlines without replacement, and keep DOM order logical for reading order.

Poor heading structure

What it is: Headings provide structure for screen reader users. Skipping levels or using non-semantic styling removes that structure.

How to test: Inspect heading tags for order and hierarchy. Use a screen reader to jump by headings.

How to fix: Use proper heading tags in order, for example h2 then h3. Do not style normal text to look like headings instead of using semantic tags.

Non-descriptive link text

What it is: Links labelled “click here” or “read more” do not tell users where they go.

How to test: List links and read them out of context. If they are ambiguous, they need work.

How to fix: Use clear text such as “Download the annual report (PDF)” or include the destination within the link.

Video without captions or audio description

What it is: People who are deaf need captions. People who are blind benefit from audio description for visual-only content.

How to test: Play media without sound and watch for captions. Check for a transcript or audio description options.

How to fix: Add synchronized captions and provide a transcript. For important visual-only content add an audio description track.

Missing semantic HTML or misused ARIA

What it is: ARIA should enhance native HTML when it cannot provide the required semantics. Overuse or incorrect ARIA can break assistive technology support.

How to test: Audit the DOM for custom controls that do not use native elements, and for ARIA roles that conflict with semantics.

How to fix: Prefer native HTML controls such as <button> and <select>. Use ARIA only when no native control fits and follow WAI-ARIA authoring practices.

Motion, animation and flashing content

What it is: Fast or flashing animations can trigger seizures or cause vestibular distress.

How to test: Identify animations that play automatically or repeat and check if they can be paused or turned off.

How to fix: Provide a setting to disable animations or respect the user’s prefers-reduced-motion media query.

Inaccessible documents and PDFs

What it is: Uploaded documents often lack structure, tags or text alternatives and can be unreadable by screen readers.

How to test: Try opening documents with a screen reader or check whether they are tagged and have selectable text.

How to fix: Export tagged PDFs from source files, provide an accessible HTML alternative, or include a structured text version.

How to test accessibility on a website

Automated checks

What to run: Use multiple automated tools to find obvious issues. They catch many missing attributes and contrast failures but not everything.

Manual checks

• Keyboard only navigation. Ensure everything interactive is reachable and usable.
• Screen reader review with tools such as NVDA or VoiceOver to hear content order and labels.
• Colour contrast checks for text and interactive components.
• Form completion and error handling using only the keyboard and screen reader.

User testing

Invite people who use assistive technology to perform real tasks. Their feedback finds issues tools miss.

A simple priority plan to fix accessibility issues (practical step-by-step)

1. Inventory: Crawl the site and list pages and components. Note where PDFs and media live.
2. Quick wins: Fix missing alt text, label simple forms, and restore visible focus. These are small changes with big impact.
3. Critical fixes: Resolve keyboard traps, major navigation problems, and contrast failures that block reading.
4. Component fixes: Make shared components semantic. Update design tokens for accessible colour choices.
5. Automate: Add accessibility checks to CI for regressions on new code.
6. Verify: Run manual testing and a small user panel before each release for high-impact pages.

Common developer mistakes and how to avoid them

• Avoid using ARIA when a native element already does the job. Native elements have built-in keyboard and accessibility behavior.
• Do not remove focus outlines without replacing them with a visible, high-contrast focus style.
• Do not rely only on automated tools. They miss context, reading order and real assistive technology interaction.
• Do not hide content visually with CSS while leaving it accessible to assistive tech unless you have a clear reason and use correct methods.

Quick checklist for developers and content editors

Issue	How to test	Quick fix
Missing alt for images	Inspect img alt attributes	Add meaningful alt or empty alt for decorative images
Low contrast	Contrast checker	Adjust colours or increase text size
Unlabelled form fields	Screen reader or inspect for label	Add label for or aria-labelledby
Keyboard traps	Tab through site	Ensure focusable elements and logical DOM order
Missing captions	Play media without sound	Add captions and transcripts

Standards and next steps

Follow WCAG 2.1 and 2.2 guidance for technical success criteria and consult WAI-ARIA documents for dynamic widgets. Combine automated checks with manual and user testing. Start with the quick wins and work through the priority plan every sprint.

If you want a short, actionable audit for a specific page, list the URL and the top three pages you care about. A targeted review will find the highest-impact fixes first.