What works, and what doesn’t yet.

Each of these is a decision in the code rather than an intention:

• The catalogue works with JavaScript off. Searching, filtering, sorting and paging on the explore page are ordinary links and forms rendered on the server. Nothing is hidden behind a script that has to run first.
• Status is never colour alone. Every state marker carries a distinct shape as well as its word and its colour, so it survives greyscale, colour blindness and a bad screen in a bright room.
• Focus is always visible. There is one focus treatment across the whole site and we do not remove it. On the search fields it moves to the frame of the field so the whole control lights up rather than the text cursor.
• Skip to content is the first thing you tab to, on every page.
• Reduced motion is honoured properly. With prefers-reduced-motion set, animations and transitions collapse, smooth scrolling turns off, and the scroll film on The World does not download its video clips at all — the stills stay up and cross-dissolve.
• Menus and panels behave. The mobile menu traps focus while it is open, returns it to the button that opened it, and closes on Escape.
• Results that change without a page load say so. The gift finder, the waitlist form and the location strip announce their outcome to a screen reader instead of changing silently.
• Photographs are described. Every cover image carries alternative text written for that specific photograph, not the filename and not the listing title repeated.

Two known ones, both visual surfaces, and both with a working path around them:

• The map view is not keyboard-navigable pin to pin. Everything a pin knows — the producer, the price, the times left, the link — is also in the list beside it, and that list is the accessible path. But tabbing the map itself will not take you from pin to pin, and it should.
• The scroll film has no described alternative. The World is a scroll-scrubbed visual piece with no narration or transcript. It is skippable and it gates nothing — every experience it shows is reachable from the explore page — but someone who cannot see it is missing the piece rather than an equivalent of it.

Neither is on this page to excuse it. They are here because a statement that lists only successes tells you nothing about the site.

In-house, by the people who built it — which is the weakest form of accessibility testing there is. The decisions listed above are held to in review rather than caught afterwards, and every change is looked at on a desktop and a phone before it ships.

What has not happened: an independent audit, and testing by screen-reader users who do not work on this site. Both are worth more than everything in the paragraph above. Until they are done, read this page as a description of specific decisions in the code, not as a conformance claim.

Write to hello@drinkcard.app with the page you were on, what you were trying to do, and what you use to browse. Any of the three is enough to start; all three make it fast.

An accessibility barrier is a bug, and it goes in front of whatever feature we were building. If you need something on this site and cannot get to it, say so and we will get it to you directly while we fix the page.