The 10 Most Common Website Accessibility Failures (and How to Fix Them)

97% of website homepages have detectable accessibility failures. You’re almost certainly not an exception. But the good news is this: most of those failures are the same 10 problems, and they’re quick to fix.

This guide walks through the most common failures we find when screening UK websites, exactly what they are, why they’re a problem, and how to fix them. Most of these are one-step fixes. None require a website redesign.

1. Missing Alt Text on Images

What it is: Informative images on your page have no alternative text, or images that should have descriptive text have only a generic filename.

Why it’s a problem: Blind users and users with low vision use screen readers to navigate websites. A screen reader can’t “see” images — it needs alt text to describe them. An image with no alt text is invisible to screen readers. If the image shows a product, a graph, a logo in a link, or any information, a screen reader user misses it entirely.

How common it is: About 54% of homepages have missing or inappropriate alt text (WebAIM Million study).

How to fix it:

• Every informative image needs descriptive alt text that conveys the same information as the image. If the image shows a red dress, write alt="red sleeveless A-line dress"
• Decorative images (spacers, dividers, background images) need empty alt: alt=""
• Logo images that are links need alt text describing the link: alt="Bartram Compliance home", not alt="logo.png"
• For complex images (graphs, infographics), provide both alt text and a longer description in the page content
• Don’t use “image of” or “picture of” — that’s redundant. A screen reader already knows it’s an image

How to check: Right-click on an image, inspect it, and look for the alt attribute. If it’s missing or generic, fix it.

2. Inadequate Colour Contrast

What it is: Text that doesn’t meet the WCAG AA colour contrast ratio of 4.5:1 for normal text or 3:1 for large text.

Why it’s a problem: People with low vision, colour blindness, and older users struggle to read text with low contrast. Light grey on white, dark blue on black, or other low-contrast combinations are illegible for many users.

How common it is: About 81% of homepages have at least one contrast failure (WebAIM Million).

How to fix it:

• Normal text (14px or less): contrast ratio must be at least 4.5:1
• Large text (18pt+ or bold 14pt+): contrast ratio must be at least 3:1
• Use a contrast checker tool (Chrome DevTools, WebAIM Contrast Checker, or similar) to test colour combinations
• If you have light grey text, darken it. If you have light text on a light background, either darken the text or change the background
• Test on different screens and at different brightness levels — what looks okay on a bright monitor might be illegible on a laptop in sunlight

How to check: Use the colour contrast checker in Chrome DevTools (Inspect > Computed > scroll to find the color contrast ratio) or WebAIM’s contrast checker.

3. Non-Keyboard-Navigable Elements

What it is: Interactive elements (buttons, menus, sliders, custom widgets) that only respond to mouse clicks and can’t be accessed or used with keyboard navigation.

Why it’s a problem: Users with motor impairments, blind users, and users of switch devices navigate with keyboards, not mice. If an interactive element only responds to clicks, these users are locked out entirely.

How common it is: Very common in sites with custom JavaScript menus, sliders, and interactive widgets.

How to fix it:

• Every interactive element (link, button, form field, custom widget) must be reachable by Tab key and usable without a mouse
• Test by tabbing through your entire site. Can you reach every button and link? Can you click it or activate it with Enter or Space?
• For custom JavaScript widgets (dropdowns, modals, sliders), add tabindex="0" to make them focusable, and add keyboard event handlers (Enter, Space, Arrow keys as appropriate)
• Don’t use <div> or <span> as buttons — use <button> elements, which are keyboard-accessible by default
• Ensure Tab order is logical — Tab moves forward through the page in a sensible order

How to check: Tab through your site with the keyboard only. If you can’t reach an element or use it, it’s not keyboard-accessible.

4. Missing Form Labels

What it is: Form fields (input boxes, select dropdowns, textareas) that don’t have associated <label> elements.

Why it’s a problem: Screen readers need labels to tell users what information each field is asking for. A form without labels is unusable for screen reader users — they have no idea what to type into each field.

How common it is: About 46% of homepages have form labelling issues.

How to fix it:

• Every <input>, <select>, and <textarea> needs a <label> with a for attribute that matches the field’s id:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

• Don’t use placeholder text as a substitute for labels. Placeholders disappear when the user starts typing
• Required fields need a visible and programmatic indicator (e.g., a red asterisk with aria-required="true")
• Error messages need to be linked to the field using aria-describedby
• Help text (hints about what format to use) should be associated with the field using aria-describedby

How to check: Inspect a form field and look for an associated <label>. If it’s missing, add it.

5. Broken Heading Hierarchy

What it is: Pages that use heading levels (H1, H2, H3) illogically — skipping levels (H1 → H3, no H2), using multiple H1s, or using headings for styling rather than structure.

Why it’s a problem: Screen reader users navigate by headings. A broken heading hierarchy breaks navigation. A user might jump from H1 to H3, missing the H2 section entirely. Or they might find eight H1s on one page, making it impossible to understand the page’s structure.

How common it is: Very common in sites built with page builders or where designers used heading styles for visual effect.

How to fix it:

• Use one H1 per page (usually the page title)
• Use H2, H3, H4 in logical order. Don’t skip levels. If you need H3, there should be an H2 above it
• Use headings to structure content, not to style text. If you want text to look like a heading but it’s not a structural heading, use CSS styling on a <p> or <div>
• Check your heading order with a heading checker tool (Chrome DevTools has a “Headings” view, or use the WAVE extension)

