This is a proposed accessibility statement for a future Dohos service. It is not a claim that any website, application, voice channel, legal document, Restaurant flow, Provider surface, or alternative method conforms to a standard or law. The Dohos legal entity, contacts, release scope, supported devices and languages, audit results, known barriers, remediation status, and assistance operations this statement depends on remain unverified. This draft must not be published until its statements match tested live behavior and every activation condition below is satisfied.
01Commitment
Dohos intends to make its activated services and material legal, ordering, payment, support, privacy, cancellation, and dispute information usable by people with disabilities.
Accessibility is an operating requirement, not only a public statement. The activated version must be supported by current testing, a staffed assistance route, barrier remediation, Provider oversight, and release controls.
If a person cannot use an activated Dohos feature, Dohos and the relevant Restaurant should provide a practical alternative for the requested function where required and reasonably available. Requesting assistance must not reduce a person's rights, change a Restaurant price, require unrelated Personal Data, or force agreement to marketing or another optional practice.
02Scope
The activated statement will identify the Dohos-operated services and versions it covers, which may include approved:
- public website pages
- Restaurant Account and administrative interfaces
- Diner web ordering and order-status flows
- AI-assisted voice interactions
- SMS and email notices
- payment-routing and confirmation steps controlled by Dohos
- privacy, security, legal, support, cancellation, and dispute routes
- downloadable documents and reports
- human or alternative support methods
It will also identify material exclusions and independently controlled surfaces.
This statement does not automatically cover:
- a Restaurant's premises, personnel, independent website, app, content, menu, or service
- a Restaurant's independent delivery or loyalty provider
- a Payment, Communications, AI, hosting, map, video, or other Provider's independent surface
- a third-party link
- a demo, prototype, test, preview, disabled, or future capability
Dohos remains responsible for accessibility duties arising from its own design, content, integration, selection, configuration, representations, and support. A Restaurant or Provider boundary is not a blanket disclaimer.
03No unsupported conformance claim
This draft does not claim:
- compliance with the Americans with Disabilities Act or another law
- conformance with WCAG 2.0, 2.1, 2.2, Level A, AA, or AAA
- certification by an accessibility organization
- compatibility with every browser, device, operating system, assistive technology, language, or disability
- that no barriers exist
- that an automated scan proves accessibility
The activated version may reference a specific target or evaluated standard only if the scope, version, success criteria, methodology, dates, environments, exceptions, findings, and evidence are current and approved. A target is not the same as conformance.
04Target design practices
For the activated scope, Dohos should implement and verify practices appropriate to the interface, including:
- semantic structure, headings, landmarks, labels, names, roles, and states
- keyboard operation without traps
- visible and logical focus order
- text and non-text contrast
- text resizing, reflow, zoom, spacing, and orientation support
- meaningful alternative text and captions/transcripts where appropriate
- accessible forms, instructions, errors, validation, and correction
- status messages and updates exposed to assistive technology
- controls that do not rely only on color, sound, motion, location, or sensory characteristics
- motion, flashing, timeout, and auto-update controls
- understandable language and consistent navigation
- accessible authentication and recovery
- durable, accessible legal and transaction records
- touch target and mobile usability
- testing with representative assistive technologies and disabled users where practicable
The exact activated practices and test results must be described truthfully. This list is a target, not evidence of implementation.
05Ordering and transaction accessibility
An activated Diner flow should allow a person to independently or with requested assistance:
- identify the Restaurant and location
- review the menu and material Restaurant information
- understand item options, availability, prices, discounts, taxes, mandatory fees, tips, and total
- communicate and verify allergy, dietary, fulfillment, and other material instructions without the system changing their meaning
- add, remove, and correct items
- distinguish an Order Request from Restaurant acceptance
- understand the payment authorization action
- receive confirmation and status
- request cancellation, correction, refund, or dispute support
- obtain a durable receipt or record in an accessible format
The service must not use an inaccessible interface to create consent, final confirmation, payment authorization, waiver, or acceptance that a person could not meaningfully understand or operate.
If a barrier prevents a material step, the approved alternative should provide substantially equivalent information, privacy, price, security, timing, and control to the extent required by law and reasonably possible.
06AI-assisted voice accessibility
An activated voice channel should support, where applicable:
- clear disclosure that the system is automated or AI-assisted
- adjustable or reasonable pacing
- repeat and spelling requests
- correction without restarting the entire interaction
- explicit confirmation of material details
- handling for pauses, speech differences, noise, overlapping speakers, relay services, and supported assistive methods
- text or another alternative channel
- truthful human or Restaurant fallback
- accessible reporting of an error or barrier
The system must not infer disability, capacity, consent, identity, or authority from a person's voice, speech pattern, response speed, assistive method, or request for help.
Natural-sounding speech is not evidence that the channel is accessible. The activated statement must identify tested languages, devices, relay/assistive methods, limitations, and alternatives without overstating coverage. See the AI and Voice Transparency Notice for the full disclosure this section only touches from the accessibility side.
07Communications accessibility
Material calls, texts, emails, and in-product notices should:
- identify the responsible sender and purpose
- use understandable language
- avoid images of text where practical
- provide meaningful link text and accessible destinations
- preserve information outside color or visual formatting alone
- support text enlargement and assistive technology in the approved environments
- provide accessible STOP, HELP, preference, privacy, and support routes
- offer an alternative when a particular channel is unusable
An opt-out or legal request must not fail solely because a person cannot use an exact keyword, CAPTCHA, visual interface, telephone channel, or unsupported document format.
08Legal documents and consent
Terms, Privacy Notices, communications disclosures, payment disclosures, recording notices, consent requests, contracts, receipts, and other material records must be available in an accessible format before the action they govern.
The activated assent or consent process should preserve:
- the exact accessible version presented
- the identity/authority and session context
- the affirmative action
- date and time
- available alternative format or assistance
- any barrier or accommodation request
- a durable copy
Accessibility assistance does not itself create assent or consent. Terms acceptance, payment authorization, Restaurant acceptance, marketing consent, recording consent, and privacy choices remain separate.
09Authentication and security
Security controls should be effective without imposing avoidable barriers. The activated service should evaluate:
- password and passkey flows
- multifactor authentication
- CAPTCHA or bot controls
- timeouts and reauthentication
- identity and payment verification
- recovery and support
- fraud or abuse challenges
Where a control is not accessible, Dohos should provide an approved alternative that preserves a comparable level of security and does not require unnecessary sensitive information.
Security is not a valid reason to deny a lawful accommodation without assessing a practical alternative. Accessibility is not a reason to bypass controls without authority.
10Payment accessibility
An activated payment path should make the merchant, amount, items, price components, tip, total, payment method, authorization action, error, and outcome understandable and operable through the approved accessible methods.
Dohos must evaluate the accessibility of the integrated Payment Provider surface and the transitions into and out of it. If a Provider-controlled barrier affects a material transaction, Dohos should provide support, escalation, and an alternative where required and reasonably available.
An alternative must not expose full payment credentials to ordinary support, AI, recordings, transcripts, logs, or Restaurant personnel. See how Dohos handles cash and card.
11Restaurant Content and responsibilities
The Restaurant supplies or approves menus, images, item descriptions, ingredients, allergens, dietary information, prices, policies, locations, hours, and fulfillment information.
The Restaurant should provide accessible and accurate source content and a practical Restaurant contact for questions it controls. Dohos should provide accessible tools, validation, guidance, and escalation appropriate to its role.
Dohos may not simply publish inaccessible Restaurant Content and disclaim all responsibility when its own platform, transformation, validation, or presentation contributes to the barrier. The activated Restaurant agreement must allocate responsibilities without shifting non-waivable duties.
12Third-party Providers
Dohos may use approved Providers for payment, communications, AI, hosting, authentication, mapping, support, or other functions. Before activation, Dohos should evaluate material Provider accessibility through available documentation, testing, contract diligence, issue history, and fallback design.
Provider certification or conformance documentation is evidence to review, not an automatic Dohos claim. Dohos must not reproduce a Provider's broad accessibility claim as its own without matching scope and verification.
Known Provider barriers affecting the activated service should be disclosed when useful and routed for remediation. A critical inaccessible dependency is an activation or continuity issue, not merely a notice item.
13Compatibility and environments
The activated statement should identify the environments included in the most recent evaluation, such as:
- supported desktop and mobile browsers
- supported operating systems and screen sizes
- keyboard-only use
- selected screen readers and browser combinations
- magnification, zoom, contrast, voice input, switch, or other assistive methods
- supported languages
- voice/relay or alternative ordering methods
14Known limitations
The activated statement should disclose material known accessibility limitations that affect use, including:
- affected feature and user impact
- environments in which it occurs
- interim accessible alternative
- owner and remediation status
- expected date only when reasonably supportable
- last verification date
Dohos must not claim "no known issues" merely because no audit, disabled-user test, monitoring, or feedback route exists.
15Assistance and alternative access
The activated statement will provide a monitored accessibility contact and explain how to request help with:
- accessing information or a legal document
- placing, correcting, or understanding an Order Request
- payment, confirmation, status, cancellation, refund, or dispute
- Account access or authentication
- privacy, communications, or security choices
- another format or communication method
- a barrier involving a Provider or Restaurant surface
The support process should ask only for information reasonably needed to locate the feature and provide assistance. It should not request full payment credentials, unnecessary health details, proof of disability beyond what law permits, or agreement to release claims as a condition of ordinary help.
16Feedback and complaints
The activated feedback route should allow a person to provide:
- the page, feature, call, message, document, or transaction affected
- date/time and Restaurant where relevant
- browser, device, assistive technology, or channel if the person chooses
- a description of the barrier and desired outcome
- a safe way to respond
Providing technical details or disability information should be optional unless reasonably necessary for the requested accommodation. Dohos must protect the report, route Restaurant- or Provider-controlled issues, preserve required evidence, and avoid retaliation.
The process should acknowledge, triage, provide interim assistance, investigate, remediate, test, respond, and allow escalation. The activated statement must publish only response targets the staffed process can meet.
17Continuous improvement
The target program includes accessibility requirements during design, content, procurement, development, testing, release, monitoring, support, incident/change management, and remediation.
Dohos should:
- assign accountable owners
- train relevant personnel
- include accessibility in acceptance criteria
- test representative workflows, not only components
- include disabled-user and manual assistive-technology testing where appropriate
- evaluate material Providers
- prevent regression through automated and manual checks
- track barriers by severity and user impact
- verify fixes in the original context
- update this statement from current evidence
This is a target operating model, not a claim that these activities currently occur.
18Changes to this statement
The activated statement must include a version, last-reviewed date, covered release/scope, and material known changes. A product, content, Provider, Restaurant flow, legal-document, support, language, or compatibility change may require renewed testing and an updated statement.
An updated statement does not retroactively cure an inaccessible flow or defective assent, consent, payment, cancellation, privacy request, or transaction. Prior versions and issue evidence must be preserved at the version archive.