Build1 publisher3 min readPublished
Screen-reader testing found a second list of OneFindMe bugs after axe-core reported zero
OneFindMe's developer took axe-core to zero findings, then a keyboard and VoiceOver pass turned up six kinds of failure the scanner never flagged. One site and one blind iPhone user make a strong case for a screen reader in the release test plan.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The first thing the developer's blind brother tried with VoiceOver on his iPhone, voice search, did nothing at all.
- Before the manual pass, axe-core flagged two unnamed sort and filter selects, 130 to 250 low-contrast 7px labels and a missing main landmark, all since fixed.
- Favourites, price-alert and similar-products pop-ups were plain divs that opened on screen while focus stayed behind them and VoiceOver said nothing.
- Search results filled the grid with no announcement, so a blind user could not tell whether the search had finished.
- A trending rail placed above the results in the DOM meant the screen reader read unrelated bestsellers before the search results.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Release checklists need a keyboard-and-screen-reader run through each user flow, because a passing scan left focus handling and announcements untested on this site.
- constraint A zero from axe-core holds only for the pages, viewports and colour schemes it ran against; a 1.2:1 dark-mode button went unreported by a tool that had caught label contrast elsewhere.
- cost Cached per product and language at about 0.6 cents each, the photo-description bill grows with catalogue size and languages served, and repeat views cost nothing.
- exposure An endpoint that forwards image URLs to a paid model is a free vision API on the operator's key until the host is allowlisted, and the site's own image proxy first broke that allowlist.
The developer wrote that none of the second list was visible to axe [6]. The account covers one site and one VoiceOver user on an iPhone [1]. Most of what the manual pass found concerns what happens after an action. The fixes are mostly about timing and names.
Take the silent results. According to the developer, a screen reader speaks a live region only when its text changes, so two identical searches in a row produced no announcement [16]. The fix empties the region and refills it on the next tick [16]:
```js function announce(msg) { el.textContent = ""; setTimeout(() => { el.textContent = msg; }, 60); } ```
After a search, focus also moves to the results heading with `focus({ preventScroll: true })` [17]. The reading position jumps to the results while a sighted visitor sees nothing move [17]. The move is skipped while focus is in the filter bar, because arrowing through a `<select>` fires `change` on every step [17]. Without that guard, a keyboard user changing the sort order would be pulled away on the first arrow press [17].
Naming came next. Read in DOM order, a product card came out as "Top pick, minus sixty-six percent, 15.04, 30.70, Baby cup..." [14]. One `aria-label` on the card's link now carries the title, the price, the original price when discounted, the rating, the order count and free shipping [14]. Save and Share buttons now name the product they belong to [15]. Emoji had been read aloud as written, so a deals entry was announced as "Fire. Daily deals." [11] The menu, Home and History buttons in the bottom bar were focusable and wired to nothing [10]. "For a sighted user that's a small annoyance. For a screen reader user it's a trap," the developer wrote [10].
Photo description is the part the developer is proudest of [25]. AliExpress titles are keyword piles. So every result has a visually hidden button that sends the product photo to a vision model and returns a description in the page's language [18]. The prompt forbids inventing sizes, brands or specifications [23]. The developer compared Haiku, Sonnet and Opus on the same photos in Hebrew [19]. Haiku invented parts that were not there. Sonnet matched Opus on accuracy and was about two seconds faster [19]. "For someone who can't check the photo, a confident wrong description is worse than none," the developer wrote [20].
I think the selection rule is right for this job, because the reader has no photo to check the output against [20]. The ranking is a result on one workload: AliExpress product photos described in Hebrew, on a test set whose size the post does not give [19]. It carries over to another catalogue only if that catalogue's photos and output language resemble these.
What to watch
- The cause of the voice search failure the VoiceOver user hit first, and what fixed it.
- How the favourites, price-alert and similar-products pop-ups were rebuilt to take and return focus.
- Whether the Haiku, Sonnet and Opus ranking holds on product photos in languages other than Hebrew.