Accessibility
Usable by everyone, tested properly.
Accessibility work makes a website usable by people navigating with a keyboard, a screen reader, magnification, voice control or reduced motion. It is a build standard rather than a plugin, and almost every site fails it.
What does it take to make a website WCAG 2.1 AA accessible?
Four categories of work: correcting structure, meaning real headings in order, landmarks, labelled form fields and meaningful alternative text; correcting presentation, meaning contrast ratios of at least 4.5 to 1 for body text and text that reflows when zoomed; correcting behaviour, meaning everything reachable and operable by keyboard with visible focus and no traps; and correcting components, meaning menus, modals, tabs and carousels that announce themselves correctly to assistive technology.
Automated scanning finds a minority of it. The rest requires testing with a keyboard and with a screen reader, which is why a scan report is a starting point rather than a result.
It is not a widget. Overlay products that claim to make a site compliant by adding one script do not fix the underlying markup and are widely criticised by disabled users.
What WCAG actually asks for
The Web Content Accessibility Guidelines are organised around four principles. Content should be perceivable, so you can take it in however you receive information. Operable, so you can drive it with whatever input you use. Understandable, so it behaves predictably. And robust, so it keeps working with tools the author never tested.
Level A covers the basics without which some people cannot use a page at all. Level AA adds what makes a page usable in practice: contrast, resizable text, consistent navigation, visible focus and clear error handling. Level AAA is stricter and the guidelines themselves acknowledge it is not realistic as a blanket target.
Level AA is the standard referenced in United States web accessibility guidance and the one procurement teams ask about. It is what we build to.
A useful thing to understand: most of this overlaps with things you already want. Clear headings help everyone. Readable contrast helps everyone in sunlight. Forms with proper labels are easier for everybody to fill in. Accessibility work is rarely a trade against usability.
How common the failures are
WebAIM at Utah State University runs an automated analysis of the top one million home pages each year. Automated testing catches only part of what matters, which makes these figures a floor.
SourceThe WebAIM Million, WebAIM at Utah State University, 2026
Six error types account for 96% of everything detected: low contrast, missing alternative text, missing form labels, empty links, empty buttons and missing document language. All six are ordinary markup problems with ordinary fixes.
How remediation actually runs
The order matters, because structural fixes change what the later tests find.
Automated scan, to find the obvious
A scan across the whole site catches contrast failures, missing alternative text, unlabelled inputs, empty links and buttons, and missing language attributes. It is fast, it is cheap, and it finds roughly a third of what matters.
Keyboard testing, by hand
Tab through every page template without touching the mouse. Can you reach everything? Can you see where you are? Can you open and close the menu, the modal and the accordion? Can you get out of them? This finds the problems that stop people using the site entirely.
- Visible focus on every interactive element
- Logical order that matches the visual layout
- No traps, meaning nothing you can enter and not leave
Screen reader testing
Listening to how each template is announced. Whether headings describe the structure, whether links make sense out of context, whether form errors are announced, whether a modal moves focus and traps it correctly while open. This is where component level problems surface.
See the remaining steps: How remediation actually runsHide the remaining steps: How remediation actually runs
Fix the structure first
Headings in order with no skips, landmarks, labels tied to inputs, alternative text that describes purpose rather than filename, and decorative images hidden from assistive technology. Structural fixes frequently resolve several reported errors at once.
Fix presentation and components
Contrast corrected at the design token level rather than page by page, so the problem does not recur. Focus styles made visible. Custom components given the roles, states and properties they need, following the established authoring practices rather than improvising.
Retest, then bake it into the build
Retesting with the same three methods, then adding the checks to how new pages are built so the site does not drift back. A remediated site with no process returns to where it started within a year.
The last step is what separates remediation from a permanent fix, and it is the step most often left out of a quote.
Why overlay widgets are not a fix
There is a category of product that promises to make a website compliant by adding one line of JavaScript. It typically adds a floating icon offering contrast adjustment, text resizing and other toggles, and claims to repair accessibility problems automatically.
The underlying markup does not change. A form input with no label still has no label. A custom dropdown that a screen reader cannot operate still cannot be operated. What the overlay adds is a set of preferences a browser already offers, plus automated guesses about your content that are frequently wrong.
Read the full breakdown: Why overlay widgets are not a fixHide the full breakdown: Why overlay widgets are not a fix
These products have been widely criticised by disabled users and by accessibility practitioners, and there are documented cases of overlays actively interfering with the assistive technology a person already uses, making the site harder rather than easier.
We build a small preference control into sites we make, offering reduced motion and larger text, and we are precise about what it is: a convenience, not a compliance measure. The accessibility comes from the markup underneath it.
If somebody has sold you an overlay and told you the site is now compliant, the useful test is to unplug your mouse and try to use your own contact form.
What you can test yourself in twenty minutes
None of this requires software or expertise, and it will tell you more than a scan report.
- Unplug your mouse. Navigate to your contact page using only the Tab and Enter keys and submit the form.
- While doing that, can you always see which element is selected? If the focus indicator is invisible, that is a failure on its own.
- Open your main navigation with the keyboard. Can you close it again without a mouse?
- Zoom the page to 200% in your browser. Does text reflow and stay readable, or does it overlap and get cut off?
- Look at your lightest grey body text on white. If you struggle in daylight, it very likely fails the 4.5 to 1 contrast requirement.
See the full checklist: What you can test yourself in twenty minutesHide the full checklist: What you can test yourself in twenty minutes
- Check whether your images have alternative text that says what they show, rather than the file name or nothing.
- Fill in a form incorrectly on purpose. Is the error explained in text, or only shown as a red outline?
- Look at your links. Do any of them say click here or read more with no context?
If the keyboard test fails on the contact page, that is the highest priority finding you will get from any audit, free or paid.
Where we stand on the legal question
We are not lawyers and we do not give legal advice. What we can tell you is the standard we build to and how it is tested.
What is publicly documented is that the Department of Justice has published guidance pointing to WCAG as the practical benchmark for web accessibility under the Americans with Disabilities Act, and that accessibility litigation against businesses is common. Whether any particular obligation applies to your business is a question for your own counsel.
Read the full breakdown: Where we stand on the legal questionHide the full breakdown: Where we stand on the legal question
We will also be blunt about the marketing that surrounds this, because it is unusually predatory. Anybody guaranteeing legal compliance, including any vendor selling you a widget, is claiming something they cannot deliver. Conformance to a technical standard is verifiable. Legal compliance is a judgement a court makes.
What genuinely reduces exposure is a site that a disabled person can actually use, a published accessibility statement that says what you have done and what you know is imperfect, and a route for somebody to report a barrier and get a response.
How this is measured
Automated error count as a floor, tracked before and after, with the understanding that zero automated errors is not the same as accessible.
Manual test results by template: keyboard operability, screen reader announcement quality, focus visibility and error handling, recorded per template rather than per page, since templates are what get fixed.
Read the full breakdown: How this is measuredHide the full breakdown: How this is measured
Contrast conformance across the design system rather than per page, because fixing it at the token level is what stops it recurring.
And the honest qualitative measure: can a person using only a keyboard complete the primary task on each key page. That is the test that matters most and it is not a number.
We do not publish a price for this piece of work on its own, because the right scope depends on what already exists. What is published is the bundle pricing: 2,400, 3,600 or 4,800 dollars a month depending on which channels are running. You can read the full breakdown on the pricing page, and you will get an exact number in writing before anything starts.
How this connects to the rest
Accessibility is built into every site we make under web design and development rather than sold as a separate stage, because retrofitting it costs several times more than building it in.
It overlaps with conversion rate optimisation more than people expect. Clear labels, visible focus, readable contrast and understandable errors improve completion rates for everybody, not only for people using assistive technology.
It touches technical SEO through shared foundations: heading structure, meaningful link text, alternative text and semantic markup serve both a screen reader and a search engine.
For an existing site that cannot be remediated without rewriting its templates, the honest recommendation is usually a WordPress rebuild rather than continued patching.
Unplug your mouse and try your own contact form.
That one test tells you more than most audits. Bring us what you find and we will tell you whether this is remediation work or a rebuild.
Straight answers.
Does my website have to be accessible?
What is publicly documented is that the Department of Justice points to WCAG as the practical benchmark for web accessibility under the ADA, and that accessibility litigation against businesses is common.
What we will tell you is what we build to, which is WCAG 2.1 Level AA, and how it is tested. Whether a particular obligation applies to your business is a question for your own counsel, and the section above sets out exactly where we stand on it.
Will an accessibility widget make my site compliant?
No. Overlay products do not change the underlying markup, so an unlabelled form field remains unlabelled and an inoperable component remains inoperable.
They have been widely criticised by disabled users, and there are documented cases of overlays interfering with the assistive technology someone already uses.
How long does remediation take?
It depends on how many distinct templates the site has rather than how many pages. Fixing a template fixes every page using it, so a hundred page site with six templates is a smaller job than it sounds.
The audit is days. The fixes are usually weeks. Building the checks into how new pages are made is what stops it recurring.
Is an automated scan enough?
No. Automated testing catches a minority of what matters, mostly contrast, missing alternative text and unlabelled inputs.
The problems that actually stop somebody using a site, such as keyboard traps and components a screen reader cannot operate, need manual testing to find.
Does accessibility help SEO?
They share foundations: proper heading structure, meaningful link text, alternative text and semantic markup serve both a screen reader and a search engine.
It is a genuine overlap rather than a claim that accessibility is a ranking factor. Treat the search benefit as a side effect and do the work for the actual reason.
What is an accessibility statement?
A page saying which standard you build to, what you have done, what you know is imperfect, and how somebody can report a barrier and get help.
It is not a legal shield and it is a genuine signal that you take it seriously, as well as being useful to the person who cannot complete something on your site today.
Where this comes from.
Primary documentation and published research behind the guidance on this page.
- WCAG 2 checklist, WebAIM (opens in a new tab)A practical summary of the Level A and AA success criteria.
- ADA.gov guidance on web accessibility (opens in a new tab)
- The WebAIM Million accessibility analysis (opens in a new tab)
- WebAIM contrast checker and guidance (opens in a new tab)
- Laws and policies on accessibility, Section508.gov (opens in a new tab)
Talk to the team
A short call, a look at how the business currently shows up, and a straight answer on what we would do first.