Most businesses meet accessibility as a demand letter or a procurement questionnaire, which is a poor introduction to a subject that is mostly about whether people can use your site. The standards are public, the common failures are few and repetitive, and the fixes are well understood. What trips teams up is the belief that this can be bought as a product and bolted on at the end. It cannot, and the sites that get it right treat it as part of how they build rather than something they buy afterwards.
Website accessibility compliance means meeting WCAG 2.2 level AA: text alternatives for images, full keyboard operation, sufficient colour contrast, visible focus indicators, labelled form fields and clear error messages. Overlay widgets do not achieve it. Accessibility is a design and build discipline, applied by designers, developers and content editors.
What does WCAG 2.2 actually require?
The Web Content Accessibility Guidelines are the technical standard most accessibility expectations point at, including in US litigation and procurement. Version 2.2 is the current release. It defines three conformance levels, A, AA and AAA, and the target almost everyone works to is AA.
Level A is the floor. Without it, parts of your site are unusable for some people rather than merely awkward. In plain language it asks for things like: every image that carries meaning has a text alternative, every function that works with a mouse also works with a keyboard, video has captions, nothing flashes in a way that can trigger seizures, and form fields have labels a screen reader can announce.
Level AA is what the standard practice, and it is where most of the work sits. It adds requirements around contrast between text and its background, text that can be resized without breaking the layout, a visible focus indicator so keyboard users can see where they are, consistent navigation across pages, and error messages that explain what went wrong rather than just colouring a box red.
Version 2.2 added criteria that catch problems people meet every day. Focus must not be hidden behind sticky headers or cookie banners. Drag and drop interactions need a single pointer alternative. Authentication must not depend on a cognitive test such as remembering a code or solving a puzzle, unless there is an alternative route. And forms should not force people to re-enter information the site already has.
Level AAA exists but is not a sensible sitewide target. The standard's own authors say so. Pick specific AAA criteria where they help your audience and leave the rest.
Why are overlay widgets not a fix?
You have seen the pitch. One line of JavaScript, a floating accessibility icon in the corner, and the vendor says your site is now compliant. It is an attractive offer because it converts a design and engineering problem into a subscription.
The trouble is what the widget can and cannot reach. It runs after your page has loaded and attempts to patch the result. It can toggle a high contrast mode and enlarge text, which some users appreciate. It cannot understand what your images depict, so any alt text it generates is a guess. It cannot restructure a heading hierarchy that skips levels. It cannot make a custom dropdown built from unlabelled divs behave like a real control. It cannot fix a checkout that traps keyboard focus.
Worse, overlays sometimes interfere with the assistive technology people already use and have configured to their own needs. Screen reader users have been broadly and publicly critical of them for exactly this reason, and a number of US lawsuits have been filed against sites that had an overlay installed at the time. Installing one does not immunise you, and it can create a false sense that the work is done.
Use an overlay only as a convenience layer on top of a site that already conforms. Never as the conformance itself.
Our first test on any site is to unplug the mouse and try to complete the primary conversion using only the keyboard. If you cannot reach the submit button, or you cannot see where focus is, no widget is going to save that page. It takes ten minutes and it tells you more than most automated scans.
What is the commercial case beyond legal risk?
Legal exposure is real. The ADA has been applied to commercial websites in US courts, and demand letters are a routine cost of doing business for retailers. But fear is a poor project sponsor, and teams that build only to avoid a letter tend to do the minimum and stop.
The stronger argument is that accessibility work is usability work with a specification attached. Larger tap targets help everyone on a phone on a train. Clear error messages reduce form abandonment for every user, not just those using a screen reader. Proper heading structure makes pages easier to scan and gives search engines a cleaner picture of your content. Captions get watched by people in open plan offices with the sound off.
There is also the market you are excluding. A meaningful share of adults live with a disability affecting vision, hearing, motor control or cognition, and many more experience temporary or situational limits: a broken wrist, bright sunlight, a slow connection, a noisy room. Every one of those people is a customer who either completes your form or gives up.
And there is procurement. Public sector buyers and large enterprises increasingly ask for an accessibility conformance report before they will sign. If you sell business to business, an inaccessible site can quietly remove you from consideration without anyone telling you why.
What are the most common failures, and how do you fix them?
The same faults appear on site after site. None of them are exotic and most were introduced by a decision that seemed purely visual at the time.
| Failure | Who it affects | The fix |
|---|---|---|
| Low contrast text, usually light grey on white | Low vision users, anyone in bright light | Meet the AA contrast ratios. Fix it in the design tokens so it cannot creep back |
| Images with no alt text, or alt text reading "image1.jpg" | Screen reader users | Write descriptive alt text. Mark purely decorative images as decorative so they are skipped |
| Form fields labelled only by placeholder text | Screen reader users, anyone who forgets what a field wanted | Use real label elements, kept visible when the field is filled |
| Focus indicator removed for aesthetics | Keyboard users | Restore a visible focus style. Design one you like rather than deleting it |
| Menus and modals that only respond to a mouse | Keyboard and switch device users | Add keyboard handling, manage focus on open and close, support Escape |
| Headings chosen by size rather than structure | Screen reader users, search engines | Use one h1 per page and nest headings in order. Style separately from structure |
| Link text reading "click here" or "read more" | Screen reader users navigating by link list | Write links that describe their destination on their own |
| Video without captions or transcripts | Deaf and hard of hearing users, sound off viewers | Caption everything. Auto captions need a human edit before they count |
| Errors shown only by turning a field red | Colour blind users, screen reader users | Add text explaining the problem and how to correct it, announced programmatically |
| Content that only appears on hover | Touch and keyboard users | Make it reachable by focus and dismissible, or stop hiding it |
| Cookie banner or sticky header covering focused elements | Keyboard users | Adjust scroll offsets so the focused element is never obscured |
| PDFs used for key information | Screen reader users, mobile users | Publish as HTML. Remediate the PDF only if it must stay |
How do you run a practical audit?
Automated tools catch roughly a third of issues. That third is worth catching, and it is cheap, but a clean automated report is not a passing grade. The rest needs a person.
- Pick a representative sample rather than every page. Homepage, a category or listing page, a detail or product page, a form, a long article, the checkout or enquiry flow, and any page with video.
- Run an automated scan across those pages to clear the mechanical failures: missing alt attributes, contrast ratios, missing labels, empty links.
- Do the keyboard pass. Tab through each page, complete the main task without a mouse, and note anywhere focus disappears, gets trapped, or jumps somewhere unexpected.
- Test with a screen reader. VoiceOver on macOS and iOS, NVDA on Windows, both free. Listen to whether the page makes sense in the order it is read.
- Check the page at 200 percent zoom and at 320 pixels wide. Content should reflow rather than requiring horizontal scrolling.
- Review the content itself: heading order, link wording, alt text quality, caption accuracy, reading level.
- Log every issue with the page, the WCAG criterion it fails, a severity, and a suggested fix. Anything less than that becomes a document nobody actions.
- Fix by severity, starting with anything that blocks a task outright, then re-test the fixes rather than trusting the ticket was closed correctly.
A first pass on a small business site takes a specialist two to four days. Remediation depends entirely on how the site was built, which is the uncomfortable part of the answer.
We add accessibility acceptance criteria to design and development tickets rather than scheduling an audit at the end. Contrast is checked when the palette is chosen, focus states are designed alongside hover states, and components ship with keyboard behaviour. Catching it there costs a fraction of retrofitting it later.
Who owns accessibility on your team?
The reason accessibility fails is almost never that someone objected to it. It fails because it belonged to nobody in particular and arrived too late to be cheap.
Designers own contrast, focus states, target sizes and whether a component can be operated without a mouse at all. Developers own semantic markup, keyboard behaviour, focus management and how errors are announced. Content editors own alt text, heading order, link wording and captions, and they will keep introducing failures long after the audit if nobody trains them. Whoever runs the site owns the retest schedule.
This is why accessibility is a build discipline rather than a plugin. Every one of those responsibilities sits with a person making a decision, and no script installed afterwards can reach back and change those decisions. It belongs in the way you approach website design and development from the first wireframe, and in the standards your content creation process holds itself to.
What does ongoing compliance look like?
A site that passed an audit in March is not necessarily passing in September. Every new landing page, campaign template and blog post is a chance to reintroduce something you already fixed.
What holds over time is a small amount of structure. An accessibility statement on the site with a real contact route, so someone who hits a barrier can tell you instead of telling a lawyer. Accessible components in your design system, so the correct pattern is also the easiest one to use. A short checklist in your publishing workflow covering alt text, headings and link wording. A quarterly automated scan and an annual manual review. And user testing with people who actually use assistive technology, which will teach you more in one session than a month of reading the criteria.
None of that is expensive once the foundation is right. The expensive version is the one where you skip it for three years and then rebuild under a deadline set by somebody else. Fixing accessibility also tends to lift the numbers you were already watching, which is why it belongs in the same conversation as conversion optimization rather than in a compliance folder.
Frequently asked questions
Is my business legally required to have an accessible website?
In the US, the ADA has been applied to commercial websites in court, and businesses open to the public regularly receive demand letters about inaccessible sites. Public sector organisations and the vendors selling to them face further requirements. There is no certificate that ends the question, which is why most organisations adopt WCAG 2.2 level AA as their working standard and document what they have done.
Will an accessibility overlay widget make my site compliant?
No. An overlay runs after the page loads and can only adjust what it finds. It cannot repair a broken heading structure, free a keyboard trap, give semantics to a custom control built from divs, or know what your photographs show. Some overlays actively interfere with the screen readers people have configured for themselves. Sites with overlays installed have still been sued.
What is the difference between WCAG level A and level AA?
Level A removes outright blockers: images without text alternatives, functions that only work with a mouse, form fields with no programmatic label. Level AA covers the quality issues most people encounter daily, including colour contrast, a visible focus indicator, text that resizes without breaking, navigation that stays consistent, and error messages that say what went wrong. AA is the level virtually everyone targets, and the one referenced in most legal and procurement contexts.
How much does it cost to make a website accessible?
The audit is the predictable part, usually two to four days of specialist time for a representative sample of pages. Remediation is where the range opens up. Alt text, contrast and link wording are cheap and can often be handled by your content team. Custom components built without semantics or keyboard support are expensive, because the honest fix is rebuilding them. A site built with accessibility in mind from the start avoids nearly all of that.
Does accessibility help SEO?
Yes, though indirectly. Descriptive alt text, a heading hierarchy that reflects real structure, link text that describes its destination, and captions or transcripts for video all give search engines better information about what a page contains. Accessible pages also tend to be clearer and quicker, which helps how people behave on them. Treat it as a welcome side effect rather than the argument for doing it.
How often should we retest accessibility?
Quarterly automated scans and an annual manual review suit most business sites, with an extra check whenever a significant new template or user flow goes live. The bigger risk is drift between reviews. Every new landing page and blog post is an opportunity to reintroduce a problem you already paid to fix, so a short publishing checklist covering alt text, heading order and link wording does more good than a more frequent audit.
The takeaway
Accessibility rewards the same discipline as everything else that works on a website: decide it early, put it in the components, and make it someone's job. Audit a representative sample, fix by severity, and build the checks into how you design, develop and publish. The version of this that costs the most is the one you postpone until a deadline is set by someone outside your company.