This part of the history is uncomfortable in a useful way. It shows me correcting a story that was too easy to overread.
Screen reader support is one of the most sensitive areas in accessibility tooling because it is very easy for a repo to sound more definitive than the implementation deserves.
A11Y Cat hits that problem in public. On April 8 there is a commit explicitly called “Clarify Guidepup as repo-side smoke coverage.” A few hours later there is another one: “Remove Guidepup and simplify screen reader story.” That second commit deletes the old screen-reader automation layer, removes its hooks and docs, and keeps the public story aligned around guided manual review, Playwright coverage, and real assistive-technology sign-off.
I think that sequence says a lot. Something about the previous framing was too easy to misread as an in-product capability or as a stronger validation story than the repo really had. Instead of quietly letting that ambiguity live, the project backed it out.
That is not the same thing as abandoning screen-reader work. The screen-reader review surface stays in the product. The manual accessibility checklist stays. The later extension docs and release checklist become even clearer that NVDA, JAWS, and VoiceOver sign-off is still required. What changes is the honesty around what the automated or semi-automated parts can claim.
This is one of the first places where I can see the builder moving from “that sounds useful” to “is that wording actually safe?” That is an important growth step in accessibility work. If the tool is going to help with screen-reader-related review, it has to be extremely careful not to imply that it is running a real assistive-technology session when it is not.
The later virtual screen reader work makes that lesson even clearer. When that subsystem arrives, the docs go out of their way to say it is a virtual review aid and not a real NVDA, VoiceOver, or JAWS session. That kind of explicit phrasing only happens because the repo has already been burned by the looser story.
I think this whole phase is a good example of engineering maturity that does not look glamorous in a changelog. It is mostly correction, removal, and rewording. But those are exactly the kinds of changes that make a tool easier to trust.
Visual evidence
The repo has screen-reader-related UI images, but not a reliable screenshot of the removed Guidepup automation layer itself. The closest honest visual references are the bookmarklet-era screen-reader audit surface and the later extension screen-reader review panel:
What I was really learning here
I was learning that in accessibility tooling, fuzzy wording can be as dangerous as weak implementation. If the tool cannot honestly claim a real AT check, the docs and UI have to say that plainly.
Evidence
- Commits:
95be0c5– Guidepup clarified as repo-side smoke coverage486c2c7– Guidepup layer removed and screen-reader story simplified5ab9f2c– later AT sign-off matrix added
- Files:
../../MANUAL_ACCESSIBILITY_CHECKLIST.md../../SUPPORTED_ENVIRONMENTS.md../../README.md- later comparison docs in
../../docs/at/
- Historical paths removed by
486c2c7:tests/screen-reader/guidepup-helpers.jstests/screen-reader/guidepup-nvda.spec.jstests/screen-reader/guidepup-voiceover.spec.js
- Inference:
- The phrase “burned by the looser story” is an inference from the speed of clarification and removal, not from a separate retrospective note.
