Accessibility
Built to be used, and checked on every deploy
We build to WCAG 2.1 Level AA. Rather than describe that as a policy, this page lists what the build actually enforces — every check below runs before the site can go out, and a failure stops the release.
There is no accessibility widget here
You will not find a floating button offering to enlarge the text, change the contrast or read the page aloud. Those overlays sit on top of a page and try to guess at repairs while you are using it, and they routinely get in the way of the screen reader, magnifier or contrast setting you already have configured the way you like it.
Your browser and your operating system already do this job, and they do it across every site rather than one. Our part is to write markup those tools can work with, and then to keep checking that we did.
What every deploy checks
Automated rules, on every page
axe-core runs the WCAG 2.0 and 2.1 Level A and AA rule sets against every page, at a desktop width and a phone width, with the mobile menu opened. The build fails on critical and serious findings. Serious is the one that matters: colour contrast is graded serious and never critical, so a build that only fails on critical has no contrast coverage at all while appearing to check everything.
Colour, measured from the stylesheet
Every colour pairing the design system permits is read out of the stylesheet itself and measured. Text has to clear 4.5:1 against what it sits on. Borders, icons and focus rings have to clear 3:1. A colour pairing that is not on that list cannot be used.
Controls that show their state with colour
The store pickers say which location you have chosen mostly through the colour of a border, which makes that border information rather than decoration. It is measured against its background at 3:1, the WCAG 1.4.11 threshold. The automated text rules do not look at this.
The keyboard path, walked for real
Skip to content is the first stop on every page and it moves you into the main content. Every visible control is reachable by Tab. Every stop paints a focus ring you can see. Nothing on the site uses a positive tabindex, which would silently reorder the whole page. The mobile menu keeps focus inside itself, closes on Escape, and puts focus back on the button that opened it.
Coverage that cannot quietly shrink
The list of pages all of the above runs against is generated from the pages the build produced, not typed out by hand. A new page cannot ship without being checked, and a deleted one stops being checked, with no second edit anywhere.
Where this falls short
A statement that lists only what went well is not much use to somebody trying to work out whether they can order dinner. These are the known gaps.
Ordering happens somewhere else
Order Online hands you to Toast, the ordering system the restaurant uses. Those pages are built and operated by Toast, not by us, and nothing above applies to them. If you hit a problem after the handoff, it is worth telling both us and Toast.
Automated checks find a minority of real problems
Rules catch missing labels, bad contrast and broken structure. They cannot tell you whether a heading makes sense, whether an image description is any good, or whether the order of the page is confusing. Testing with screen readers is not complete.
Nobody has tested this who needs it
This has not yet been in front of people who use assistive technology daily. That is the difference between a page that passes and a page that works, and it is the next thing on the list.
Tell us what broke
If something on this site does not work for you, we want to hear it as a bug rather than as feedback. The page you were on and what happened is enough to start with — what you were using to browse helps, if you know it.