How to Respond to an Accessibility Complaint

Why your response matters more than the complaint

Accessibility complaints — whether filed through a contact form, sent by email, submitted to a regulator, or delivered as a formal legal demand — are rarely the end of the story. How you respond determines what happens next.

A prompt, genuine, and action-oriented response resolves most complaints without escalation. An evasive, dismissive, or absent response is frequently what turns a fixable user complaint into a formal investigation or lawsuit.

This guide covers how to handle accessibility complaints at every stage: from the moment you receive one through remediation, communication, and putting systems in place so the same complaint does not arrive again.

Understand what kind of complaint you have received

Not all accessibility complaints are the same, and the appropriate response varies depending on the type.

User feedback

The most common form. A person with a disability encountered a barrier on your website — a form they could not complete with a screen reader, a video with no captions, a button that was unreachable by keyboard — and they reported it directly to you through your contact page, accessibility feedback mechanism, or general support channel.

These complaints are often the most valuable feedback your team will ever receive. They identify real barriers from real users in real situations that automated tools frequently miss.

Regulatory or government complaint

In the UK, a user may report an issue to the Government Digital Service (GDS) or the Equality and Human Rights Commission (EHRC). In the US, complaints may be filed with the Department of Justice (DOJ), the Department of Education’s Office for Civil Rights (OCR), or other federal agencies. In the EU, complaints go to national enforcement bodies designated under the Web Accessibility Directive.

These complaints follow a formal process. You will typically receive written notice, a description of the alleged violation, and a timeframe for response.

Legal demand letter

In the US, this is often the first indication that a plaintiff intends to pursue litigation under ADA Title III. The letter describes the alleged violations and typically proposes settlement terms. This is a legal matter requiring separate handling — see our ADA demand letter guide for a dedicated walkthrough.

Accessibility statement feedback

If your site has a published accessibility statement with a feedback mechanism (required under PSBAR in the UK and strongly recommended everywhere else), you may receive structured feedback through it. These are often detailed and specific, and deserve the same treatment as any other complaint.

Step 1: Acknowledge promptly

The single most important thing you can do when an accessibility complaint arrives is respond quickly to confirm you have received it.

This is true even if you cannot immediately investigate the issue. A same-day or next-business-day acknowledgement communicates that you take the complaint seriously. It also prevents the complainant from assuming their message was ignored — a common trigger for escalation.

Your acknowledgement should:

Confirm you have received the complaint
Name a specific person or team responsible for following up
Give a realistic timeframe for a full response (see Step 3)
Thank the person for raising the issue — they are helping you identify a barrier that affects other users too

Keep the tone professional and genuinely appreciative. People who report accessibility barriers are often users who have tried other workarounds and found none. They are taking time they should not have to spend.

Template:

Thank you for getting in touch. We have received your message and are reviewing the issue you described. A member of our team will be in contact within [timeframe] with an update. We take accessibility seriously and appreciate you bringing this to our attention.

Step 2: Investigate the specific barrier

Once acknowledged, investigate the specific issue the complainant described. Avoid the temptation to run a general accessibility audit and treat that as a response to the specific complaint — it delays resolution and misses the point.

What to investigate:

Can you reproduce the issue? Test it in the environment the complainant described: the browser, operating system, and assistive technology they mentioned (if they mentioned any).
Is the barrier at the component level (a specific button, form, or modal) or at the page level?
Is it a code issue, a content authoring issue, or a third-party component issue?
Does the same barrier appear elsewhere on the site?
Which WCAG success criterion does it violate (if any)?

Testing tools to use:

Keyboard only — can you reach and operate the affected element using Tab, Shift+Tab, Enter, Space, and arrow keys?
Screen reader — test with NVDA + Chrome, JAWS + Chrome, and VoiceOver on Safari (macOS/iOS). Does the element have an accessible name? Is it announced correctly?
Automated scanner — run a targeted scan on the affected URL to surface any co-located issues
Zoom to 200% and reflow to 320px — does the layout break?

Document your findings. You need a clear record of what the barrier is, where it exists, and what caused it.

Step 3: Fix it — and set a realistic timeline

Once you understand the barrier, fix it. The priority and timeline should match the severity:

Severity	Examples	Target fix time
Critical	Checkout form unreachable by keyboard, login blocked for screen reader users	24–72 hours
Serious	Missing alt text on product images, unlabeled form inputs in a key flow	Within one week
Moderate	Poor color contrast on secondary content, missing heading structure	Within the sprint or two weeks
Minor	Non-descriptive links in a blog post, missing `lang` attribute	Next planned maintenance window

If the fix will take time — for example, it requires a third-party vendor to update their component — communicate that to the complainant. Tell them:

What the barrier is
What is causing it
What you are doing to fix it
When you expect it to be resolved
Whether there is an alternative way they can complete the task in the meantime