How to check: Use DevTools to view the heading structure or use a screen reader to listen to headings. The order should be logical and non-skipping.

6. Inaccessible PDFs and Documents

What it is: PDF files, Word documents, or Excel spreadsheets published on your website without accessible structure, text layers, or tags.

Why it’s a problem: Many PDFs are just scanned images of documents with no underlying text. A screen reader can’t read an image. Even PDFs with text need proper tagging (headings, lists, table structure) to be navigable by screen readers.

How common it is: Very common. Many businesses publish documents without thinking about accessibility.

How to fix it:

• Export documents from Word or PowerPoint as PDFs rather than scanning and uploading images
• Use proper heading styles in Word before exporting (Heading 1, Heading 2, not bold text)
• For spreadsheets, use table headers and structure
• Use tools like Acrobat Pro to add tags to existing PDFs, or use third-party PDF remediation services
• For long reports, consider also publishing as HTML — it’s more accessible and performs better on mobile
• Add a note on the page: “If you need an accessible version of this document, contact us [link to contact]”

How to check: Try opening the PDF in a screen reader or a PDF accessibility checker. If the text isn’t readable, it needs remediation.

7. Low-Vision Unfriendly Text Sizing and Zoom

What it is: Text that can’t be resized or zoomed without breaking the page layout, or text set too small to read at normal zoom levels.

Why it’s a problem: Users with low vision need to enlarge text. If your page is built with fixed font sizes that don’t scale, or if text becomes unreadable or breaks layout at 200% zoom, you’ve created a barrier.

How common it is: Less common than some failures, but significant on sites with small body text (12px or below) or fixed layouts.

How to fix it:

• Use relative font sizes (rem, em, %) rather than fixed pixels. This allows users to scale text globally via browser settings
• Test at 200% zoom in your browser (Ctrl/Cmd + scroll or Ctrl/Cmd + Plus sign). Text should remain readable and nothing should be cut off
• Body text should be at least 14–16px by default (larger for older users)
• Ensure line spacing is adequate (1.5x or higher)
• Avoid long lines of text (more than 80 characters per line is hard to read)

How to check: Zoom your page to 200% in the browser. Can you still read the content? Do you have to scroll horizontally?

8. No Focus Indicator

What it is: Interactive elements (links, buttons, form fields) that have no visible focus indicator when navigated to by keyboard.

Why it’s a problem: Keyboard users need to see where focus is. Without a focus indicator, it’s impossible to know which element you’re on. This makes keyboard navigation frustrating and often impossible.

How common it is: Common in sites where CSS is used to remove the default browser outline without replacing it with a custom indicator.

How to fix it:

• Keep the default browser focus outline (don’t use outline: none)
• Or add a custom focus indicator that’s clear and high-contrast:

button:focus {
  outline: 3px solid #0066cc;
  outline-offset: 2px;
}

• The focus indicator should have high contrast (4.5:1) against the background
• Use consistent focus indicators across the site

How to check: Tab through your site. When focus moves to each element, is there a visible outline, border, or background change? If not, add one.

9. Link Text That Doesn’t Describe the Link

What it is: Links with text like “Click here,” “Read more,” “Learn more,” or “Link” that don’t describe where the link goes.

Why it’s a problem: Screen reader users often browse by links only, hearing the link text in isolation. “Click here” tells them nothing. A user navigating by links hears “Click here,” “Learn more,” “Click here,” “Learn more” — totally uninformative.

How common it is: Very common in sites with generic link text.

How to fix it:

• Make link text describe the destination: “Download our accessibility guide” instead of “Click here”
• If you must use “Learn more,” provide context in the surrounding text or use aria-label:

<p>We offer three pricing tiers. <a href="/pricing" aria-label="Learn more about pricing tiers">Learn more</a></p>

• Don’t use URLs as link text (<a href="/about">example.com/about</a>)
• If images are links, use alt text to describe the link: <a href="/"><img src="logo.png" alt="Bartram Compliance home"></a>

How to check: Listen to your site with a screen reader or use the WAVE extension, which highlights link text. Does each link make sense in isolation?

10. Missing Language Declaration

What it is: The HTML page doesn’t declare the language using the lang attribute on the <html> tag.

Why it’s a problem: Screen readers need to know what language a page is in to pronounce text correctly. English text pronounced with French phonetics is incomprehensible.

How common it is: About 17% of homepages (WebAIM Million).

How to fix it:

• Add the lang attribute to the opening <html> tag:

<html lang="en">

• If you have content in multiple languages, specify language for those sections:

<p>This is English. <span lang="fr">Ceci est du français.</span></p>

• Use the correct language code (en for English, fr for French, etc.)

How to check: Inspect the <html> tag at the top of your page. Does it have lang="en" (or your language)?

How to Prioritise Fixes

If you find many failures, prioritise in this order:

1. Colour contrast. Quick win, affects many users.
2. Alt text. Quick win, affects visually impaired users immediately.
3. Form labels. Quick win, affects screen reader users on interactive pages.
4. Heading structure. Moderate effort, affects navigation.
5. Keyboard navigation. More effort, affects motor-impaired and blind users.

Most sites can address 70–80% of automated failures in a few hours of work.

What’s Next

If you want a baseline scan that identifies exactly which of these issues affect your site and in what priority order, Bartram Web screens your website and delivers a report you can act on immediately.

For more context on the legal obligations behind these fixes, see WCAG 2.2 Explained and Equality Act Website Obligations.