Greenbox has sixty-eight subscribers. The signup flow works – mostly. Two sprints into the new delivery, a subscriber called Helen sends a polite email that lands like a small earthquake under the kitchen table where Maya does her reading.
Helen’s email is three paragraphs long. The first paragraph thanks Maya for the boxes and mentions that her daughter-in-law recommended Greenbox. The second paragraph asks a practical question about substitutions. The third paragraph is the one Maya reads twice.
“I should mention,” Helen writes, “that I’m registered blind. I use a screen reader called JAWS to use my computer. I managed to sign up to Greenbox, but it took me about forty minutes. The checkout form had some fields my screen reader couldn’t identify, and I had to guess what some of the buttons did. I got there in the end, but I wanted to let you know in case you can fix it for others. I’m not complaining – I’m glad I found you. Just letting you know.”
Maya reads it a third time. Then she forwards it to Tom, Priya, and Lee with one line: “We need to talk about this.”
The Monday morning conversation
By Monday, Tom has opened the signup form on his own laptop, turned on VoiceOver, and tried to complete it with his eyes closed.
He gets to the delivery frequency dropdown and stops. VoiceOver reads it as “button, pop-up button.” It doesn’t say what the button is for. It doesn’t read the current selection. If Tom hadn’t known he was on the delivery frequency field, he would have no idea what was happening.
He tries the substitution preferences checklist next. VoiceOver reads “checkbox, unchecked” three times in a row and then stops. There are twelve checkboxes on that page. Helen would have had to tab through all twelve without knowing what any of them were for.
Tom puts his headphones down.
“We failed her,” he says to Priya. “She got through it because she’s determined. Not because we did our job.”
Priya has been reading the Web Content Accessibility Guidelines on her laptop. “WCAG 2.2,” she says. “There are three conformance levels – A, AA, AAA. AA is the standard most regulators use. It covers perceivable, operable, understandable, and robust. Four principles, thirteen guidelines, seventy-eight success criteria.”
“Seventy-eight.”
“Some of them are easy. Colour contrast, alt text on images, form labels. Some of them are harder – like making sure that every interactive element works with a keyboard, or that the order the screen reader reads things in matches the visual order. The hard ones are the ones we’re failing.”
Maya is listening from the other end of the kitchen. She asks the question she always asks when she’s trying to decide how seriously to take something. “What does it cost to fix?”
Compliance or product?
This is the moment the conversation could go two different ways.
One version: Greenbox treats accessibility as a compliance checklist. Tom and Priya spend a week grinding through the WCAG criteria, ticking boxes, running automated scans with axe and Lighthouse, fixing the failures the scans flag. At the end of the week, the automated scans are green. They declare victory. They write a blog post about being WCAG AA compliant. Nobody tests with an actual screen reader again for the rest of the year.
The other version: Greenbox treats accessibility as a product quality decision. The signup flow has to work for everyone, because every person who can’t complete signup is a subscriber Greenbox loses – and a person whose experience of Greenbox is worse than their experience of the shops. The team doesn’t just run automated scans. They test the flow with a screen reader, with keyboard-only navigation, with high-contrast mode, and with somebody whose vision is actually impaired.
Maya has been in enough tech companies to know which version happens by default. She’s seen “WCAG AA compliant” stickers on websites that are unusable with a screen reader. The compliance checklist is seductive because it’s finite. You do the list, you’re done. The product quality framing is harder because there’s no finish line – just a commitment to keep checking.
She picks the harder framing.
“We’re not going to be WCAG AA compliant,” Maya says. “We’re going to be a subscription box that actually works for people who can’t see the box on the website. Those are different goals, and I want to be sure we know which one we’re solving.”
Tom nods slowly. He can feel the difference in his stomach. Compliance is a sprint – a week of furious fixing, then done. Product quality is an orientation – something you carry into every future sprint.
What “works for Helen” looks like
Lee takes out a marker and goes to the whiteboard. “Okay. If we’re going to treat this as a product decision, we need to be specific about what we’re deciding. What does ‘works for Helen’ mean?”
The team spends an hour working through it. The outcome isn’t a WCAG checklist. It’s a set of user story map updates – concrete journey steps that have to work regardless of how the subscriber is accessing the site.
- A subscriber who cannot see the screen can sign up, choose a box, set preferences, and complete checkout using only a screen reader, without asking for help.
- A subscriber who cannot use a mouse can do the same using only a keyboard.
- A subscriber with low vision can read every piece of content on the site with the browser’s text size set to 200%.
- A subscriber who is colour-blind can distinguish every button, status indicator, and error message without relying on colour alone.
- A subscriber with cognitive difficulties can understand the delivery schedule, the substitution rules, and the cancellation process on first reading.
Each of these feeds back into the user story map as a row of slices that cut across every feature. They’re not a separate “accessibility backlog” to be done later. They’re the same stories the team has already mapped – with a new dimension added.
“This is how we avoid the compliance trap,” Lee says. “Accessibility isn’t a feature. It’s a quality attribute of every feature. If we build a new delivery scheduler, it has to work for Helen. If we build a new substitution flow, it has to work for Helen. We don’t ship a feature unless it works for Helen.”
Tom writes “Helen” on a sticky note and puts it next to the Definition of Done on the team’s process wall. Next to “passes tests,” “code reviewed,” and “deployed to staging,” they add “tested with keyboard and screen reader.”
It doesn’t fix everything. The existing signup flow still has the problems Helen described. Tom and Priya spend the rest of the week going through it systematically – not by running automated scans, but by closing their eyes and trying to use it. They find things the scans missed. The checkout button is a styled <div> instead of a <button>, so screen readers don’t announce it as clickable. The error messages appear as text near the broken field, but the screen reader doesn’t read them when the field is focused. The delivery day picker is a custom component that traps keyboard focus.
They fix each one. Priya writes a short internal doc – Greenbox Accessibility Standards – that lists the decisions they’ve made and why. It has four sections: semantic HTML first, keyboard navigation always, visible focus indicators, and test with actual assistive technology. It’s shorter than the WCAG spec. It’s more useful, because it’s specific to the decisions they make every day.
The email back to Helen
On Friday, Maya sends Helen a reply.
“Helen – thank you for writing to us. Your email changed how we’re building Greenbox. This week, Tom and Priya went through the entire signup flow with a screen reader and fixed the problems you described. We’ve also added keyboard and screen reader testing to our Definition of Done, which means every new feature we ship has to work before it goes live. I’d love to send you a free box as an apology for the forty minutes, and to thank you for teaching us something we should have known. If you’re willing, we’d also love to ask you a few questions about the rest of the site – not to interrogate you, but because you’ll notice things we won’t.”
Helen writes back within the hour. She says yes to the box, and yes to the questions. She adds: “Most of the time when I tell a company their site is broken for me, they apologise and nothing changes. Thank you for being different.”
Maya pins the email to the wall next to the sticky note with Helen’s name on it.
Why this matters beyond Helen
Here’s the thing about building the product this way: it doesn’t just benefit Helen. The changes Tom and Priya made also benefit:
- The subscriber who has broken their arm and is navigating the site one-handed with a keyboard.
- The subscriber on a train with a bad connection and a small phone screen.
- The subscriber whose first language isn’t English, who uses a screen reader to slow down the text.
- The subscriber who is sixty-eight and wears reading glasses and needs the text bigger than the default.
- The subscriber whose ADHD makes it hard to parse a cluttered interface and needs clear headings and clean structure.
This is a well-known result in accessibility research: building for the edges improves the middle. Captions were designed for deaf users and are now used by everyone watching TV in a noisy pub. Kerb cuts were designed for wheelchair users and now serve parents with prams, cyclists, and people wheeling suitcases. The term for this is the curb-cut effect, and it’s real and measurable.
Maya didn’t know the term when she made the decision. She just knew that Helen was a subscriber, Helen had been failed, and the right response wasn’t a compliance sticker.
The lesson Maya writes down
In her notebook – the one she uses to capture the decisions she wants to remember – Maya writes:
“Accessibility is a product quality decision. The compliance frame makes it finite and lets you declare victory. The product frame makes it ongoing and lets you keep improving. Choose the product frame. The cost is real but small. The benefit is that every subscriber can actually use what you built. That is the whole point of building something.”
She closes the notebook. The email from Helen is still pinned to the wall.
Next to it, she adds a second sticky note. On it, in her careful handwriting: Helen is a subscriber. Every subscriber matters. Every subscriber counts.
It isn’t a WCAG criterion. It’s better.