Reporting an accessibility barrier

What follows is the real lifecycle a report goes through, start to finish, and what each stage actually commits to.

01What counts as a barrier worth reporting

Anything that makes the product harder or impossible to use because of how someone perceives, navigates, or interacts with it counts — a screen reader that can't reach a control, contrast too low to read comfortably, a call flow that doesn't accommodate a communication difference, a document that isn't available in a format someone can actually use. It doesn't have to block every user, and it doesn't have to be something a person can point to a specific standard for — if it's a real obstacle to using the product, it's worth reporting.

It's also not limited to one kind of person hitting it. A restaurant's own manager running into a console screen that doesn't work with a screen reader reports it the same way a caller running into a call flow that doesn't accommodate how they communicate does — same case process, same lifecycle, regardless of which side of the product the barrier showed up on. Nobody needs to already be a Dohos customer to report one.

02The real lifecycle, stage by stage

A report starts with an acknowledgment that does real work rather than just confirming receipt — it assigns a case, and it's explicit about what it isn't:

“Not a conformance conclusion” is a deliberate phrase, not a hedge. Acknowledging a report doesn't mean a formal finding has been made about whether something meets any particular accessibility standard — that's a separate, later judgment. A related but distinct starting point is a direct written request for material in an accessible format — not necessarily a barrier report, just someone asking for something they need:

That last sentence protects the person making the request as much as it protects Dohos — an accessible-format request almost never actually needs medical documentation to be honored, and asking for it by default would be its own kind of barrier. Once a barrier is real and confirmed, the response isn't “we'll fix it eventually and say nothing until then.” An immediate, practical workaround comes first, stated alongside the state of anything already in progress:

A workaround exists to close the gap right now, not to replace an actual fix. The next stage names the real fix and a real commitment to check it actually worked:

“Retesting with the appropriate method” is doing real work in that sentence — a fix that hasn't actually been checked against the barrier it was meant to solve isn't treated as done yet. Only once that retest happens does a case close, and even then, the resolution is worded carefully, never as more than it actually is:

03Two situations that don't resolve the ordinary way

Sometimes the fix isn't a correction to something broken — it's a specific accommodation approved for a specific situation, like a modified process for one account. That gets its own real accountability if it isn't actually delivered as promised:

And sometimes the honest answer to a specific request is no — not every requested method can always be provided exactly as asked. When that happens, the response doesn't stop at the refusal:

A refusal paired with a genuine alternative and a real path to ask for review is a fundamentally different thing than a refusal that just ends the conversation. Both halves of that sentence matter equally.

04When the barrier is only partly Dohos's to fix

Not every barrier sits entirely inside Dohos's own product. Sometimes part of it belongs to a restaurant's own content, or to a technology partner Dohos works with rather than controls directly. That doesn't become a reason to disclaim the whole thing:

The report still gets routed to whoever actually controls the part that's broken, and Dohos still stays accountable for its own share — coordinating the fix and keeping the case updated — rather than closing it out because the root cause sits somewhere else.

05How to actually report one

1. Say what and where. The specific page, flow, document, or call, and roughly when it happened — enough for the report to be reproducible, not necessarily a technical description of the issue.
2. Name a preferred accessible contact method, if there is one — the case acknowledgment asks for exactly this, and it shapes how every update after that point actually reaches the person who reported it.
3. Write to support if this is the first report of its kind — it routes to the right channel regardless of which specific stage above the issue eventually reaches.

06If a report doesn't go the way this page describes

• A report comes back saying it “isn't a conformance conclusion.” That's accurate, not an evasion — the case is real and under review; a formal statement about whether something meets a specific standard is a separate, later judgment from the initial acknowledgment.
• A fix was made, but the resolution message doesn't say “fully accessible.” That's deliberate — see the note above. A specific barrier gets fixed and retested; that's the honest scope of the claim, on purpose.
• The requested exact accommodation can't be provided. Look for the alternative and the appeal path in the same response — a genuine refusal always comes paired with both, not with a dead end.
• The barrier turns out to involve a restaurant's own content, not Dohos's product. The report still gets routed and tracked under one case, and Dohos keeps its own share of responsibility for coordinating a real fix.
• A workaround was offered, but it doesn't actually work for the specific situation. Say so through the same case rather than starting a new report — the case already has the context.