Accessibility Statement

Palatis should work if you navigate by keyboard, read with a screen reader, need larger text, or find motion uncomfortable. This statement says what we target, what currently meets it, what does not, and how to tell us when we get it wrong.

Our target

We aim to conform to the Web Content Accessibility Guidelines version 2.2 at level AA across palatis.app and the web app. We are partially conformant: most of the site meets the standard, and the exceptions below do not yet.

We treat accessibility as part of shipping rather than a later pass. A change that breaks keyboard operation, contrast or heading structure does not go out, and the checks below run on every release.

What conforms today

• Keyboard. Every interactive element is reachable and operable by keyboard in a logical order, with no trap. A skip link jumps to the main content as the first stop. Focus is always visible, with a high-contrast ring that does not rely on colour alone.
• Structure. One h1 per page, headings in order without skipped levels, landmark regions for header, navigation, main and footer, and lists marked up as lists.
• Contrast. Body text on the cream ground measures well above the 4.5 to 1 minimum, and large display text above 3 to 1. Pill buttons, form borders and the focus ring meet the non-text contrast requirement.
• Text scaling. The layout is fluid and survives 200 percent zoom and a 400 percent reflow at 320 pixels wide without horizontal scrolling or clipped content.
• Images. Informative illustration carries alternative text describing what it conveys. Purely decorative shapes — the coloured blobs and circles — are hidden from assistive technology so they do not add noise.
• Forms. Every field has a visible or programmatically associated label, errors are announced in text next to the field rather than by colour, and confirmation messages go through a polite live region.
• Motion. Reveal and hover animation is subtle, never conveys meaning, and is switched off entirely when your system asks for reduced motion. Nothing autoplays, flashes or loops.
• Without JavaScript. The whole site reads and navigates with scripts disabled. The FAQ uses native disclosure elements, and forms degrade to plain submissions.
• Language. Page language is declared, and the language switch marks each option in its own language.

Known exceptions

• The card carousels. The rails on the paths, chef and testimonial sections scroll horizontally. The scroll container is keyboard focusable and arrow-key scrollable, and no card is unreachable — but the previous and next buttons and the position dots are a weaker experience with a screen reader than a plain list would be, and the dots do not yet announce the total count. We are moving these to a paged listbox pattern with a visible all view. Target: next release cycle.
• The illustrated art. The market scene, the portrait and the app screenshots carry short alternative text, but a dense illustration cannot be fully described in a sentence. Long descriptions are planned for the market scene and the flavor map. Target: within two release cycles.
• The flavor map radar. The five-axis chart is currently an image with a text summary beside it. A table of the same values is planned so the numbers are readable in any order. Target: with the long descriptions.
• Older journal posts. A handful of posts published before this statement contain images without adequate alternative text. We are working backwards through the archive.
• Partner checkout. The grocery hand-off finishes on a partner site we do not control. We test partners before integrating and raise defects with them, but we cannot guarantee their conformance. Tell us if a partner blocks you and we will escalate it with them and, if it does not improve, drop them.

How we test

Every release is checked by keyboard only, at 200 percent zoom, and with a screen reader — VoiceOver on macOS and iOS, NVDA on Windows — on the pages that changed. Contrast is verified against the design tokens rather than sampled by eye, so a colour change cannot quietly fail. Automated checks run in the build. Automated checks find perhaps a third of real problems, which is why the manual pass is not optional.

An external audit is scheduled for the second quarter of 2026, and we will publish its findings and our remediation dates here.

Compatibility

We support the current and previous major version of Chrome, Edge, Firefox and Safari, on desktop and mobile, with VoiceOver, NVDA, JAWS and TalkBack. Very old browsers still receive readable, navigable content, just without the visual polish.

Tell us when it fails

If something blocks you, email [email protected] with the page address, what you were trying to do, and the browser and assistive technology you were using. Put accessibility in the subject and it is routed straight past the general queue.

We acknowledge within two working days and give you either a fix or a dated plan within ten. If you need something from Palatis that the site will not give you — an export, a price, an answer the FAQ hides behind a carousel — ask, and a person will send it to you in a format that works. If our answer does not satisfy you, you can raise it with the Dutch authority responsible for accessibility enforcement or, in the EU, with the body designated in your own country.

This statement

Prepared on 17 February 2026 by the Palatis product team, based on our own keyboard, screen reader and contrast testing of the current release. We review it every six months and after any significant redesign. Next scheduled review: August 2026.