Most accessibility audit tools tell a screen reader user "audit complete" and stop there. That is a compliance-shaped truth. It is not a useful one.
If I am using an audit tool as a screen reader user, "audit complete" is the moment I need information the most. I have run the check. Something changed, or nothing changed. A sighted user glances at the results panel and knows in one second. I have to hunt: tab into the findings list, arrow through, find the summary, work out what is new versus what is left over from last time.
AMASAMYA v4.3.0 was the release where I decided to stop making the screen reader do that work.
Why one utterance and not two
There is nothing clever about the code. The diff engine already ran. The completion announcement already existed. The change was to concatenate them into one live-region write rather than firing two events that a busy assistive technology stack would potentially coalesce, drop, or reorder. That is the whole feature.
I tried the two-event version first. It failed in exactly the way you would expect if you have ever built anything for NVDA. If the audit-complete event fires while NVDA is still speaking the last table row of the findings render, the completion beep gets queued behind whatever comes next. Sometimes the diff summary landed first. Sometimes the completion word landed first. Sometimes both were dropped because a polite region was being written to by another handler.
The one-utterance model is boring, and boring is the point. There is exactly one polite-region write per audit run. The screen reader either announces the whole sentence or, in the rare case that a user interaction pre-empts it, announces none of it. There is no half-announcement.
What the sighted seat never sees
If you are auditing this behaviour without a screen reader, you cannot verify it exists. Chrome's DevTools do not show what NVDA queued. The visible findings panel looks identical before and after this change. The only way to know it works is to open NVDA Speech Viewer (NVDA+N, Tools, Speech Viewer) and watch the trailing text after the completion signal.
I mention this because it is a class of bug that is trivial to introduce and impossible to notice unless the test is being run by someone who lives in a screen reader. A regression tester using axe-core will never catch it. A sighted QA lead reading the JIRA ticket will never file it. It gets found once, by one person, and either they fix it or the tool stays quietly broken.
That is what "blind product builder" means in practice. It is not a headline claim. It is the reason certain classes of defect get fixed in AMASAMYA that stay unfixed in tools with larger teams and better budgets.
Where to see it
- Install AMASAMYA from the Chrome Web Store. The polite-region behaviour ships in v4.3.0 and later, currently v4.3.1.
- Load a page. Run an audit. Note the completion announcement.
- Load the same page in a new tab or after refresh. Run a second audit. This one carries the diff summary.
Open Speech Viewer if you want to see it in text. Open your ears if you trust them.
I built this because I wanted the tool to work for me. If it does not work for you, tell me what broke and on which screen reader. Feedback via the AMASAMYA feedback form or LinkedIn both reach me the same day.