A discovery surface is one control and one panel of content. Press the control, get a different thing. There is not much to it, which is exactly why the interactive versions of this idea so often end up being operable only by pointing at them.
These are the build notes: five decisions, what each one costs, and a section at the end listing what is still not good enough. That last section is longer than we would like.
What this is, and who it is for
For anyone who has landed on an interactive toy and found there was no way in without a mouse. And for anyone building something similar, because these decisions are small and they are much cheaper to make at the start than to retrofit.
Two disclosures before anything else, both of which limit what this post is allowed to claim.
This is an accessibility specification, not a completed usability-test report. The register and discovery pages define the required behavior without claiming a deployed populated surface.
No accessibility conformance claim is made here. What follows is a specification and a reusable verification checklist, not a report of testing that this article does not document.
Why this blocked launch rather than following it
The usual sequence is to ship the thing, watch people enjoy it, then work on access when someone complains. On a surface this small that sequence is hard to defend, because the work is genuinely minor and the alternative is a toy that turns some people away at the door.
There is also a practical reason specific to this site. The whole proposition here is that a person checked something before it was published. A discovery tool that had never been checked for whether it could be operated at all would sit very badly next to that.
So these were written down as launch conditions rather than as a backlog. Not because access is a virtue we would like credit for. It is the floor, and a control that only responds to a pointer is a control that does not work.
Decision: every action reachable by keyboard
There are three actions on the surface. Draw another entry, follow the entry out to the operator's own site, and read the rules page. All three are real controls that can be reached in the normal tab order and operated with the keyboard.
What that ruled out was the pattern where the whole panel is the button. Making a large decorated area clickable feels generous with a pointer and is worth nothing without one, because a clickable region is not a control and has no name to announce and no place in the tab order.
So the next-entry action is an ordinary button with an accessible name that says what it does, and the outbound action is an ordinary link. Both are boring. Boring is the point: the browser already knows how to expose a button and a link to whatever the reader is using, and every custom widget is a promise to reimplement behaviour that already existed.
Decision: nothing auto-advances
The surface does not rotate on a timer, does not refresh itself, and does not move to the next entry while you are reading.
Auto-advance is tempting on a tool like this because it makes a demo look alive. It is also the single most hostile thing this surface could do. Anyone reading slowly, navigating with a keyboard, using magnification, or simply thinking about whether to click loses the thing they were reading to a clock they did not set. There is no way to make that acceptable through configuration, so it does not exist.
The related decision is that nothing happens on the surface without an action from the reader. No content changes on hover, nothing loads because you scrolled, and the panel does not update while your attention is elsewhere.
Decision: focus never gets trapped
The surface is a region of a page rather than a modal layer over one. Nothing about it captures the keyboard, and it is possible to tab out of the surface and into the rest of the page and out of the page entirely, in both directions.
This one is worth stating explicitly because the natural implementation of "a card you keep pressing next on" drifts towards a dialog, and dialogs are where focus traps come from. Avoiding it meant not building a dialog. There is no overlay, no lightbox, no takeover state.
The cost is real: a dialog would let the surface fill the viewport and feel more like a distinct place. The panel is a section of an ordinary page instead, which is duller and does not lock anybody in.
Decision: the outbound link is a link, not a script
The route out to the operator's site is a plain anchor with the operator's own address in it, carrying only the ordinary safety attributes and no interstitial, no countdown and no redirect that hides where it goes.
The accessibility case for this is that a real link comes with everything the browser already provides. It is reachable in the tab order, it is announced as a link rather than as unlabelled text, its destination can be read before it is followed, it can be opened in a new tab, copied, or opened however the reader prefers to open links. A click handler on a non-link element gives up all of that and gives back nothing.
The operator's case is separate and points the same way. A plain link means the visit arrives at their site as an ordinary referral that their own analytics can see, rather than as traffic from a wrapper. Why we don't frame anyone's site sets out the rest of that argument.
Two decisions that follow from the same principle: the address shown to the reader is the address the link goes to, and there is no tracking hop in between. If a link ever needed a redirect to work, we would rather not have the link.
Decision: motion is optional
Any transition between one entry and the next respects the reader's system motion preference, and where that preference asks for reduced motion the change happens without animation.
This was a cheap decision because the surface has very little motion to begin with. The general principle behind it was to design the thing so that the version with no motion is the complete version, and animation is decoration that can be removed without losing information. Motion that carries meaning is motion somebody will miss.
How to verify an implementation
Treat the decisions above as requirements and record evidence for each one. A useful review includes:
- Traverse the page in both directions with a keyboard and record the focus order, control names, and whether focus can leave the surface.
- Draw several entries with a screen reader and record whether the changed content is announced once, with enough context and without taking control away from the reader.
- Check text, controls, focus indicators, and every state with a contrast-measurement tool; record the values and the colours measured.
- Enable reduced motion and verify that no information depends on animation.
- Disable JavaScript and document the remaining route to the same destinations, or state plainly that the interactive surface requires it.
- Repeat with the shortest and longest permitted descriptions so wrapping and reading order are both exercised.
- Include review by users of assistive technology before making a usability claim; automated checks and keyboard inspection do not substitute for that evidence.
A conformance report needs a date, implementation version, tester, method, assistive technologies and browsers used, findings, and unresolved failures. Without that record, the accurate description is that the implementation follows this specification, not that it has passed an accessibility audit.
If you are building something similar
A transferable checklist, all of which is cheaper before the build than after.
- Make every action a real button or a real link. If you are adding a click handler to a container, stop.
- Give each control a name that says what it does, and check the name is present rather than implied by an icon.
- Do not advance anything on a timer. If a demo needs auto-advance, make the demo a video.
- Do not build a dialog unless you need a dialog. Most "cards" do not.
- Keep the destination of every outbound link visible and honest, with no interstitial and no redirect hop.
- Treat the no-motion version as the real version and animation as removable decoration.
- Write down what you have not tested, publish that list, and resist the temptation to describe design decisions as if they were test results.
In Plain English
What it means. The specification requires full keyboard operation, no automatic movement, no focus trap, a plain outbound link, and optional animation. The checklist above shows how to test an implementation; this article does not claim a completed accessibility audit.
Who it helps. Anyone who does not use a pointing device, and anyone building a small interactive thing who would rather make these decisions once than retrofit them.
When to use it. Before you build the interactive part, not after somebody tells you it does not work.
What to do next. Read what the surface actually does for the selection side of the same build, or the rotation rules for the specification. If you are working on your own site, shopfront basics covers the same principle applied to an ordinary small business page.
Try the stumble
The stumble is the complete selection protocol, not a claim of a live populated service. The requirements in this post are suitable for keyboard review of any implementation, and seeded examples cannot count as passing evidence.