Accessibility Statement

Our commitment

We want this website, the ordering sites we host for restaurants, and the Cobblestone POS applications to be usable by everyone, including people who use a screen reader, navigate by keyboard, rely on magnification, or need larger text and higher contrast.

We aim to meet Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. We are not claiming full conformance — we have not had an independent audit — and this statement describes honestly where we are.

What we have done

• Pinch zoom is never disabled on a customer-facing page. We do not set `user-scalable=no` or a maximum scale, which is a WCAG 1.4.4 requirement and something a lot of restaurant sites get wrong.
• Form fields are at least 16px on touch devices. Below that, iOS Safari zooms the page the moment a field is focused and does not zoom back, which leaves a customer on a sideways-scrolling checkout with the pay button off screen. This is enforced automatically on every build, not left to review.
• Keyboard navigation works through menus, forms and checkout, with a visible focus indicator.
• Semantic markup — real headings, lists, labels, tables with header cells, and landmark regions, so a screen reader can navigate structurally.
• Labelled form controls, with errors reported in text rather than by color alone.
• Text contrast is checked against the 4.5:1 ratio for body text on our own pages.
• Alternative text on meaningful images, and decorative images marked so a screen reader skips them.
• Layouts reflow to phone width without horizontal scrolling, and respect the device safe area so nothing hides under an iPhone home indicator.
• No flashing or auto-playing audio, and motion kept to transitions rather than animation that could trigger discomfort.

Known limitations

Being straight about the gaps:

• No independent audit. Our accessibility work is internal review plus automated checks. We have not commissioned a third-party WCAG audit or user testing with assistive technology users.
• Signage and kiosk displays — menu boards, marketing displays and kitchen screens — are built for a fixed TV or a mounted tablet and do deliberately restrict zoom. They are not interactive customer interfaces, but they are also not adaptable, and a printed or spoken menu should always be available to a guest who needs one.
• Older devices. Some of our customer-facing apps need iOS 16.4 or newer for full visual fidelity. On an older iPhone a few surfaces may render with less contrast than intended. Content and function remain available.
• Older blog posts may contain images whose alternative text is thinner than it should be, and PDFs we did not author may not be fully tagged.
• A restaurant's own content. We host ordering sites, but each restaurant writes its own menu text and uploads its own photos. If a description or an image lacks useful alternative text, that content belongs to the restaurant — tell us anyway and we will pass it on and help them fix it.
• Third-party components. Payment card fields are supplied by our payment gateway and run in its own frame. We set their font size to avoid the zoom problem, but we do not control their internal markup.

Tell us about a problem

If any part of Cobblestone POS blocks you, we want to know — a specific report is worth more to us than a generic audit. Email hello@cobblestonepos.com and include, if you can:

• The page or screen, and a link if you have one.
• What you were trying to do, and what happened instead.
• Your device, browser and any assistive technology you use.

We aim to acknowledge a report within 3 business days and to tell you our plan and a timeframe within 10 business days. If a fix will take longer, we will say so and offer another way to get the task done in the meantime.

Another way to get it done

If something on a restaurant's ordering site is not working for you, you can always call the restaurant and order by phone. If something in Cobblestone POS is blocking you as a merchant, email us and a person will walk through it with you or do it on your behalf.

How we keep this current

Accessibility checks run automatically whenever we build a customer-facing app, and a build fails rather than ships if it breaks the rules above. We review this statement when we make a significant change to a customer-facing interface, and the "Last updated" date shows the last review.