Accessibility
Draft for legal review — not yet in force. The known-gaps list in §4 has now been re-checked against the built product; what remains before publication is counsel’s review of §2 and §6.
Last updated 29 July 2026.
The short version
- We build to EN 301 549 v3.2.1, which means WCAG 2.1 Level AA.
- We are not fully there yet, and §4 lists exactly where we are not. We would rather publish an honest gap list than a badge.
- Found a barrier? [email protected]. We reply within 5 working days, with a workaround if we have one and a date if we do not.
- This is an obligation under the European Accessibility Act, not a courtesy, and we treat it that way.
1. Why this page exists
The European Accessibility Act has applied to consumer services since 28 June 2025. Voyade is a consumer service sold in the EU, so accessibility is a legal requirement and a design constraint, not a nice-to-have on a backlog.
It is also, frankly, the right way to build a group product. A trip group is a mixed bunch of people and devices. If the least-motivated member cannot vote on their phone, the product has failed at its own job.
2. What we build to
Standard: EN 301 549 v3.2.1, the harmonised European standard, which incorporates WCAG 2.1 Level AA.
Status: partially conformant. Most of the product meets the standard. The parts that do not are listed in §4 with what we are doing about them.
We do not rely on the microenterprise exemption. The Act exempts very small service providers. We are not going to lean on that, because a person using a screen reader does not care how many people we employ.
3. What we have actually built
These are commitments enforced in our design system and tested in our build, not aspirations.
Contrast and colour
- Body text sits at 8.1:1 against the page, and our quietest grey — the one under a card, on a timestamp — at 4.98:1. Both are above the 4.5:1 the standard asks for. These are measured in a browser on every build, not read off a palette: a colour that passes on paper can still fail once it has been through a faded card or a gradient over a photograph, and ours did in six places until we measured.
- Colour never carries meaning on its own. Every state also has a word or an icon:
BOOKED ✓,MUST ×4,FREE,WAITING. If you cannot distinguish our green from our amber, you lose nothing. Links in running text are underlined, not just coloured. - Dark surfaces hold at least 4.5:1.
Keyboard and focus
- The focus ring is 2px, at 2px offset, and is always visible on keyboard navigation. We do not remove focus outlines.
- Vote controls, day chips and tab bars are real radio and tab groups with arrow-key
navigation, not styled
divs.
Screen readers
- The map, the route drawing and the recap statistics all have text equivalents in the DOM. The route is also a list of places, and when a trip has no place names to list it says how many days it drew rather than announcing a list and then not providing one. Each recap statistic is also a sentence — “2,300 km driven”, not a number and a label read out as two unrelated facts. The map’s pins are buttons carrying the name and the state in words, so “walkable” and “out of reach” do not depend on seeing green and grey.
- Timed content — the “leave by 14:20” countdown in Travel mode — announces politely once per threshold, not once per second. Being told the time every second is not accessibility.
- Form labels always sit above the field. There are no placeholder-only inputs.
- Errors appear below the field and say the fix, not the rule — “add a date to publish this” rather than “this field is required”.
Motion
prefers-reduced-motionis respected everywhere. All transforms become opacity crossfades at 120ms, the recap route renders complete rather than drawing, counters render their final value, and the only looping animation in the product — the leave-by chip — becomes static.- Nothing becomes unreachable when motion is off. Swipe still works; only the tracking animation goes.
Touch and mobile
- Minimum target size 44×44 on mobile.
- Body text does not go below 12px on mobile.
- Nothing depends on hover. Anything revealed by hover on desktop is either always visible on mobile or available on long-press.
- Primary actions are thumb-reachable, and safe-area insets are honoured so a sticky button never sits under the home indicator.
Every gesture has a button. Swiping between days, keep-and-skip on a proposed change — both have a non-gesture alternative that does the same thing. Reordering items is the exception, and §4 says so.
4. Where we fall short — the honest list
Every item below was re-checked against the built product on 29 July 2026, in a browser, by someone using a keyboard. One entry turned out to be describing a workaround that does not exist and is corrected below; two entries were added. We would rather correct this list in public than let it age quietly.
The map, for screen reader users. The map has a text equivalent — the day’s places as an ordered list, each pin a button carrying its name and its state in words. That is genuinely usable. But it is a parallel experience, not an equal one: you cannot explore spatially, pan to see what is nearby, or tap a pin. We do not have a good answer to this yet and we are not going to pretend the list is the same thing.
Moving an item to a different day. Within a day, reordering is fully keyboard operable: focus the handle, press space to pick the item up, arrow it into place, space to drop, escape to leave it where it was. Every step is announced.
Moving an item to a different day is drag-only. An earlier version of this page said there was a “Move to day” menu on every item as the alternative. There is not — we checked, and the sentence was wrong. Nothing else in the product gets you there without a pointer. This is our highest-priority accessibility fix, and until it ships the workaround is to delete the item and re-add it on the day you want, which is not good enough and we know it.
Which proposed change you are looking at, on a wide screen. On the desktop proposal review, the ghost list highlights the change under your pointer. There is no keyboard equivalent for that highlight. The keep and skip buttons themselves are fully reachable and operable, and each change’s rationale is read out with it, so nothing is unusable — you just lose the “you are here” cue that a mouse user gets.
Alt text on photos. Photos in the feed and in trip albums are uploaded by people, and most people do not write alt text. We generate a description for template cover images. Photos inside a shared album mostly have none. We are working on generated descriptions with an easy manual override.
Colour-only cues in third-party embeds. Partner offer content we render from a partner’s API sometimes arrives with its own formatting, and we cannot always fix theirs.
Uploaded PDFs. A booking confirmation you upload is the airline’s PDF. We parse the useful parts into accessible text in the booking task — that part is fine — but the original file is as accessible as whoever made it.
Partner websites. Once you tap a booking link you are on a partner’s site, which is theirs to make accessible. We would rather tell you that than let you find out.
Complex data tables. The budget’s per-person, per-day and per-category views are navigable but dense. Header association is correct; the reading experience on a screen reader is still heavier than it should be.
Three screens are currently broken and therefore unaudited. A traveller takes page, a template’s questions page, and two of the booking task forms return a server error rather than a page, for reasons that have nothing to do with accessibility. We mention them because “we have not audited these” and “these pass” are different statements and only one of them is true.
What we have not tested enough. Voice control, switch access, and screen magnification above 300%. We have tested with VoiceOver, NVDA and keyboard-only. The others are on the list and we are not going to claim conformance we have not verified.
5. How we test
- Every page in the product, on every build, blocking merges. The list of pages is read from the router rather than typed out, so a new screen is audited the day it exists — and a screen that is neither audited nor deliberately excused with a stated reason fails the build on its own. That is 129 surfaces across a signed-out visitor, a trip member and an administrator, at 390px, against WCAG 2.1 AA.
- Contrast is measured in a browser, not read off a palette. A colour that passes as a token can still fail after a faded card, a gradient over a photograph or an inherited colour from a dark panel. All three had happened; none was visible in the design system. We also re-measure our photo scrims with pure white behind them, because a gradient that holds over one photograph can fail over the next.
- Keyboard traversal of the interactions the product rests on — the vote control, the day chips, the booking board, sheets, the proposal review — driven by real key presses, checking that focus arrives, that it is visible, that it is trapped inside a sheet and that it comes back when the sheet closes.
- Reduced motion and reflow, with the operating-system preference genuinely switched on: nothing stranded at zero opacity, every day still reachable without the swipe, and no sideways scrolling at 320px.
- A lint rule that fails the build if a semantic colour is used outside its meaning — which is how we keep “colour never carries meaning alone” true over time rather than just at launch.
- Manual keyboard-only passes on every new screen.
- Screen reader testing with VoiceOver (iOS, macOS) and NVDA (Windows).
- Real-device testing on mid-range Android over 4G, not just a fast laptop.
We have not yet commissioned an independent audit. We intend to before public launch, and we will publish the result here — including the parts that go badly.
6. Telling us about a barrier
Tell us what you were trying to do, what got in the way, and what you were using — the browser, the device, the assistive technology. Any detail helps; a rough description is still worth sending.
What we will do:
- Reply within 5 working days, from a person.
- Tell you if there is a workaround, straight away.
- Tell you whether we can fix it and roughly when. If the answer is “not soon”, we will say that rather than leave you waiting.
- Add it to §4 above if it is a real gap, so the next person is not surprised by it.
If we do not sort it out. You can complain to the accessibility enforcement body in the EU country where you live — every Member State has one, and it can require us to fix the problem. You do not have to go through us first, and you do not need our permission.
Where we are established, that is the authority designated under the Danish Accessibility Act (lov om tilgængelighedskrav for produkter og tjenester), which implements the European Accessibility Act in Denmark. Sikkerhedsstyrelsen, the Danish Safety Technology Authority, is the market-surveillance authority under that Act, and it will direct a complaint about a service to the right desk if it is not the right one itself.
To confirm before publishing. Denmark splits enforcement between authorities by the kind of product or service. Counsel should confirm which one takes a complaint about an online consumer service, and this paragraph should then name exactly one body and its contact route rather than a starting point. Naming the wrong desk is a small failure; naming none is a bigger one, which is why this says what it does.
7. Formats
Need this page, or any of our policies, in another format — large print, plain text, a document your reader handles better? Ask at [email protected] and we will send it.
Every policy page on this site is plain long-form text at the same size as our guide body, in one column, with real headings, real tables and real lists — no PDFs, no images of text, and nothing that needs JavaScript to read.
Related: Terms of use · Privacy · Contact
Change log
| Date | What changed |
|---|---|
| 2026-07-29 | Gap list verified against the built product, in a browser, with a keyboard. §4: the claim that every item had a “Move to day” menu alternative was false and is now stated as the drag-only gap it is; the desktop proposal ghost list’s pointer-only highlight was added; three server-erroring screens are disclosed as unaudited. §3: contrast figures restated from measurement (body 8.1:1, quiet grey 4.98:1) and the “lighter grey for meta” carve-out removed — it never reached 4.5:1 and the greys it described have been replaced throughout. §3 also now states that links in running text are underlined. §5 rewritten to describe the automated pass that actually runs. |
| 2026-07-28 | First draft. Not yet in force. Gap list pending verification against the shipped build. §6 now names a real enforcement route in Denmark rather than a placeholder, with the remaining question for counsel stated beside it. |