Accessibility

1. Why this page exists

Gid is built for every operator and every employee in a restaurant. That includes the manager who reads on a 5-inch phone screen between covers, the line cook whose first language is not English, the host who relies on a screen reader after an eye injury, the owner who runs the floor without a mouse because both hands are full. If the app does not work for any of you, the app is broken. We treat accessibility as a product requirement, not a checkbox.

This page tells you what we have built, what we are still working on, and how to reach us when something blocks you. We will not pretend we are done. We will tell you where the gaps are and what we plan to fix next.

2. Standards we follow

3. What we have built

Site (gidai.ca)

• Semantic HTML on every page. Headings are in order. Buttons are buttons, not divs.
• Color contrast at or above 4.5:1 on body copy and 3:1 on large text. The orange accent and the dark Founders Programme background were both verified.
• Every interactive element is reachable by keyboard alone. Focus states are visible and high-contrast.
• All informational images carry alt text. Decorative images use empty alt or aria-hidden so screen readers skip them.
• Forms have visible labels, helper text, and error messages tied to each field.
• The site renders cleanly down to 320 px width without horizontal scrolling. Text reflows; nothing is locked to a fixed pixel size.

Gid app (web and mobile)

• Built on Flutter, which gives us first-class screen reader support across Web, Android, and iOS through Semantics widgets that map to platform a11y trees.
• Touch targets are at minimum 44 by 44 logical pixels. We test on actual phones, not just simulators.
• The app honors system-level dark mode and reduced-motion preferences. We do not autoplay video.
• Notifications go through a single AppNotificationService. The glassmorphic banner has a 5-second default that respects screen reader announcement timing.
• Voice features are optional. Every voice action has a tap equivalent. No part of the product requires speech to be usable.

Documents and downloads

• Invoices and exported reports are tagged PDFs. Headings, tables, and lists carry their semantic structure into the file so a screen reader can navigate the document the same way it navigates the app.
• CSV exports use real column headers and consistent date formatting so assistive technology and translation tools can parse them cleanly.

4. Where we are still working

• Voice receptionist preview. The optional AI receptionist for Gid Reservations does not yet have a fully captioned demo on the marketing site. Closed captions ship with the production launch of Gid Reservations later this year.
• Hindi screen-reader coverage. Our Hindi mirror at gidai.ca/hi/ is read correctly by NVDA and VoiceOver, but TalkBack pronunciation on certain Devanagari ligatures is uneven across Android versions. We have an open ticket and review monthly.
• Schedule heatmap colors. The manager-side schedule heatmap uses red and green to flag understaffed and overstaffed shifts. We have shipped a textured pattern toggle for color-blind users; the default still leans on color. We are testing a fully pattern-first version that any user can opt into in settings.
• Long-form playbook articles. Some of our build-in-public posts on the changelog use code blocks without explicit language hints. Screen readers therefore read code as plain prose. We are migrating to explicit language attributes across older posts.
• Captioning lag on live feature videos. Captions on demo videos are auto-generated and reviewed manually within 24 hours of upload. We will move to human-first captions when video production scales past one a week.

5. How we test

• Automated checks on every dev push: axe-core via the dev-validation CI gate, Lighthouse audits weekly, and color-contrast linting against the design tokens.
• Manual screen-reader runs once per sprint on the changed surfaces: NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
• Keyboard-only navigation runs on every new screen before merge to main.
• Annual review of the Multi-Year Accessibility Plan, with feedback received from operators logged into the plan and tracked to closure.

6. Tell us when something blocks you

This is the part that matters most. Accessibility ships best when the people who hit walls tell us where the walls are. If you cannot do something with Gid that you should be able to do, we want to hear about it. We will respond within 2 business days, and we will tell you the truth about whether we can fix it this sprint or whether it lands later.

7. Our commitment

We are a small team of former restaurant operators. We will not always get accessibility right on the first try. We will always tell you where we are, where we are going, and what we are doing about gaps you raise. Accessibility is part of how we build with the industry, not a separate workstream we maintain to look compliant. The 500 Founders who back us early help shape this list every quarter — your feedback is the reason this page gets longer over time, and shorter where the gaps closed.