Keyboard-operable throughout
Every menu, dialog and form works without a mouse. A drawer and a search dialog trap focus while open. They hand it back to exactly where it started.
Beemy · beemy.co
Printed from beemy.co/accessibility/
Accessibility
Every page targets WCAG 2.2 AA. Here's what we test for, what holds today, and what's still short. We name it plainly, the same way /mistakes names what goes wrong.
On this page
The standard, and the test
We test the site as it actually ships. We cover every route, light and dark, at 1280px and 390px. Colour contrast and heading structure are checked automatically on every build. A keyboard-only pass by hand runs before each release. A design mockup can look accessible. Only the rendered page can prove it.
What holds today
Every menu, dialog and form works without a mouse. A drawer and a search dialog trap focus while open. They hand it back to exactly where it started.
Nothing hides where your keyboard cursor is.
Reveal animations, the interactive tour and the autonomy-ladder demo all turn off if your OS asks for less motion.
Navigation, forms and every page's content render and function with no script at all.
The dark theme is a separate, retuned palette. It clears the same contrast floor as the light one.
Some pages move text and buttons while they load, so you tap the wrong thing by mistake. Ours stay still. We test this on every page before each release, in a real browser on a slow connection. This is not a WCAG rule. We hold ourselves to it anyway. A moving page is a bad start for a product built to save you time.
A very long line of text is hard to read. Your eye has to jump back a long way to find the next line. It loses its place. Body text on this site stops at about 80 characters a line, at every font size we use. We measure it in a real browser, on every page. WCAG puts line length in AAA, not in AA. We hold ourselves to it anyway. This site asks you to read a lot of words.
What's still short
No badge-collecting here. This is what we know is missing, and what happens next.
We test the site ourselves, in headless Chromium and by hand. There's no independent VPAT or conformance report yet. That's next once the beta stabilises.
Two scripts run on every build. One does the contrast arithmetic over the colour tokens and the CSS rules that use them. The other reads the built HTML for heading order, labels, alt text and duplicate ids. They catch the shapes we've taught them. One shape is a known blind spot. It is a rule that sets a text colour while the background comes from an ancestor. A hand-kept list holds those pairings. The whole site also gets an axe-core sweep before a release, not on every commit. The sweep covers every route in both themes at both widths.
We check structure (headings, labels, roles) on every build. We haven't walked every form and dialog with a screen reader start to finish.
The header and search dialog have had a full pass for the 24x24px minimum. The rest of the site hasn't, yet.
The fixes behind this page are minimum-viable corrections to specific problems. The higher AAA bar is a later project.
Found something we missed
If something on this site doesn't work with your keyboard, your screen reader, or your eyes,contact us. Describe what happened and what you were using. We reply to every message. Tell us what you found and we'll add it to the list above.
Read next
Beemy is in private beta. We send invites in rolling batches. We cannot promise a date. When your invite arrives, connect Gmail. Beemy sorts your inbox in that first session.
You're in the hive. You get no email now. We write to you once, when your invite is ready.
While you waitLinks do not work on paper. Open the address above to follow them.
To join the waitlist, go to beemy.co/waitlist.