100+ unique participants
ranging in level of visual impairment across 14 studies in 3 countries
2 patent applications pending
for the text-to-speech and magnifier experiences
4.2+/5 final validation scores
on every feature, from directional navigation to guided audio to low-vision accommodations
Low need for technical support
Participants reported they could finish checkout without asking for help
Self-checkout assumes you can see the screen, reach the whole surface, read small text, and follow a visual flow with no audio. When any of that does not hold, the machine stops being self-service. You wait for an attendant, in public, to do something everyone around you is doing alone.
European accessibility requirements coming into force made this a compliance obligation as well as a right, and we had a next-generation platform in flight. That was the window to build accessibility in rather than retrofit it.
Rather than starting from a list of features to add, the program started from how visually impaired shoppers actually navigate, orient themselves, and build confidence at a machine.
Reach Mode
Completing a transaction through directional controls instead of touch. 37 participants across 4 tests, 5 in person and the rest remote across the US, UK, and Australia.
Text-to-Speech
A fully auditory path through checkout for shoppers who are blind or severely visually impaired. 7 rounds of research with 59 unique participants across a range of vision loss and technology familiarity.
Magnifier & Text Resize
Visual accommodations for shoppers with residual vision. 2 rounds of in-person testing with 18 participants, whose conditions included retinitis pigmentosa, glaucoma, central and peripheral vision loss, and reduced visual fields. Nine of ten participants in the low-vision study had used self-checkout while visually impaired before, so we were watching real behavior rather than first exposure.
"Users navigate by screen hierarchy"
They do not. Participants moved toward goals and destinations by the shortest logical path, not through the interface structure we had designed. They expected navigation to reach the nearest relevant element rather than follow our containers and groupings.
This changed the architecture of everything that followed. We moved to nearest-element navigation, contextual movement, intentional focus placement, and workflow-based paths. Every later accessibility experience was built on that decision.
"More instruction is more helpful"
Lengthy guidance became tiring and slowed people down. Participants wanted concise, actionable instruction with orientation and control.
This reframed the entire text-to-speech effort from an audio problem into an information architecture problem. What people needed to know was where they were, what was available, what they had entered, what came next, and how to recover. That is wayfinding, not narration.
"Users remember what they entered"
Across loyalty entry, search, and number input, participants repeatedly asked to verify rather than recall. Confidence depended on being able to check.
So confirmation and verification patterns became standard rather than optional.
"Magnification would be the preferred low-vision accommodation"
It was not. Text resize scored 4.6 out of 5 on likelihood to use against the magnifier’s 4.3, because it required no repositioning and no viewport tracking, and it fit into the flow people were already in.
This expanded the whole program from supporting blind shoppers to supporting the full spectrum of visual ability.
Reach mode
On-screen navigation replaced touch with directional controls, which meant focus placement became the entire interface. Where focus lands, how it moves, and how clearly it reads determined whether someone knew where they were. Research showed users navigated toward destinations rather than through structure, so focus follows the nearest relevant element and the workflow rather than the container hierarchy underneath.
[One or two sentences on the focus indicator itself: contrast, weight, how it reads at a distance, what you tried before landing on it.]
Magnifier
Magnifier let shoppers enlarge part of the screen and move that viewport around. Testing surfaced two interface problems. A fixed magnification level did not fit the range of visual needs in the room, and locating the control handle to reposition the magnified region was harder than manipulating the region directly. Participants also preferred keeping the magnifier visible rather than dismissing it between tasks, which changed how it had to coexist with the rest of the screen.
Text Resize
Text resize enlarged type throughout checkout without asking anyone to reposition anything. It rated highest of any feature at 4.6 out of 5, and the reason was interaction cost: no viewport to track, no repositioning, nothing to manage while shopping.
The finding underneath all three is that readability is not a font size problem. Participants still struggled when contrast, hierarchy, font weight, border weight, target size, and visual prominence worked against them, no matter how large the text was. Enlarging type exposed layout decisions rather than fixing them.
[Two or three sentences here on specific interface changes you made as a result: what you adjusted in contrast, hierarchy, or target sizing, and what it looked like before.]
Discovering Accessibiliy Features
Accessibility controls are not naturally discoverable. Participants could not always find the tools built for them. Discoverability became a design requirement rather than a settings-menu afterthought.
Competitive benchmarking of assistive kiosks, including units at the Atlanta airport, found no standard for navigation style, wildly variable scripting depth, and a common baseline of volume and speed controls with at least three levels.
We built a section-based layout: pages divided into named sections users move between with directional controls, with items and options inside them. Each section type carries its own instruction pattern, which is what makes the system scalable across configurations rather than scripted screen by screen.
Details that came directly out of testing:
• A negative tone when a key press does nothing, because participants pressed keys while learning the navigation and became confused by silence
• Instruction repeat after five seconds of inactivity
• Three speed settings
• Position announcements in the form of item three of six, because orientation was what people asked for most
Prototyping what didn't exist
There was no way to usability test an audio experience with a static prototype, so I built a working one. It was time consuming and there was no established pattern to copy in our tooling.
It was the right call. Describing an audio flow to a participant produces polite agreement. Testing the real thing produced the findings that shaped the requirements.
Participants independently completed navigation, search, loyalty entry, assistance, checkout, and payment. In final validation one participant said the system made them feel independent as it went on. Another called it the best thing they had come across for visually impaired people.
I translated findings into implementable requirements with engineering across two product lines, working within hardware constraints, and ran formal handoff sessions and documentation for implementation teams. Two patent applications came out of this work, covering text-to-speech and the magnifier.
What I would do differently
Scope a first slice small enough to fit a release rather than presenting a full program as one body of work, tie it explicitly to the compliance deadline so it competes as a requirement rather than an enhancement, and bring engineering feasibility in earlier so effort is not a surprise at the decision point.
What stayed with me
Accessibility enters my process at requirements now, not at review. The larger lesson is that this program changed product direction before implementation rather than after, which is the cheapest possible moment to be wrong.