Accessibility is a baseline requirement for every surface we ship — the marketing site, the operator dashboard, and the diner-facing websites and ordering pages we generate on behalf of restaurants. This page documents the standards we follow, what we have tested, where we know we fall short, and how to report a barrier.
1. Our commitment
RestaurantGPT is committed to making the marketing site, operator dashboard, and the diner-facing surfaces it generates (websites, ordering flows, receptionist transcripts) usable by people with the widest possible range of abilities and assistive technologies. Accessibility is treated as a product requirement, not a one-time audit.
2. Standards we follow
We design and test against the Web Content Accessibility Guidelines (WCAG) 2.2 at conformance level AA. The dashboard and the customer-generated websites are reviewed against this standard. Where we fall short of AA on a specific surface, we list the gap below and the planned remediation date.
3. What this means in practice
Across our surfaces we aim to provide: visible focus indicators on all interactive elements, keyboard operability without a mouse, semantic landmarks for screen readers, alt text for meaningful images, color contrast at or above AA ratios, captions on demo videos, ARIA only where native semantics are insufficient, motion-reduction respect for the prefers-reduced-motion media query, and form errors announced to assistive technology rather than only shown visually.
4. Operator-generated content
When operators publish a website or ordering page through the platform, the underlying templates ship accessible. However, content the operator uploads — menu photos, custom HTML in long-form descriptions, embedded videos — can introduce barriers we cannot guarantee. The dashboard surfaces accessibility warnings for missing alt text and low-contrast color choices, and we recommend acting on them before publishing.
5. Known gaps
We maintain a public list of known accessibility gaps and remediation timelines. As of the date above, the most material open items are: (a) keyboard navigation in the legacy reporting charts (target fix Q3 2026), (b) screen-reader announcements for live order-status updates in the operator dashboard (target fix Q3 2026), and (c) full caption tracks on archived webinars (rolling). When new gaps are discovered, we add them here within two weeks.
6. Assistive technology we test with
We routinely test with NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android, keyboard-only navigation, browser zoom up to 400%, and high-contrast mode in Chrome and Edge. We use automated tools (axe-core in CI) to catch regressions, but treat manual testing as the source of truth.
7. Report a barrier
If you encounter an accessibility barrier on this site, in the operator dashboard, or on a website generated by the platform, please email accessibility@restaurantgpt.xyz with: (a) the URL or screen, (b) the assistive technology and browser you were using, and (c) what you were trying to do. We aim to acknowledge within 2 business days and provide a remediation timeline within 10 business days.
8. Procurement (Section 508 / EAA)
For US public-sector procurement, an Accessibility Conformance Report (ACR) following the Section 508 / Revised 508 VPAT 2.5 template is available on request. For European customers, we maintain a statement of compliance with the European Accessibility Act (EAA) for the consumer-facing surfaces. Email accessibility@restaurantgpt.xyz to request either document.
9. Continuous improvement
Accessibility is a moving target — guidelines change, browsers and assistive tech evolve, and we ship new product surfaces every week. We review accessibility quarterly and after every major release, and update this statement when our practices, standards, or known gaps change.
Questions? Reach us at our contact page or by email at accessibility@restaurantgpt.xyz.
Back to top ↑