Most accessibility issues on the web aren’t rare or exotic. WebAIM’s annual scan of the top one million home pages finds the same six issue types year after year, and in its 2026 report those six accounted for about 96% of all the errors it detected. Low-contrast text alone appeared on 83.9% of home pages.
That concentration is useful. If you manage a large site, fixing the six most common accessibility issues removes most of the barriers an automated scan can see, and many of the fixes sit in a template or a component, so one change repairs every page that uses it. This article covers what each issue is, the WCAG 2.2 success criterion it fails, how to fix it, and who on your team usually owns the fix.
What are accessibility issues?
An accessibility issue is any barrier that makes it difficult or impossible for a person with a disability to equally access, navigate, or engage with the content on your website. Most accessibility issues are also a failure of a specific success criterion in the Web Content Accessibility Guidelines (WCAG), the W3C standard that accessibility laws and policies commonly reference. Naming the criterion matters, because it tells the person fixing the issue exactly what the requirement is.
To understand how accessibility issues can occur, you need to understand how people with disabilities access and use websites. The types of disabilities to be aware of are:
- Blindness and low vision
- Deafness and hearing loss
- Limited movement
- Speech disabilities
- Neurological limitations
- Cognitive limitations
- Temporary or situational impairments
How an individual with a disability accesses websites varies with the type of disability and their personal preferences. Some people can’t use a mouse and rely on keyboard-only navigation. Others use assistive technology, such as screen readers that read the contents of the website aloud, or sip and puff devices that let a user without mobility in their arms or hands navigate the website using the power of their breath.
The six most common accessibility issues
WCAG 2.2, the current W3C Recommendation, has 86 success criteria, and not all of them will apply to your website. The six issues below are the ones that turn up on most websites, ranked by how many of the top one million home pages had each one in WebAIM’s 2026 scan.
1. Low-contrast text
Text that doesn’t stand out enough from its background is hard to read for people with low vision, and for everyone reading a phone in sunlight. WCAG 2.2 success criterion 1.4.3 Contrast (Minimum), at Level AA, requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (at least 18 point, or 14 point bold). Found on 83.9% of home pages.
The fix: check your brand palette against those ratios once, then fix the colors at the design-system level so every page inherits them. Use the color contrast checker to test a pair. Design usually owns this one, with content teams watching for text placed over images.
2. Missing alternative text for images
People using screen readers rely on a text alternative to understand an image they can’t see. Success criterion 1.1.1 Non-text Content, at Level A, requires one for every informative image. Found on 53.1% of home pages.
The fix: give each informative image an alt attribute that says what the image conveys in context. For an image of a park, a fitting alt text could be “Aerial view of Central Park in New York.” A purely decorative image still needs the attribute, but left empty (alt=""), so screen readers skip it. Content teams own this, which is why it belongs in the publishing workflow rather than in a cleanup project. For what good alt text looks like, see how to write alt text that makes meaning obvious.
3. Missing form input labels
A form field without a programmatically associated label leaves screen reader and speech input users guessing what to enter. Success criteria 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions, and 4.1.2 Name, Role, Value, all at Level A, cover this. Found on 51.0% of home pages.
The fix: give every field a visible <label> element whose for attribute matches the field’s id. Placeholder text inside the field is not a label, because it disappears as soon as someone starts typing. Developers own the markup, and designers own keeping the label visible.
4. Empty links
A link with no text, such as an icon or an image link with no alternative text, is announced to a screen reader user as just “link,” with no clue where it goes. Success criterion 2.4.4 Link Purpose (In Context), at Level A, requires that the purpose of each link can be determined from its text or its context. Found on 46.3% of home pages.
The fix: give every link an accessible name. If a question mark icon links to your support pages, its accessible name should say “Customer support.” For a linked image, the image’s alt text should describe where the link goes, not what the image shows. Developers usually own icon links in templates, and content teams own linked images in the body.
5. Empty buttons
A button with no accessible name, typically an icon-only button such as a search magnifier or a menu toggle, gives a screen reader user no way to know what it does. Success criterion 4.1.2 Name, Role, Value, at Level A, requires every control to have a name that assistive technology can read. Found on 30.6% of home pages.
The fix: give each button visible text, or, for an icon-only button, an accessible name such as “Submit search” supplied through an aria-label or alt text on the image inside it. This is a developer fix, and it usually lives in a shared component.
6. Missing document language
If a page doesn’t declare its language, screen readers may read it with the wrong pronunciation rules. Success criterion 3.1.1 Language of Page, at Level A, requires the default language to be identified. Found on 13.5% of home pages.
The fix: set the lang attribute on the <html> element in every page template, for example lang="en". It takes one change per template, which makes it the cheapest fix on this list.
The most common accessibility issues at a glance
| Issue | WCAG 2.2 success criterion | Level | Share of home pages (WebAIM 2026) | Usual owner |
|---|---|---|---|---|
| Low-contrast text | 1.4.3 Contrast (Minimum) | AA | 83.9% | Design |
| Missing alternative text | 1.1.1 Non-text Content | A | 53.1% | Content |
| Missing form input labels | 1.3.1, 3.3.2, 4.1.2 | A | 51.0% | Development |
| Empty links | 2.4.4 Link Purpose (In Context) | A | 46.3% | Development and content |
| Empty buttons | 4.1.2 Name, Role, Value | A | 30.6% | Development |
| Missing document language | 3.1.1 Language of Page | A | 13.5% | Development |
Common accessibility issues that are harder to detect
The six issues above top the list partly because an automated scan can detect them. The issues below are just as common in practice but need a person, a keyboard or a screen reader to confirm.
Keyboard access and visible focus
Everything a mouse user can do must also work from a keyboard (success criterion 2.1.1 Keyboard, Level A), and a keyboard user must be able to see where they are on the page (2.4.7 Focus Visible, Level AA). WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum), at Level AA, so a sticky header or a cookie banner can’t hide the focused element. The quickest test is to put the mouse aside and tab through a page. For a full method, see keyboard navigation accessibility testing.
Heading structure
Screen reader users often navigate a page by its headings. Text that is only bolded or enlarged to look like a heading doesn’t count, because the structure must be in the markup (1.3.1 Info and Relationships). Start with one <h1> and keep subheadings in order. WCAG doesn’t strictly require sequential levels, but skipping them makes a page harder to navigate.
Carousels and other moving content
An image carousel that advances on its own needs a way to pause, stop or hide it if the movement lasts more than five seconds (2.2.2 Pause, Stop, Hide, Level A). Keyboard users must also be able to move into and out of the carousel without getting stuck (2.1.2 No Keyboard Trap, Level A). A label alone fixes neither.
Missing captions
Prerecorded video with audio needs captions for people who are deaf or hard of hearing (1.2.2 Captions (Prerecorded), Level A). Automatic captions are a starting point, but they need a human edit before they’re accurate enough to rely on.
Misused ARIA
WAI-ARIA lets developers describe custom interactive components to assistive technology, but adding ARIA is not a fix in itself. The W3C’s first rule of ARIA use is to prefer a native HTML element, such as <button>, whenever one exists, and WebAIM’s scans have found more detected errors, on average, on home pages that use ARIA than on those that don’t. Incorrect ARIA can make a component harder to use than no ARIA at all.
Some errors slip past automated checks entirely, even on pages that pass a scan. Siteimprove’s analysis of manually reviewed cases identifies five of them, covered in errors automated checks miss.
How to start fixing your accessibility issues
On a large site, the order in which you fix issues matters as much as the fixes themselves. Three principles help:
- Fix templates and components first. Missing document language, empty buttons and unlabeled search fields usually live in shared code, so one fix repairs every page that uses it.
- Weigh prevalence against traffic. An issue on your highest-traffic pages and key journeys, such as applications, checkout or account sign-in, affects more people than the same issue on an archived page.
- Route each issue to the team that creates it. Contrast belongs to design, alt text to content, and labels, links and buttons largely to development. An issue sent to the wrong team waits in a queue.
Fixing existing issues only helps if new ones stop arriving, which means building checks into publishing and procurement. For how that works in practice, see accessibility governance that stops new issues.
Shortcuts don’t help here. Overlays add a script on top of a page rather than changing its source code, so they leave these issues in place, and they can conflict with the assistive technology settings people have tuned to their own needs.
If you’re not sure which of these issues your website has, start by assessing a page with the Siteimprove website accessibility checker. It scans for the most common accessibility issues and helps you scope the time and resources a remediation plan will need.
Frequently asked questions
What are the most common accessibility issues?
The six most common are low-contrast text, missing alternative text for images, missing form input labels, empty links, empty buttons, and missing document language. WebAIM’s 2026 scan of the top one million home pages found that these six account for about 96% of all detected errors.
What are some examples of accessibility issues?
Gray text on a white background that falls below a 4.5:1 contrast ratio, a product photo with no alt text, a search field labeled only by placeholder text, an icon-only menu button with no accessible name, and an auto-playing carousel with no pause control are all accessibility issues. Each one fails a specific WCAG success criterion.
What is a common limitation of accessibility checkers?
Automated checkers can detect many issues but not all of them. They can confirm that alt text exists, for example, but not whether it describes the image accurately, and they can’t judge keyboard usability or reading order the way a person can. That’s why accessibility testing combines automated scans with manual review.
