Accessibility Statement
Our commitment. VerifyEat is built so that everyone — including people with disabilities — can publish honest menu information and customers can read it. We aim to meet WCAG 2.2 Level AA on the website and to use Apple's accessibility APIs throughout the macOS app.
1. Standards we follow
- Web Content Accessibility Guidelines (WCAG) 2.2 Level AA for the marketing website and any future web app.
- Apple Human Interface Guidelines — Accessibility for the macOS app, including support for VoiceOver, Full Keyboard Access, Dynamic Type, Reduced Motion, and Increase Contrast.
- European Accessibility Act (EAA, Directive 2019/882) as it becomes applicable to our customer-facing services in 2025+.
2. The marketing website
verifyeat.com is designed and built with accessibility in mind:
- Semantic HTML (
<header>,<main>,<nav>,<article>,<footer>, proper headings). - "Skip to content" link as the first focusable element.
- Visible focus indicators on every interactive element (
:focus-visibleoutlines). - Colour contrast meets WCAG AA on body text (≥ 4.5:1) and large text (≥ 3:1).
- Accent gold colour is never used as the only signifier of meaning — it is always paired with text or a shape.
- Light and dark theme support based on the user's system preference.
prefers-reduced-motionis respected — animations are reduced to instantaneous transitions when the user has requested less motion.- Alt text and ARIA labels on all icons, logos, and decorative graphics.
- Forms (when present) are labelled and provide clear error messages.
3. The macOS app
- Built with native SwiftUI controls that inherit Apple's accessibility infrastructure by default.
- VoiceOver-compatible labels on all custom views.
- Keyboard shortcuts for the most frequent actions (⌘N for new product, ⌘F for search, ⌘D for duplicate).
- High-contrast colour scheme available; the app respects "Increase Contrast" in System Settings.
- Dynamic Type sizes are honoured where text is not part of a generated image.
- The phone preview, although a graphical rendering, has accessible read-out for the underlying product data.
4. Public QR product pages
The HTML pages generated by VerifyEat for restaurant customers are designed to be readable by:
- Mobile screen readers (iOS VoiceOver, Android TalkBack).
- Keyboard-only navigation.
- Users with reduced motion or high-contrast preferences.
Allergen information is conveyed using both icons and text labels, never icons alone, so it remains accessible to people who cannot see the icons.
5. Known limitations
We are honest about what is not yet perfect:
- Some illustrative SVGs in the hero are decorative; we plan to add richer aria descriptions in a future release.
- The Mac app's complex form layouts may benefit from additional landmark grouping; this is on the roadmap.
- We have not yet conducted a formal third-party accessibility audit; one is planned within 12 months of public launch.
6. Report an accessibility barrier
If something blocks you from using VerifyEat, we want to know about it. Email accessibility@verifyeat.com with:
- The page or feature where you encountered the barrier.
- The assistive technology you use, if relevant (e.g., VoiceOver on macOS Sonoma).
- What you expected to happen vs. what actually happened.
We aim to acknowledge within 5 business days and provide a fix or workaround within a reasonable timeframe based on severity.
7. Contact
Accessibility issues: accessibility@verifyeat.com
General contact: hello@verifyeat.com