01The conformance target
Dohos's accessibility policy sets WCAG 2.2 Level AA as its engineering and design target across the public site, the operator console, and the AI voice channel — not WCAG 2.0 or 2.1, and not Level A or AAA. That target applies to every surface the policy covers: public pages, the restaurant account and administrative interface, AI-assisted voice interactions, SMS and email notices, the payment-routing steps Dohos controls, and downloadable legal and support documents.
In concrete terms, the target requires:
- keyboard operation without traps, with visible and logical focus order
- sufficient text and non-text contrast, with support for resizing, reflow, zoom, and spacing
- meaningful alternative text and captions or transcripts where media is used
- controls that don't rely on color, sound, motion, or position alone to carry meaning
- status messages and errors exposed to assistive technology, not just shown visually
- understandable language and navigation that stays consistent from page to page
- accessible authentication and account recovery
- motion, flashing, and auto-updating content that a person can control or turn off
02A target, not a certification
Dohos's own policy is explicit that a technical target does not by itself decide legal compliance, which depends on the actual context a specific claim is made in — and it is equally explicit that automated scanning alone cannot establish conformance, and that an accessibility overlay is not a substitute for accessible code or a basis to claim compliance. Both of those are stated here because they are exactly the kind of claim a page like this one is tempted to make and shouldn't.
03How the target gets tested
The policy's design-and-development lifecycle requires accessibility acceptance criteria defined at design time, not bolted on afterward, and both automated and manual testing of complete workflows — not only individual components in isolation. Where practicable, testing includes people with a range of disabilities and assistive technologies directly, with consent and privacy safeguards, rather than relying solely on internal review.
- accessibility acceptance criteria are part of a feature's design, not a post-launch checklist
- both components and complete end-to-end workflows are tested, automatically and manually
- release changes are checked for accessibility regressions before they ship, not after a complaint arrives
- each known issue is tracked with a severity, an owner, a workaround where one exists, and a retest once it's fixed
04The VPAT
A Voluntary Product Accessibility Template is a real, produced document — the output of an actual conformance evaluation against a named standard, typically performed or reviewed by an independent party. Dohos has not completed one.
05The voice channel specifically
The accessibility statement covers voice-channel accessibility as part of its full commitment — pacing, repetition, correction, and a human fallback. What that page states as a target, Dohos's internal policy requires to actually be tested: speech-recognition performance across accent, disability, noise, and assistive-technology use is expected to trigger a clarification and a fallback rather than a fabricated best guess at what was said, and recording is explicitly not a precondition for receiving an accommodation — a caller does not have to consent to being recorded in order to get help.
06Legal documents and requested modifications
Terms, privacy notices, consent requests, contracts, and receipts have to be usable before the action they govern, not just archivable afterward — Dohos's policy requires these in accessible HTML or an equally effective format, with a PDF or download never standing in as the only accessible path to a document someone has to act on.
Where a barrier prevents someone from completing a step the standard flow doesn't support, a trained reviewer assesses the specific request individually — what the barrier is, what outcome is needed, and what alternative would actually work — rather than applying a single fixed workaround to every case. A default product limitation on its own is not treated as a sufficient reason to deny reasonable help, and the decision and remedy are recorded rather than handled informally and forgotten.
07Reporting a barrier
An accessibility barrier found on the site, in the operator console, or on a call is treated as a real defect with an owner and a fix, not a comment for a future release. Report one through support today; it is routed and tracked the same way any other reported defect is.