Accessibility and WCAG remediation

What this actually solves

Three things bring a business to this page, and they are not equally urgent.

The first is a letter. In the United States in particular, complaints about inaccessible websites are routine, and the demand arrives with a deadline attached. The second is procurement — a government department, a university, a health system or a large corporate has made accessibility a condition of the contract, and someone has to answer a questionnaire truthfully. The third is simply a decision that the site should work for everybody, made without external pressure. The first pays fastest, the third produces the best result, and the work is the same in all three cases.

Underneath the paperwork the problem is concrete. Someone who is blind reaches your site through a screen reader that reads it aloud in order — headings, links, buttons, image descriptions. Someone with a motor impairment moves through it with the Tab key alone and never touches a mouse. Someone with low vision needs contrast that survives a bright room and text that can be enlarged without the layout collapsing. When a button is really a styled div, the screen reader does not call it a button and the keyboard cannot reach it. When a form field's label is only a placeholder, the field is announced as nothing at all. The page still looks fine to everyone testing it by looking.

Accessibility is not a layer applied to a finished site — it is a property of the markup underneath. That is why it can be genuinely repaired and why nothing bolted on top can repair it.

What we do, and in what order

1. Run the automated pass first, to clear the cheap findings. axe DevTools and WAVE across a representative set of templates rather than every page — home, a content page, a listing, a form, checkout or booking if there is one. This catches contrast failures, missing alternative text and unlabelled controls quickly, and it establishes a baseline we can re-run later. One day.
2. Test it by hand, which is where the real findings are. The whole site driven with Tab, Shift+Tab, Enter and Space and nothing else — checking that focus is always visible, that the order matches the visual layout, that no component traps focus, and that everything reachable by mouse is reachable without one. Then the same journeys listened to through NVDA, with the screen off for the parts that matter, because reading the markup and hearing the page produce different lists. Three to six days depending on site size.
3. Write the findings up so they can be argued with and acted on. Every issue recorded with what is wrong, which WCAG 2.2 success criterion it relates to, who it affects and how badly, and the specific fix. Severity is ranked honestly — blockers that stop someone completing a task come first, cosmetic items last. This document is the deliverable even when we go on to do the fixes, because it is what you hold afterwards. Two to four days.
4. Fix it in the markup, starting with the blockers. Native elements restored where divs were doing the work of buttons, links and headings. Real labels attached to form fields, errors associated with the field they belong to and announced when they appear. Focus management in modals and menus. Contrast corrected in the design tokens rather than patched per component. ARIA used only where no native element exists, because incorrect ARIA is worse than none. One to three weeks depending on how much is in scope.
5. Re-test, then hand over something that holds. The automated pass re-run against the baseline, the manual keyboard and screen-reader journeys repeated, and a closing report showing what was fixed, what was not, and why. With it, a short set of rules for new work and an automated check wired into the build, so the next component does not undo the month. Two to three days.

What moves the price

The range is $700–$5,000, and three things decide where a project falls inside it.

How many distinct templates and components exist. Page count matters far less than variety. A two-hundred-page site built from six templates is a smaller job than a twenty-page site where every page was assembled differently, because accessibility is fixed per pattern, not per page.

Whether interactive components are involved. Static content is comparatively quick. Custom dropdowns, date pickers, modals, tabbed interfaces, carousels, multi-step forms and anything drag-based are where the difficult findings concentrate, and where fixes sometimes mean rebuilding a component rather than adjusting it.

Audit only, or audit and remediation. A findings report on its own sits at the lower end of the range and does not include implementation. Full remediation across a complex site with custom components sits at the top. It is worth being clear which one you are buying, because the two are often quoted against each other as though they were the same thing.

What usually goes wrong

An overlay widget is bought instead of doing the work. One line of JavaScript, an accessibility badge in the corner, and a claim of instant compliance. It cannot repair the markup the screen reader is reading, it sometimes interferes with the assistive technology the user already has configured, and it is actively opposed by the people it claims to serve. Businesses that installed one have still received legal complaints — and now they have paid twice.

A scanner report is presented as an audit. The tool returns a clean result and everyone relaxes. But an automated check confirms that an image has alt text, not that the alt text describes the image; it confirms a control has a name, not that the name makes sense when spoken aloud; and it cannot tell that the keyboard focus disappears behind a sticky header. An audit with no keyboard pass and no screen reader in it has not tested the thing it claims to have tested.

ARIA is bolted onto div soup. A component is built from generic containers, then role="button" and a handful of aria- attributes are added to make the scanner quiet. It usually makes the experience worse, because the roles now promise behaviour — keyboard activation, state announcements, focus handling — that nobody implemented, and the screen reader announces something that does not do what it says. Using the native <button>, <a> or <h2> is shorter code and it works. This is also the most common thing to find when markup has been generated quickly, and it is the pattern to look for first.