Common Accessibility Issues

Accessibility issues rarely show up because a team doesn't care about accessibility — they show up because accessibility isn't always visible during normal development and testing. A page can look perfect to a sighted visitor using a mouse and still be genuinely difficult to use for someone relying on a screen reader or keyboard navigation. Here are the issues that turn up most often.

Missing image alt text

Images without alt text are effectively invisible to screen readers, or get announced only by their filename. This is usually the single most common accessibility issue on any given site, simply because it's easy to forget during a fast content update. It's covered in more depth in Why Image Alt Text Matters.

Missing form labels

Every form field — a text box, a dropdown, a checkbox — needs an associated label that a screen reader can announce. Without one, a screen reader user tabbing through a form hears something like "edit text" with no indication of what information is expected. This is especially damaging on forms that matter most to a business, like checkout flows or contact forms, since a visitor who can't understand what a field is for often can't complete the form at all.

Placeholder text is not a substitute for a real label — placeholders disappear once a user starts typing and aren't reliably announced by all screen readers in the first place.

Improper heading hierarchy

Headings (h1 through h6) aren't just a visual styling choice — screen reader users frequently navigate a page by jumping between headings, similar to how a sighted user might scan a page visually for section titles. When headings skip levels (a page going from an h2 straight to an h4, for example) or appear out of logical order, that navigation becomes confusing or misleading, since the structure no longer reflects the page's actual organization.

More than one H1, or no H1 at all

Every page should generally have exactly one h1 — the single most important heading that describes what the page is about. Multiple h1 elements, or none at all, weaken the page's structural clarity for both screen readers and search engines, since there's no longer a single clear answer to "what is this page primarily about."

Missing language identification

Every page should declare its primary language (via the lang attribute on the page's root element). Screen readers use this to select the correct pronunciation rules and voice — without it, a screen reader may default to the wrong language, making an otherwise well-written page difficult to understand when read aloud.

First heading isn't an H1

Related to heading hierarchy, but common enough to call out on its own: if the first heading a screen reader encounters on a page is an h2 or lower, it signals that the page's true main heading is either missing or mislabeled, which undermines the same structural navigation benefits mentioned above.

Why these issues cluster together

If a site has one of these issues, it often has several — they tend to stem from the same root cause: accessibility wasn't part of the original build process or template, so the same gap repeats across every page built from that template. This is actually good news once you've found the pattern: fixing the shared template or component often resolves the issue across dozens of pages at once, rather than requiring page-by-page fixes.

Where to start

If you're triaging accessibility findings for the first time, form labels and missing alt text are usually worth fixing first — they tend to block real tasks (submitting a form, understanding an image) rather than just creating friction. Heading structure and language identification matter too, but they affect navigation and comprehension more than they block a specific action outright.