The Most Common Accessibility Issues (and How to Fix Them)

Across the websites we scan, the same handful of accessibility issues come up again and again — and the good news is they’re among the easiest to fix. If you tackle just these, you’ll resolve the majority of the defects that block real users and show up in compliance complaints. Here are the most common offenders, why they matter, and how to fix each one.

1. Low color contrast

Why it matters: light-gray text on white, or pale text on a colored button, is unreadable for people with low vision — and for anyone outdoors in sunlight. The fix: ensure body text meets a 4.5:1 contrast ratio against its background (3:1 for large text, 18.66px bold or 24px regular and up), and 3:1 for icons and UI borders. Check brand colors against white and against each other; darken the foreground or background until it passes.

2. Images without alt text

Why it matters: screen readers announce the file name (or nothing) when an image has no alt attribute, so informative images become invisible. The fix: give every meaningful image concise, descriptive alt text that conveys its purpose; use empty alt="" for purely decorative images so they’re skipped. Don’t start with “image of” — the screen reader already says that.

3. Form fields without labels

Why it matters: a placeholder is not a label — it disappears on input and isn’t reliably announced. Unlabeled fields leave screen-reader users guessing. The fix: associate a visible <label> with every input viafor/id. Where a visible label isn’t possible, use aria-label or aria-labelledby — but a real label is best.

4. Buttons and links with no accessible name

Why it matters: icon-only buttons (a bare hamburger, a × close, a magnifying glass) announce as “button” with no indication of what they do. The fix: add an aria-label (e.g. aria-label="Close") or visually hidden text. For links, make the text describe the destination — avoid a sea of “click here.”

5. Missing or invisible focus indicators

Why it matters: keyboard users navigate by focus; if the focus ring is removed in CSS (outline: none) with nothing put back, they can’t tell where they are. The fix: never remove focus styles without replacing them. Provide a clearly visible focus indicator (an outline or ring) on every interactive element, and consider :focus-visible so it shows for keyboard users.

6. Keyboard traps and unreachable controls

Why it matters: custom widgets (modals, carousels, menus) sometimes capture focus so it can’t move on, or can’t be reached at all with the Tab key. The fix: make sure every interactive element is reachable and operable by keyboard, and that focus can always move away (Esc closes dialogs, focus returns sensibly). Prefer native elements (<button>, <a>) over <div> with click handlers.

7. Skipped heading levels and no landmarks

Why it matters: screen-reader users navigate by headings and landmarks; a page that jumps from h1 to h4, or has no <main>/<nav>, is hard to scan. The fix: use one h1 per page and a logical heading order; wrap regions in semantic landmarks (header, nav, main, footer).

8. Content that breaks on zoom (reflow)

Why it matters: people who zoom to 200–400% need content to reflow into a single column; if it forces horizontal scrolling or clips text, it’s unusable. The fix: build responsive layouts that reflow to a 320 CSS px width (WCAG 1.4.10) without two-dimensional scrolling, using relative units and avoiding fixed-width containers.

Find yours in a couple of minutes

Most of the issues above are detectable automatically, which means you don’t have to hunt for them by hand — a scan will tell you which ones your site has, how severe they are, and which pages they affect. The judgment calls that remain (is this alt text meaningful? does the reading order make sense?) are where manual review comes in; we describe that split in our methodology, and the WCAG 2.2 checklist covers the full standard.