Skip to main content
AccessibilityBrief

Blog

The 6 accessibility problems on almost every website, and how to fix them

· 4 min read

Low-contrast text, missing alt text, unlabelled form fields, empty links and buttons, and a missing page language. What each one breaks, how to find it, and the code to fix it.

Blog cover with the title: The 6 accessibility problems on almost every website, and how to fix them.

Every year, WebAIM tests the home pages of the top one million websites for accessibility problems. Every year the result is roughly the same: about 95 percent of those pages have problems that an automated test can detect, and most of the errors belong to the same six types.

That is good news. If you fix these six, you remove most of what an automated scan finds on a typical site, and you make the site easier to use for a lot of people: anyone with low vision, anyone using a screen reader, anyone filling in your forms on a phone in bright sunlight.

Here they are, from most to least common, with what each one breaks and how to fix it.

1. Text with too little contrast

What it is: text whose colour is too close to its background colour. Light grey on white is the classic example, often chosen because it "looks clean".

Who it affects: people with low vision, older visitors, and everyone reading a phone screen outdoors.

The rule: WCAG 2.2 asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (about 24 px, or 19 px bold). Placeholder text in form fields counts too.

The fix: darken the text or lighten the background until the ratio passes.

/* Before: #999999 on white is 2.8:1 */
.card p { color: #999999; }

/* After: #595959 on white is 7:1 */
.card p { color: #595959; }

On WordPress, Shopify and other themes the colour usually lives in the theme's typography or colour settings, so one change fixes every page. Check a colour pair with our free contrast checker, and see the full guide on fixing colour contrast.

2. Images without alt text

What it is: an image with no alt attribute. A screen reader then reads out the file name, such as "IMG underscore 2041 dot jpg", or skips the image without saying what it showed.

Who it affects: blind and low-vision visitors using a screen reader, and anyone whose images fail to load.

The fix: describe what the image means in that spot, in a short phrase. Images that are only decoration get an empty alt="", so screen readers skip them.

<!-- Before -->
<img src="/img/IMG_2041.jpg">

<!-- After: an informative image -->
<img src="/img/IMG_2041.jpg" alt="Red running shoe, side view">

<!-- After: a decorative divider -->
<img src="/img/divider.svg" alt="">

Don't start with "Image of": the screen reader already says it is an image. Shop platforms have an alt text field on every product image, and it is worth filling in for SEO too. More in our alt text checklist and the guide to missing alt text.

3. Form fields without a label

What it is: an input that only has placeholder text, or a visible label that isn't connected to the field in the code.

Who it affects: screen reader users, who hear only "edit text" with no idea what to type; people with memory or attention difficulties, who lose the placeholder as soon as they start typing; and anyone who taps the label expecting the field to get focus.

The fix: give every field a <label> connected with for and id, and keep it visible.

<!-- Before -->
<input type="email" placeholder="Email">

<!-- After -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">

Contact form plugins usually have a "show labels" or "label position" setting; switch from "placeholder only" to a visible label. See form fields without a label.

What it is: a link with nothing inside it that a screen reader can read. Most often an icon link (a social media logo, a cart icon) or a linked image without alt text.

Who it affects: screen reader users hear "link" and nothing else, and voice control users have no name to say to click it.

The fix: add text that says where the link goes. It can be visually hidden if the design only shows an icon.

<!-- Before -->
<a href="https://www.facebook.com/yourpage"><svg>…</svg></a>

<!-- After -->
<a href="https://www.facebook.com/yourpage" aria-label="Our Facebook page">
  <svg aria-hidden="true" focusable="false">…</svg>
</a>

The guide to links without a name has the steps for common platforms.

5. Buttons without text

What it is: the same problem on buttons: search, menu, close, play and "add to cart" buttons that show only an icon.

Who it affects: screen reader users hear just "button", so they can't tell the menu button from the search button.

The fix: give the button an accessible name.

<!-- Before -->
<button class="menu-toggle"><svg>…</svg></button>

<!-- After -->
<button class="menu-toggle" aria-label="Menu" aria-expanded="false">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

On most sites these buttons sit in the header template, so fixing them once fixes every page. See buttons without a name.

6. A missing page language

What it is: the <html> element has no lang attribute, so assistive technology has to guess the language of the page.

Who it affects: screen reader users. A wrong guess means English text read with, say, German pronunciation, which is very hard to follow. It also affects translation tools and hyphenation.

The fix: one attribute in the page template.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">

Most website builders set this from the site's language setting, so check that the setting is right. See missing page language.

How to find these on your own site

You don't need to guess. Any of these will show you where the six problems are:

  1. Run an automated check. Paste your address into our free checker above: it tests one page and shows every problem it finds with the fix. Free browser extensions such as WAVE and axe DevTools work too.
  2. Do the keyboard test. Put your mouse away and press Tab through the page. You'll notice icon-only buttons and links that show no focus, and forms you can't complete.
  3. Start with templates. The header, footer, navigation and product template appear on every page. A fix there fixes the whole site.

Automated checks find only part of the problems WCAG describes. Fixing these six is a strong start, not the finish line: keyboard and screen reader testing still matter.

The short version

  • Contrast: at least 4.5:1 for normal text.
  • Images: a short alt that says what the image means, or alt="" for decoration.
  • Forms: a visible <label> for every field.
  • Links and buttons: always a text name, even when only an icon shows.
  • Page language: <html lang="en">, or the language your page is in.

Got a question about one of these on your own site? Ask in our free Website Accessibility Help group on Facebook, where we answer every question.

Automated testing detects only a portion of WCAG issues. Manual testing is required to assess full conformance. This article is general information, not legal advice.

All blog posts