← Blog

Human-in-the-Loop Accessibility: Why Generation and Verification Are Different Jobs

Apple ships Text Recognition on by default. Image Descriptions requires a manual toggle, a model download, and a sensitivity warning. That asymmetry isn't an accident — it's a precise signal about where automation's confidence runs out. This is about what happens after the generation, and why that step still belongs to a human.

Panopt ·
A woman with brown hair views financial data and charts displayed on a tablet and laptop at a desk, with multiple monitors visible in the background of a bright office workspace.

When Apple introduced VoiceOver Recognition in iOS 14, they shipped two features in the same settings menu that quietly encode a lesson about the limits of automation. Both live under Settings → Accessibility → VoiceOver → VoiceOver Recognition. Both use machine learning. Both serve screen reader users navigating a world that doesn’t always describe itself. But only one of them ships on by default.

Text Recognition — which uses OCR to surface text embedded inside images — is enabled out of the gate. Image Descriptions — which generates natural language descriptions of what’s in a photo or graphic — requires a manual toggle, a model download, and comes with a sensitive content warning you have to configure before it does anything useful.

That asymmetry isn’t an accident. It’s Apple’s own implicit taxonomy of what automation can and can’t promise.

The Two-Speed Problem

Text recognition is a solved problem. Given an image containing text, a well-trained OCR model will reliably output that text. The output is deterministic enough that Apple ships it on and leaves it alone. You don’t have to tell it how to handle edge cases, because the edge cases in OCR are narrow and well-characterized. Either the text is readable, or it isn’t. Either the characters are legible, or the model hedges with low confidence. The job is bounded.

Image Descriptions is categorically different. Generating a useful alt text isn’t just pattern matching — it requires interpretation. What’s the subject of the image? What context matters? Is this a dressage horse or a horse wearing a dressage bridle — and does the embedded text in the corner saying “Kimberly K. Brauner, Photography” count as part of the description? Those aren’t questions with one correct answer. They’re editorial decisions. The Perkins School for the Blind documented exactly this kind of regression when Apple updated iOS: the same photo that described a baby as “one face, smiling baby” before an update simply stopped producing that detail afterward. Same photo. Different model. No announcement.

The VoiceOver documentation reflects this uncertainty in how it talks about descriptions. For unlabeled icons or images, VoiceOver’s default “Speak” feedback style prefaces any description with “possibly” — as in, “Possibly Play button.” The system is announcing its own epistemic state before telling you what it sees. That’s not a quirk of the phrasing. It’s a design decision: build the hedge into the output because the confidence isn’t there to omit it.

Screen Recognition — the third leg of the VoiceOver Recognition suite — offers a useful contrast point. Documented in an Apple research paper presented at CHI 2021, Screen Recognition was built to infer UI accessibility metadata from pixels when developers hadn’t provided it. It detects buttons, text fields, sliders, and other interactive elements using an on-device object detection model trained on over 77,000 annotated iPhone screens. It achieves 71% mean average precision across UI types. For structural navigation — “is this a button? is this a text field?” — that’s good enough to ship. The model’s job is bounded. But the same researchers who built it noted explicitly that even Screen Recognition doesn’t replace developer judgment: the most accessible experiences, they wrote, are still created by people who understand how the content should be conveyed. Automatic metadata generation is a floor, not a ceiling.

The Reliability Gap No One Talks About

The AppleVis community forum captures what reliability problems actually look like for users who depend on Image Descriptions daily. Reports of VoiceOver stopping descriptions mid-session without explanation. Users discovering that the feature’s storage allocation shows 0 KB instead of the 30+ MB the model should occupy — a sign the model has been silently removed or corrupted. Fix attempts ranging from toggling the feature off and on to full device restarts while the feature is disabled, then re-enabling after boot. One user speculated the descriptions might rely on remote Apple servers; another noted from Apple’s own documentation that the model runs on-device — but if the on-device model has a problem, you’re out of luck and the system doesn’t tell you.

There’s also a quieter issue of changing defaults. An iOS update at some point switched the “Navigate Images” setting from its original default, silently opting users out of image navigation. Perkins documented users suddenly unable to navigate photos by swiping — only to discover the setting had changed under them. When a feature that assistive technology users depend on can silently change behavior across an update, the implicit trust that “it’s working, I can rely on this” breaks down.

