What is the accessibility consideration for confidence indicators?
Meadowlark Public Library runs Stackwise, an AI reference assistant on its kiosks and website. It answers a patron's question and marks each answer with a confidence cue, so patrons know whether to trust it or ask a librarian. Selin Karaca manages Digital Services there. Junko Adeyemi has used the library for eleven years and reads every screen with a screen reader.
- Give every confidence cue a text label and a spoken-equivalent line, never color alone.Why: color carries zero meaning to a screen reader, no matter how visible it is on screen.
- Test the actual screen reader output on a real device, not just the visual design.Why: a badge can pass a contrast-ratio check and still say nothing new out loud.
- Track completion and follow-up rates split by assistive-tech usage.Why: the patrons losing this signal will not file a complaint about something they were never told existed.
- Name both people harmed by a design gap, not just the team that built it.Why: a design review that only asks "does this look clean" never asks who it looks clean to.
- Treat any removed accessible label as a regression, never a simplification.Why: "cleaner" for one group can quietly mean "silent" for another.
- Leave the sighted visual design's colors and icons alone.Why: the fix is adding a missing channel, not removing the ones that already work.
How to answer this, stage by stage
Nobody is grading whether you can name a WCAG rule number. They're grading whether you can find the patron your design quietly stopped talking to.
Let's learn
Stackwise is an AI assistant Meadowlark Public Library runs on its kiosks and website. A patron asks a question, Stackwise answers, and marks the answer with a confidence cue, so patrons know whether to trust it or ask a librarian.
Before Stackwise, a patron asked a librarian directly, always got a person's real judgment, and sometimes waited five or ten minutes during a busy afternoon. Now Stackwise answers about 900 questions a day instantly, freeing librarians for harder requests. About 27 of those sessions a day, roughly 3 in 100, come from patrons using a screen reader.
Here's the turn: a visual redesign meant to make the kiosk screen "cleaner" for sighted patrons replaced a spoken confidence label with a plain color dot, and quietly changed its screen-reader description to a generic "status indicator," with no actual value inside it. Sighted patrons could still read green, amber, or red at a glance. Patrons using a screen reader got nothing new at all, and had no way to know anything was even missing.
At its worst, a patron acts on a Stackwise answer that Stackwise itself was unsure about, with nothing telling her to double check, simply because the one channel that would have warned her never reaches a screen reader at all.
What I would leave alone: the sighted visual design itself, the actual colors and icon shapes chosen, doesn't need a rebuild. The gap was never what sighted patrons saw. It was what got left out for patrons who couldn't see it at all.
The lesson: an accessible design isn't one look everyone can see. It's the same warning, reaching every patron through whatever channel actually works for them.
Now here is the same thing as a story
The short version above is what you'd say defending this fix to Meadowlark's library board. Read this one for how quietly the gap actually opened.
The reference desk at Meadowlark Public Library used to have a line most Thursday afternoons, patrons waiting to ask a librarian something a catalog search couldn't answer.
Junko Adeyemi has used the library for eleven years, and reads every screen, at home and on the library's own kiosks, with a screen reader. She was one of the first patrons to try Stackwise on the day it launched, and for months it worked exactly as well for her as it did for anyone else, the confidence label read aloud right alongside the answer.
Selin Karaca manages Digital Services at Meadowlark and led a redesign meant to make Stackwise's kiosk screen feel calmer, less like a form, more like a person talking. Patrons loved the cleaner look. The badge shrank from a labeled box to a single color dot with an icon.
Nobody on the design team tested the new badge with a screen reader before shipping it, since the visual version had already passed a contrast-ratio accessibility check. That check answered a real question. It just wasn't the question that mattered here.
Six months later, Meadowlark's state library association ran its annual accessibility review and pulled ten random kiosk sessions to test with a screen reader. Nine were fine. The tenth was Stackwise's confidence badge, and it read only "status indicator, button," nothing else, on every single answer, sure or not.
Junko had used Stackwise regularly to check large-print book availability for her book club, and had quietly stopped noticing anything different, since nothing in what she heard ever changed between a confident answer and an unsure one. She had no way to know the cue she used to rely on had gone silent months earlier.
The auditor's finding wasn't really about Junko's book club question, mostly harmless as it was. It was that for six months, roughly twenty-seven screen-reader sessions a day had been getting Stackwise's least confident answers with zero more warning than its most confident ones.
With the spoken label restored, alongside the color dot and icon, Junko now hears "not fully sure, you may want to ask a librarian" exactly when a sighted patron sees amber. Run the same book-club question forward with a genuinely uncertain answer: she now hears the warning and asks a librarian, the same choice a sighted patron already had.
The old badge was accessible on paper and silent in practice. The new one says the same thing out loud that it shows in color.
I approved the redesign because it passed the accessibility check we had. It took an auditor with a screen reader to show me we had been checking the wrong thing.
GUARD, in one screenNot a lecture on being kind to every user. GUARD is what tells you which patron your design quietly stopped talking to.
The recap, one line per letter: groups is naming Selin's team and patrons using a screen reader as the two sides, unequal is the harm landing entirely on the second group, ability to contest is Junko having no way to even know something was missing, reduce is the redundant text-plus-speech design, and detect is watching follow-up rate split by assistive-tech flag.
And if you want to be sure it really works, try it somewhere elseSame five letters, a city assessor's office instead of a library. A different perceptual gap breaks the second story.
Fairline is a city assessor's office assistant that gives homeowners a confidence read on whether their property tax appeal is likely to succeed. Delphine Osei, the office's Program Manager, oversees it. Mapped onto GUARD: groups are the assessor's office, who set the design, and homeowners using the office's plain-language reading mode, many with a cognitive disability that makes dense or abstract numbers hard to use, who are the subject.
The unequal harm here isn't about sight at all, it's about abstraction. Fairline's team assumed a bare confidence percentage, "62% likely to succeed," was already the accessible version, simpler than a colored badge. For a homeowner using the plain-language mode, a raw percentage carries almost no more meaning than a color dot would, both are abstract symbols standing in for a real answer nobody actually said in words. The ability-to-contest gap runs the same way it did at Meadowlark: a homeowner who can't parse what 62 percent means has no way to know a plainer version should have existed at all.
Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "never let color alone carry the meaning, pair it with text and speech, and watch follow-up rate by assistive-tech use," and stop.
Cost: there's no budget for a full screen-reader testing pass on every release. Say so honestly, and start by testing the one component actually carrying safety-relevant meaning, the confidence badge, before shipping anything else.
The model gets better, for real: if Stackwise's accuracy genuinely improves and confidence is rarely low anymore, that's still not a reason to drop the redundant channels, a rare low-confidence answer is exactly the one moment the warning has to actually reach every patron.
Where people run it wrong.
They test the visual design and call it an accessibility pass, without ever turning on a screen reader themselves.
They wait for a complaint to learn a design gap exists, from a group least likely to be able to file one.
They treat "we already have a color-blind-safe palette" as the whole answer, when a screen reader never sees color at all.
How to use it live. When someone asks about the accessibility consideration for any indicator, ask yourself one question before answering: if I couldn't see this screen at all, what would I actually hear? If the honest answer is "nothing new," that's the gap.
Flashcards (tap any card to flip it)
Check yourself Score: 0 / 0
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
"Isn't full screen reader testing on every release too slow for a small team?" Response: at minimum, test the one component doing safety-relevant work, like a confidence badge, before shipping it; a full sweep isn't required to catch that.
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
- A live AI agent you actually shipped
- A launch decision you can defend under pressure
- An interview-ready portfolio, not more flashcards
More on UX for uncertainty and confidence display
- #1 When should you show a confidence score to a user, and when should you hide it?
- #2 Describe three ways to communicate uncertainty without displaying a number.
- #3 What is the risk of showing a percentage confidence that users cannot interpret?
- #4 Design the UI for a feature that is 70 percent confident in its answer.
- #5 Explain how hedging language in generated text affects user trust.
- #6 How would you design an interface that encourages verification without being annoying?