Treat it as a bug report, because that is what it is. Somebody has told you a task cannot be completed in a configuration you did not test. The work is to capture enough detail to reproduce it, reproduce it, fix it, and prove the fix with the same evidence you captured at the start.
What this page covers, and what it does not
The technical record and the retest. Not the reply, not any deadline, and not whether anybody is liable. Those depend on where you are and what was said, and they belong with your own counsel.
Write It Down Like a Bug, Because It Is One
The fields a federal accessibility test report is expected to carry are the right fields for a complaint record too, and they are the ones that make the difference between a ticket somebody can act on and a ticket that gets closed as unclear.
- What and where. The page or screen, the exact step, and what was supposed to happen instead.
- The product version. Yours, and theirs if they told you. A report against last month's build is about last month's build.
- The environment. Operating system, browser and version, and the assistive technology and version if one was in use.
- The steps. Enough of them that somebody else can arrive at the same place without guessing.
- Evidence. A screenshot, a recording, or a code snippet. Whichever of these the reporter gave you, keep the original.
- Severity, as a planning label. Critical, high, medium and low are a reporting convention rather than anything in WCAG, and they are useful for ordering work, not for deciding whether a criterion was met.
Ask for what is missing once, kindly, and in one message. A person who has just failed to complete a task is not owed an interrogation, and the second round of questions is where most reports go quiet.
Reproduce It in the Same Combination
Try it in the combination they described before you try it in yours. Screen readers, browsers and operating systems interact, and a barrier that appears in one pairing can be genuinely absent in another. This is not the reporter being unreliable. It is why the standard has a concept of accessibility support at all.
If their combination sits outside the baseline your audit tested against, you have learned something worth acting on. W3C's method allows the baseline to be extended mid-evaluation when the evaluator reaches for something new, and a real user hitting a real barrier is the clearest reason there is to extend yours. Our screen reader testing guide covers getting set up in the common pairings.
When You Cannot Reproduce It
Not reproducing something is a result about your attempt, not about their experience. Before you record it as unreproducible, check the four things that most often hide it: a different assistive technology version, a different browser, a feature flag or A/B variant they were in and you were not, and a state you cannot easily reach, like a validation error on the third field.
Then tell them what you tried. A message saying which combination you tested and asking whether they would recognize it is a reasonable thing to send, and it often produces the missing detail in one reply.
Nobody Has to Prove a Disability to Report a Bug
Do not ask. It is not relevant to whether the barrier exists, you cannot verify the answer, and asking turns a person who did you a favor into somebody defending themselves. The technical question is whether the task can be completed with the technology they were using, and that question stands on its own.
The same goes for judging whether the complaint is serious enough. A report that a form cannot be submitted by keyboard is a report that a form cannot be submitted, and it does not become smaller because one person sent it.
Why the Scan Came Back Clean
The usual first move is to run a scanner over the page, and the usual result is nothing. That is a fact about scanners. On our own classification of W3C's 432 techniques and documented failures we graded 356, and 10 of those can be settled by a machine outright. And 49 of the 86 success criteria in WCAG 2.2 have no automated rule written against them at all.
So a clean scan after a complaint tells you the failure is in the majority of the standard that tools do not reach, which is where most real barriers live anyway. Use the scanner to clear the mechanical noise, then go and do the task yourself with the keyboard and with a screen reader.
What the Retest Has to Show
The same shape as the original finding, from the other side. The same steps, the same environment, and the task completing this time. A ticket marked done is not evidence, and a code review is not evidence either, because the question was never whether the change was written but whether the barrier is gone.
Keep the before and the after together in one record. If the same person reports something similar in six months, that pairing is what tells you whether it is a regression or a new problem, and if the fix ever comes up in a conversation you did not expect, it is the only thing you will wish you had.
The Part We Are Not Covering
Whether a reply is owed, by when, in what form, and what it should say are questions about your jurisdiction and your own situation. So is anything about liability. Our law pages explain what the various regimes require of whom, and a qualified adviser in your jurisdiction is who decides how that applies to the message in your inbox.
What we would say about the timing is narrower and is about the work rather than the law. Fixing it is faster when the record is complete, and the record is only complete on the day it arrives.