This is the shape of the reliability gap. Not catastrophic failure — more like slow erosion. A description that was rich last month is vague this month. A feature that was active yesterday silently reset overnight. The automation is running, but you can’t be sure what you’re getting.

Generation vs. Verification: Two Genuinely Different Jobs

Here’s the distinction that the VoiceOver example makes vivid: generation and verification require different things from a system.

Generation is about removing friction from a blank-page problem. Writing alt text from scratch for every image on a website, a product page, or a social post is cognitively expensive and easy to skip. Automation handles that well. It gets something down fast, consistently, without requiring the writer to stop what they’re doing and compose a description. The quality ceiling is fuzzy, but the quality floor is significantly higher than zero — which is what you get when people skip it entirely.

Verification is about whether what was generated is actually right. Did the description capture the right subject? Did it catch the text embedded in the image? Is the tone appropriate for the context — a clinical description of a medical diagram lands differently than a marketing photo of a family at the beach? Is there anything factually wrong, misleading, or missing? Those are judgment calls that require a human who knows the content, the context, and the audience.

The mistake is treating these as a single continuous process — as if better automation eventually eliminates the verification step. It doesn’t. It just compresses the generation step enough that verification becomes the bottleneck worth addressing. Apple’s own reluctance to enable Image Descriptions by default, despite years of development, is evidence of this. The generation is good enough to be useful. It’s not good enough to be trusted without review.

What This Means for Panopt

Panopt was built around exactly this distinction, even if we haven’t always named it that explicitly.

The tool accelerates generation. Right-click an image, get a Claude-powered alt text back in seconds — one that’s grounded in the actual content of the image, informed by WCAG and A11Y guidelines, and available in the user’s language without additional configuration. The blank-page problem goes away. The friction of having to write every description from scratch goes away.

What Panopt doesn’t do — and what no generation tool should do, at least not without a human in the chain — is make the verification call for you. The generated text goes into an editable field. You read it. You decide if it’s right. You adjust the tone if needed, catch anything the model missed, and confirm whether embedded text in the image was detected and included. That step isn’t overhead we’re trying to automate away. It’s the job.

The label “Human-in-the-Loop” often sounds like a limitation — like the thing you add when your system isn’t good enough to run autonomously. But in the context of accessibility, it’s the design. A description that’s reviewed and confirmed is meaningfully different from one that isn’t, for the same reason that a published article with an editor is different from a published article without one. The underlying content might be similar. The confidence you can place in it isn’t.

Apple signaled this with two toggles in the same settings panel. One for a solved problem, one for an unsolved one. The solved problem ships on. The unsolved one asks for a human to configure it, opt into it, and — implicitly — stay in the loop on what it produces.

That’s a reasonable place to be. It’s where Panopt is too.

Panopt is an AI-powered alt text generator for Chrome. Generate, review, and export accessible descriptions — without leaving the page. Try it at usepanopt.com.

Sources

  1. Apple Support. Use VoiceOver Recognition on your iPhone or iPad. https://support.apple.com/en-us/111799

  2. AppleVis. A Deep Dive into VoiceOver Settings for iOS and iPadOS. https://www.applevis.com/guides/deep-dive-voiceover-settings-ios-ipados

  3. Gadget Hacks. 19 New Accessibility Features in iOS 14 That Every iPhone User Can Benefit From. https://ios.gadgethacks.com/how-to/19-new-accessibility-features-ios-14-every-iphone-user-can-benefit-from-0323436/

  4. Perkins School for the Blind. Automatic Image Descriptions on iOS. https://www.perkins.org/resource/automatic-image-descriptions-ios/

  5. AppleVis Forum. VoiceOver no longer reads image descriptions. https://www.applevis.com/forum/ios-ipados/voiceover-no-longer-reads-image-descriptions

  6. Zhang, X., et al. Screen Recognition: Creating Accessibility Metadata for Mobile Applications from Pixels. arXiv:2101.04893. https://arxiv.org/pdf/2101.04893