Accessibility Statement

We are working towards WCAG 2.1 Level AA for the native app (the full product — see “Where this applies” below), as a practical benchmark rather than a certification. We have not commissioned an independent accessibility audit, and this statement is our own assessment, not a third party’s.

The work described here is about the native iOS app, which is the actual product. This website is a small marketing and legal site plus a read-only shared-recipe page — it has not had the same accessibility review pass as the native app, and nothing below should be read as a claim about it.

• Colour contrast. An automated test, checked into the codebase and run on every change, measures the app’s colour palette against WCAG’s own thresholds — 4.5:1 for body text, 3:1 for icons and other non-text controls — for every place in the app we’ve identified those colours being drawn, including text sitting on a tinted background. Three colours that fell short of that bar have been darkened; the test fails if either the override regresses or a raw, non-adjusted colour is used in their place.
• Reduced motion. Every custom, continuously looping animation in the app — the bouncing-emoji and pulsing-dot loading indicators, and skeleton placeholders — checks the device’s system-level Reduce Motion setting and shows a static alternative instead when it’s turned on.
• Larger text sizes. The app’s buttons are built with a minimum height rather than a fixed one, so that if you use a larger text size, the label can grow the button to fit instead of being clipped or overlapping. Not every control is built this way yet — a few, like the tab bar and dropdown pickers, still use a fixed height today.
• Screen readers. Interactive elements across the app’s screens — buttons, tabs, cards, form fields — carry a label and role so tools like VoiceOver and TalkBack can announce what they are and what they do.

We would rather list these than let the section above stand in for a blanket claim:

• No independent or professional accessibility audit has been done. Everything above is our own, code-level verification.
• The contrast check covers a maintained list of where each colour is drawn in the app. It is kept up to date by hand as the app changes, not derived automatically, so it can only be as complete as that list is.
• We have not verified on a physical device that every screen holds up correctly at the largest Dynamic Type text sizes — the layout work described above is designed to accommodate it, but that has not been confirmed end-to-end by hand. It also doesn’t cover every control yet: the tab bar and dropdown pickers use a fixed height today, so their text could still be clipped at the largest sizes.
• Disabled controls (greyed out while unavailable) are not held to the same contrast bar as active ones — this follows WCAG’s own exemption for inactive interface components, not an oversight.
• We have not done a full manual pass with a screen reader across every screen — the labels and roles above are applied consistently, but that is not the same guarantee as a hands-on audit.

If something in Dish is hard or impossible to use because of a disability, please tell us. Email callumdeas@gmail.com with what you were trying to do, the device and assistive technology you were using (for example VoiceOver on iOS), and what happened. Dish is built by one person, so we can’t promise a fixed turnaround, but we do read and respond to every report, and genuine barriers are the kind of bug we prioritise.

We’ll revise the “last updated” date above whenever the accessibility work described here changes, so this stays an accurate picture rather than a stale one.