Case Study: 

Trapped in the Search Bar

Blind Users (via Screen Reader) | Low Vision Users (via Font Sizing and Screen Magnification)

What is Assistive Technology (AT)?

AT is software or hardware that helps people with disabilities have full access to computing devices. Examples include:

• Screen readers

• Larger fonts

• Screen magnifiers

• Captions

• Eye tracking

• Voice control / access

What is a Screen Reader?

VoiceOver, Apple's built-in screen reader on iOS, converts on-screen content into speech, letting users navigate and interact with their device without seeing the screen. It's the primary assistive technology used by blind users to access digital content.

Common screen reader interactions include swiping to move between elements, double-tapping to activate, and using rotor controls to jump between headings, links, or landmarks. 

Mei's role

• Sole researcher: designed and ran the full heuristic evaluation myself using assistive technology directly

• Tested all 9 core user journeys across 3 assistive tech configurations (Screen Reader, Font Sizing, Screen Magnification) on an iOS device

• Worked directly with 2 stakeholders, an engineer and a designer, to scope the fix once I'd identified the root cause

• Owned the scorecard, issue theming, and recommendations tied to the OKR tracker bug hotlist

The Challenge

A structural blocker to the user experience

Several tasks were all fundamentally uncompletable for the same reason: users couldn't exit the search bar once they'd landed in it. I traced the root cause to navigation elements in the code being placed out of order rather than a broken search bar. 

Once I identified that reordering navigation elements would fix the blocker, I worked directly with the stakeholders to add the quick fix to their hotlist. That single fix moved 4 of 9 Unhealthy tasks to Healthy, taking the evaluation from a failing state to a passing grade with only minor issues left to address. 

Goal of this research

Identify accessibility issues across Search's top 9 tasks and provide prioritized recommendations to meet the accessibility OKR.

Spotlight on Accessibility Heuristic Evaluation 

This was an expert evaluation rather than a moderated study. I tested Search's 9 top tasks directly on a single iPhone 14 running iOS 18.3.23, using 3 assistive tech configurations: Screen Reader for blind users, and Font Sizing / Screen Magnification for low vision users. 

Each configuration navigated the full set of 9 tasks, measuring whether the task could be completed and where navigation, layout, or legibility broke down. I scored every task Healthy, At Risk, or Unhealthy based on the number and severity of issues found, and tagged the specific issue types blocking each one.

Reasoning behind the method

• Pros: fast, no recruiting needed, catches structural barriers before they reach real users

• Cons: doesn't capture how real assistive tech users work around friction, or how severe that friction actually feels to them

Every major issue had one root cause

4 of 9 tasks failed, and all 4 came from the same barrier. Once a Screen Reader or magnification user landed in the search bar, there was no clean way to exit it and reach the surrounding content. 

↪ Recommendation

Reorder navigation elements so users can scroll to the next header, or scroll linearly out of the search bar entirely.

The info card wasn't structured for scanning

The info card surfaced on the summary task packed sections like "Age" and "Parents" together without header markup, so Screen Reader users scrolling through missed information they'd already passed.
 

↪ Recommendation

Mark each section of the info card as a proper header so scrolling users can tell what they've passed and what's still ahead.

Text overlapped at larger sizes

On 2 of 9 tasks, resizing text caused content to run together instead of reflowing, making it hard to tell where one piece of information ended and the next began.

↪ Recommendation

Reduce how much information displays at once, or resize individual elements in step with the text scale instead of letting them overlap.

Icons didn't scale with the text around them

On 2 of 9 tasks, icons stayed a fixed size while surrounding text scaled up, making them harder to locate or tap at larger text sizes.

↪ Recommendation

Scale icon size in step with text size so both stay proportional and usable together.

What was assumed

Search was assumed to be broadly accessible already, since it goes through general accessibility testing as part of Google's standard product checks.

What we found

Search's top 9 tasks were mostly accessible on their own, but one navigation pattern (getting stuck in the search bar) was severe enough to single-handedly fail 4 of 9 tasks for blind and low vision users. It never would have surfaced without testing on real assistive technology.

What was decided

The team prioritized a fix for the search bar exit issue, reordering the navigation elements I'd flagged as the root cause.

Downstream wins

• 4 of 9 Unhealthy tasks moved to Healthy after the fix, taking the evaluation from a failing state to a passing grade with only minor issues remaining.

• Surfaced a blocker that standard accessibility checks had missed, reinforcing the case for expert assistive-tech testing on core Search flows.