( Accessibility )
How to fix the most common accessibility issues
How do I fix accessibility issues?
Start with the seven failures below. They are the ones automated scanning detects reliably, they account for the bulk of raw findings on most sites, and each has a specific fix rather than a judgement call. Every one of them is documented as a rule with its criterion and remedy, and each maps to a success criterion in the WCAG standard.
Two things make the difference between fixing them once and fixing them forever. Work at the component level, because a single shared component is usually responsible for findings across dozens of pages. And put detection in the workflow rather than in an annual audit, for the reasons set out at the end of this post.
1. Low colour contrast (WCAG 1.4.3)
The most frequent failure on the web, and getting worse: WebAIM found it on 83.9% of home pages in 2026, up from 79.1% the year before. Grey-on-white microcopy, placeholder-coloured labels, text over hero images. Anything below 4.5:1 for body text (3:1 for large text) fails.
Fix: darken the text or lighten the background until the ratio passes. Design tokens make this a one-place fix; ad-hoc colours make it a hundred-place fix. Contrast failures affect a huge population: low vision, older users, anyone on a phone in sunlight. The ratios, and where automated checking stops working, are worth knowing before you start moving colours.
2. Images missing alt text (WCAG 1.1.1)
Screen readers announce the filename or nothing at all. AI crawlers get nothing either.
Fix: every <img> needs an alt attribute. Informative images get a description of what the image communicates (“Bar chart showing 40% growth in Q3”, not “chart”). Decorative images get alt="" so assistive tech skips them. The empty string is a decision, not an omission. Getting from “has an attribute” to “says something useful” is a separate exercise, and it is the half no scanner can do for you.
3. Form inputs without labels (WCAG 4.1.2, 1.3.1)
Placeholder text is not a label. It vanishes on input and many screen readers don’t treat it as one. An unlabelled field is a mystery box.
Fix: a visible <label for="..."> wired to the input’s id. Where the design genuinely can’t show one, aria-label works, but visible labels help everyone, including users with cognitive disabilities and anyone who forgets what they were typing.
4. Buttons and links with no accessible name (WCAG 4.1.2, 2.4.4)
Icon-only buttons such as the hamburger, the ×, and the trash can announce as “button” with no hint of what they do. Links whose only content is an image with no alt announce as their URL.
Fix: aria-label="Close dialog" on icon buttons, or visually hidden text inside them. For links, meaningful text or alt on the image inside. “Click here” and “learn more” fail the same users in a subtler way: the link name should describe the destination.
5. Missing document language (WCAG 3.1.1)
Without <html lang="en">, screen readers guess at pronunciation. English text read with French phonemes is close to unintelligible.
Fix: one attribute on one element, sitewide. The highest fix-per-keystroke ratio in accessibility.
6. Broken heading structure (WCAG 1.3.1, 2.4.6)
Pages with no <h1>, three <h1>s, or jumps from h1 to h4 because the intermediate sizes “looked too big”. Screen reader users navigate by headings; a broken outline means navigating blind. AI systems segment your content by the same outline.
Fix: one h1 naming the page, h2 for sections, h3 inside them. Style size with CSS, never by choosing a different heading level.
7. Keyboard traps and invisible focus (WCAG 2.1.2, 2.4.7)
Modals you can tab into but not out of; outline: none applied globally so keyboard users can’t see where they are.
Fix: never remove focus outlines without replacing them with something clearly visible (WCAG 2.2 tightens this further; see our WCAG 2.2 guide). Test every overlay: Tab through it, Escape out of it.
Why do the same accessibility issues keep recurring?
Because they are invisible to the people shipping them. The site looks right, and nothing in a normal development workflow surfaces the problem: mouse users never meet the keyboard trap, sighted users never hear the missing label.
That’s the case for scanning continuously rather than auditing annually: each of these has an automated rule that catches it the day it’s introduced, mapped to the exact criterion and fix. Fix the top seven and you’ve usually eliminated the majority of raw findings on a site, and materially improved how both assistive technology and AI search read it.
How do I stop them coming back?
By changing where the checks sit rather than how hard the team tries. The failures above are not difficult; alt text and focus states have never been the hard part. What sinks product accessibility is process, and it fails in five recognisable ways.
Auditing once and calling it done. An audit lands, a remediation sprint follows, the report gets filed, and six months of shipping quietly rebuilds the backlog. An audit describes a moment; your product changes every sprint. Put detection in the pipeline instead, so failures surface the week they are introduced.
Starting at QA instead of design. If the first accessibility conversation happens when a tester runs a screen reader over the release candidate, every finding is already expensive. Contrast, focus order, target size and label placement were all decided months earlier in a design file, where they cost nothing to get right.
Fixing pages instead of components. Teams remediate screen by screen while every screen assembles the same broken components. The unlabelled icon button gets fixed in eleven places and stays broken in the library that generates the twelfth. Fix the design system first: one accessible button, modal, field and dropdown fixes every page that uses them, present and future.
Making one person the accessibility person. Appointing a champion feels like progress, but routing every question through one person creates a bottleneck, and their departure erases the capability. Worse, everyone else learns it is somebody else’s job. Shared ownership with clear lanes works better: designers own contrast and states, engineers own semantics and keyboard support, QA owns the keyboard and zoom pass, and a specialist takes the genuinely hard judgement calls.
Relying on an overlay. An overlay promises a fix via a script tag. It patches a subset of symptoms in the browser after load while the underlying markup stays broken, for users, for crawlers and for anyone who checks. The Overlay Fact Sheet has been signed by hundreds of practitioners, including contributors to the WCAG, ARIA and HTML specifications, and many signatories are disabled people themselves. Spend the subscription on fixing components instead.
One more worth naming, because it costs deals rather than users: treating conformance claims as marketing. Declaring a standard met without evidence backfires the moment a buyer or auditor checks, and procurement teams read a lot of conformance reports. Claim what you can evidence, with real remarks and real dates. The business case follows from there.
Frequently asked questions
How do I fix accessibility issues on my website?
Start with the automated findings, because they are the high-frequency, low-judgement failures: contrast, alt text, form labels, accessible names, document language and heading order. Each maps to a specific WCAG criterion with a known fix. Work them at the component level rather than page by page, then put scanning in your workflow so the same failures cannot silently return.
What is the most common accessibility issue on websites?
Low colour contrast is consistently the most frequent failure, followed closely by missing image alt text and unlabelled form controls. All three are detectable automatically and usually quick to fix.
Are the most common accessibility issues hard to fix?
Mostly no. The highest-frequency failures, such as missing alt text, low contrast, missing labels, empty buttons and links, are typically one-line fixes. The difficulty is coverage, not complexity, which is why continuous scanning matters.
Can automated scanning find all accessibility issues?
No. Automated rules reliably catch the structural failures listed here, which are a meaningful slice of WCAG. Criteria involving judgement, such as logical focus order, meaningful reading sequence and sensible link purpose, need human review. Use both.
Why do the same accessibility issues keep coming back after we fix them?
Because the fixes were applied to pages rather than to the components those pages assemble, and because nothing in the workflow catches a regression. A single shared button or form field can generate findings across dozens of pages, so fixing it once in the design system is worth more than fixing it everywhere else. Continuous scanning then catches the reintroduction the week it happens instead of at the next audit.
Do accessibility overlays fix these issues?
No. Overlays patch symptoms in the browser at runtime and miss most real failures, while the underlying markup stays broken for users, crawlers and anyone who inspects it. The Overlay Fact Sheet has been signed by hundreds of accessibility practitioners, including contributors to the WCAG, ARIA and HTML specifications. Fixing your components fixes the product; an overlay defers the work and adds a script.
