Accessibility remediation services for websites, documents and Section 508
You are here because something has already been found: an audit came back with a list, a buyer questioned your accessibility documentation, or a demand letter named specific barriers on your site. The finding is not the problem any more, closing it is. We fix the issues in the code, the documents and the interface, retest to confirm each one is resolved, and hand you the evidence that says so.
Accessibility remediation services we provide
Remediation is one engagement across three kinds of material, and most teams need more than one of them. We scope them together so nothing is fixed in isolation and then contradicted by a document or a screen nobody looked at.
Website and web application remediation
Code-level fixes to templates, components and interactive patterns, made in your codebase or delivered as changes your developers can apply without re-diagnosing anything.
Document and PDF remediation
Tags, reading order, alternative text, table headers, form fields and language settings on the files you publish or send to buyers.
Section 508 remediation for federal work
The same fixes run against the standard federal reviewers use, ending in an updated conformance report you can put in front of a contracting officer.
When you need remediation rather than another audit
An audit tells you what is broken. It does not change a single line of your product. Teams come to us at the point where they already know: the report is sitting in a folder, the list has been circulated, and nothing has moved because nobody owns the fixing.
That is the gap we fill. We work from your existing audit if you have one, whether we produced it or another firm did, so you are not paying for the same assessment twice. Where a report is thin, out of date, or written against a different standard than the one you are held to, we say so before we start rather than quietly re-testing on your budget.
If you do not have an audit yet, we start with WCAG audits and testing and move into remediation from there. Buying both from one team removes the argument that usually stalls this work, where the auditor says the developer implemented it wrong and the developer says the finding was unclear.
What accessibility remediation actually fixes
Remediation is specific work on specific defects, not a pass over the site to make it feel better. The issues we close most often are the ones audits produce most often.
- Images, icons and controls with missing, duplicated or meaningless alternative text
- Keyboard operation: elements that cannot be reached, cannot be left, or trap focus
- Focus order that does not follow the visual sequence, and focus indicators invisible against their background
- Headings and landmarks that misrepresent the structure of the page
- Forms without programmatic labels, and errors shown visually but never announced
- Text and interface contrast below the required ratios
- Custom components such as menus, modals, tabs and comboboxes where ARIA is missing, incorrect, or contradicts the behavior
- Tables without header associations, and layout tables read as data
- Media without captions, transcripts or audio description
- Documents that carry the same failures into PDF
Each fix is tied to the success criterion it closes, so the report you hand a reviewer later says what changed and why it mattered.
How we prioritize remediation work
Most providers will tell you they prioritize. Very few will tell you against what, and the difference decides whether your budget buys risk reduction or a longer list of closed tickets.
We order the work by two questions. First, does the issue stop someone completing a task — buying, applying, submitting, logging in? A barrier on a checkout flow outranks a contrast failure in a footer, however many instances of the footer there are. Second, is it an issue a reviewer will land on? Contracting officers, agency compliance teams and plaintiff firms look at predictable things: keyboard operation, forms, error handling, the main navigation. Failures there cost you a contract or an answer to a letter, not just a line in a report.
Volume comes last. Fixing four hundred instances of one low-impact pattern makes the numbers look excellent and changes nothing for the person who could not complete the form. We will tell you when a large count is not the priority, and we will tell you when it is.
How a remediation engagement runs
Scope and baseline
We agree what is in — which templates, components, user journeys and documents — and against which standard. Where you already have findings, we map them to that scope so the work starts from what you paid for.
Fix
We work through the list in priority order, either directly in your codebase or as changes your team applies, whichever your release process allows. Documents are remediated and returned in whatever form fits how you publish them.
Retest and verify
Closed issues are re-tested, by hand and with assistive technology where the finding calls for it. How much of the set that covers depends on the scope we agree, but the principle does not move: a fix that satisfies a checker while still trapping a screen reader is not closed, and we will not report it as closed.
Documentation
You receive a record of what was fixed, what was verified, what remains open and why, plus an updated conformance report where procurement needs one.
Document and PDF remediation
Documents fail for reasons that have nothing to do with your website, and they are the part teams forget until a buyer opens one. A PDF that looks correct on screen can be untagged underneath, read out of order, or built from scanned images with no text layer at all.
We remediate the files you actually publish and send: tags and structure, reading order, alternative text on images and charts, table header associations, form fields and their labels, bookmarks and navigation on long documents, and the document language and title. Where a file cannot be salvaged, such as a scan with no usable text, we say so up front rather than after the attempt, and we will usually recommend rebuilding it instead.
This matters most for federal contractors, education and healthcare, where the document is often the deliverable rather than an attachment to it.
Section 508 remediation and the conformance report that follows
Federal work adds a requirement beyond the fixing: someone has to be able to verify it. A contracting officer is not going to take your word that the findings are closed, and an internal ticket marked resolved is not evidence.
So a Section 508 remediation engagement ends in a document. We fix the findings, retest against the standard the Revised 508 Standards incorporate — WCAG 2.0 Level A and AA — and update the VPAT or ACR so it reflects what the product does now rather than what it did at the first audit. Where a limitation cannot be removed in this release, it is stated accurately rather than hidden, because an honest qualification survives review and an over-claimed one does not.
If you are earlier than that and still working out what applies to you, Section 508 compliance covers the requirements and who they reach. If the report itself is what you need, VPAT and ACR reporting is where that work lives. This page is about the fixing in between.
What automated fixes can and cannot close
Automation has a real place in remediation. Machine-detectable defects such as missing alt attributes, empty links and some contrast failures can be found at scale and corrected quickly, and refusing to use tooling for that is simply slower.
What automation cannot do is judge. It cannot tell you whether focus order matches the visual sequence, whether an error message is announced when it appears, whether alternative text describes the right thing, or whether a custom component can be operated at all. Those are the findings that block users and the findings a reviewer opens first, and they need a person looking at them.
The practical consequence is that a backlog cleared by tooling alone comes back. The count drops, the report looks better, and the barriers that mattered are still there. We use automation where it earns its place and do the rest by hand.
On the related question of whether an overlay widget resolves legal exposure, ADA website compliance sets out that argument in full.
Keeping accessibility fixed between releases
Remediation has a shelf life. A site that was clean in March is not clean in September if six sprints shipped in between and nobody checked. Most of the regressions we see are not new mistakes; they are the same pattern reintroduced by a component that was never fixed at the source.
That is why we close the loop rather than the list. Where a defect repeats across a site, fixing the shared component is usually the better call than patching every instance, because that is what stops the pattern regenerating. For teams shipping on a cycle, release checks that catch a regression before it ships are worth setting up, and we can put those in place where it fits how you work. And we tell you which findings are structural and will keep coming back until the underlying pattern changes.
The alternative is remediating the same site every year and calling it maintenance.
What you receive from a remediation engagement
The output has to work twice over: your engineers need to know what changed and where, and a reviewer needs to see that the claims rest on verification rather than on a ticket marked done.
- Fixes applied in your codebase or delivered as changes your developers can apply, and remediated documents returned ready to publish
- Each closed issue tied to the success criterion it resolves, with a record of what changed
- A retest report stating what was verified, what is closed, and what remains open with the reason
- A clear statement of coverage: the templates, components, journeys and documents that were in scope
- An updated VPAT or ACR where procurement requires one
- Direction on the defects that are structural, so the same findings do not return next release
Trusted by teams at
Common questions about accessibility remediation
We already have an audit report. Can you work from it, or does everything need testing again?
Do you fix things yourselves, or hand our developers a list?
How much does accessibility remediation cost?
How do you decide what gets fixed first?
Can automated tools or an overlay do this instead?
Do you remediate documents and PDFs as well as the website?
We sell to federal agencies. Does remediation update our VPAT?
How do you prove the issues are actually closed?
What happens when the next release breaks something again?
Can you work inside our codebase, or only deliver patches?
Who does this work
David LoPresti works with product, engineering and compliance teams to turn accessibility findings into changes that hold up under review. On a remediation engagement that means fixes made against the specific success criterion each finding fails, a retest by hand with assistive technology where the finding calls for it, and, where a buyer is waiting on documentation, an updated conformance report that describes the product as it ships rather than as it was first audited.
The standards this page refers to
Close the findings and get the evidence to prove it
Tell us what came back — an audit report, a buyer questionnaire, or a letter — and we will scope the fixing and the verification with you on a call.
Free Consultation (opens in new tab)