The alternative access route is important. If a person cannot use your checkout, offer to take their order over the phone or by email while the fix is in progress. “We’re working on it” without an alternative is not a reasonable adjustment — it just tells the user they cannot access your service.

Step 4: Respond to the complainant with specifics

When the fix is complete (or when you have a concrete plan if it will take longer), respond to the complainant with a substantive update. This response should:

Describe the specific issue that was identified
Explain what you found during your investigation
State what has been fixed, or detail the fix plan with a timeline
Confirm that the fix has been verified (retested)
Invite them to test the updated experience and report back if the barrier persists
Provide a direct contact if they encounter further issues

Avoid vague reassurances like “we have improved our accessibility.” Be specific. A complainant who cannot log in with a screen reader deserves to know exactly what was broken and that it is now fixed.

Template:

Thank you for your patience while we investigated the issue you reported. We identified [specific problem] on [specific page/component]. This has been resolved — [brief description of the fix]. We have retested the updated [page/component] and confirmed that [element] is now [accessible behavior]. We would welcome the opportunity to hear from you if any issues persist. You can reach us directly at [contact].

Step 5: Document everything

For every accessibility complaint you receive and resolve, maintain a record that includes:

The date received and the date acknowledged
A description of the reported barrier
Your investigation findings
The fix applied and the date it was deployed
Confirmation that the fix was tested
All correspondence with the complainant

This documentation serves three purposes. First, it demonstrates good faith — if a complaint escalates to a regulator or legal action, a documented remediation record is strong evidence that you took the matter seriously and acted. Second, it feeds your accessibility statement, which should list known issues and their remediation status. Third, it builds institutional knowledge about recurring failure modes in your codebase or content workflow.

Step 6: Update your accessibility statement

Your accessibility statement should reflect the current known state of your site. After resolving a complaint:

Remove the barrier from any list of known issues (if it was listed)
Update the “last reviewed” date
If the complaint revealed a category of issues you had not previously identified, add it and note its remediation status

An accessibility statement that accurately reflects known issues — including ones that are not yet fixed, with realistic timelines — builds more trust than one claiming full conformance that users know to be inaccurate.

Handling complaints you cannot resolve immediately

Sometimes a barrier cannot be fixed quickly: the component is owned by a third-party vendor who has not yet released a fix, the remediation requires a platform migration, or the content is in a legacy system that requires significant effort to update.

In these cases:

Provide an alternative access route. This is legally required in most jurisdictions as a “reasonable adjustment” or equivalent. It must be genuinely equivalent — not a degraded substitute. If a PDF is inaccessible, offer to provide the information in an accessible format by email. If a booking form is blocked for screen reader users, offer to take bookings by phone.

Be honest about the timeline. A complainant told “this will be fixed in Q3” is not well served. Commit to specific milestones and follow through.

Escalate internally. Complaints involving core journeys (login, checkout, account management, key forms) should be treated as high-priority engineering issues, not content tweaks. Make sure the right people know.

Responding to regulatory complaints

If a complaint has been escalated to a regulator — GDS in the UK, the DOJ or OCR in the US, or a national enforcement body in the EU — the process is more structured.

You will typically receive:

A formal notice of complaint with the allegations described
A request for a formal response by a specified deadline
In some cases, an invitation to participate in mediation or informal resolution

Do not miss deadlines. A regulatory complaint that goes unanswered, or is responded to late, signals non-cooperation and strengthens the complainant’s position.

Engage with the specific allegations. Regulators expect a response that addresses the specific issues raised, not a general statement about your commitment to accessibility.

Provide evidence of remediation. Where you have fixed the reported barriers, provide documentation: screenshots, audit reports, confirmation of deployment dates. A regulator who can see that the issue has been resolved has significantly less reason to pursue formal enforcement.

Seek legal advice. For formal regulatory complaints, particularly in the US where DOJ investigations can have broad scope, legal counsel familiar with digital accessibility is advisable.

Preventing the next complaint

Every accessibility complaint is evidence that a barrier reached a real user. The goal is not just to resolve individual complaints, but to build systems that prevent new barriers from appearing.

Embed accessibility in your development workflow. Automated accessibility checks in your CI/CD pipeline catch detectable issues before they reach production — not after a user reports them. Our CI/CD accessibility integration makes this part of every build.

Schedule regular audits. Automated tools catch 30–40% of WCAG failures. Manual audits using screen readers and keyboard-only navigation find the rest. Quarterly or biannual audits surface issues before users do.

Train your team. Developers, designers, and content authors who understand accessibility create fewer barriers. One-time training is less effective than embedding accessibility review into design critiques, code reviews, and content publishing workflows.

Make your feedback mechanism genuinely easy to use. An accessibility statement with a working, accessible contact mechanism gives users a direct path to you instead of a regulator. Many complaints escalate precisely because the site’s own feedback channel was itself inaccessible.

If you want to understand your site’s current accessibility position before the next complaint arrives, a free automated scan is the fastest starting point. For the comprehensive picture, get in touch to discuss a full audit.