What I found when I audited my own app

Many blind people in India use my app, eSpeak NG Text-to-Speech, as the voice of their phone. When TalkBack reads a message, a menu or a bank balance, eSpeak is what they hear. It has more than 100,000 installs.

I use a screen reader every day, and I now offer accessibility audits. So I thought it was only fair to start with my own app, and to audit it exactly the way I would audit a client’s: same scope, same standard, same report. Then publish the result.

Here is what I found, and what it taught me.

How I did it

The audit covered 10 screens of the Android app: the home screen, Settings, the Reader, the Pronunciation Dictionary, the community forum, Remove Ads, About and Contact, plus the voice-data installer and the ads. Every finding was checked against WCAG 2.2 at level AA and given a severity:

• Critical: blocks a key task.
• Serious: a key task is very hard, or risky.
• Moderate: a real barrier, with a workaround.
• Minor: friction.

For this sample, the findings came from a review of the app’s code, and I confirmed the main one on my phone with TalkBack. A client audit tests every finding on real devices.

The result

No critical problems: every key task can be done with TalkBack. But 7 serious, 18 moderate and 15 minor findings. For an app built for screen reader users, by a screen reader user, that was humbling.

Four lessons stood out.

1. A control can be labelled and still be wrong

The speech-rate slider in Settings is the setting people open Settings for. With TalkBack, it says:

“175 WPM, seek control, 25 percent.”

Two numbers, and the second one is meaningless: it is the slider’s position, not the speech rate. The slider also has no name. The cause is one line that puts the value into the slider’s label. The fix is to give the slider a proper name, and give the value to Android as a state description:

seekBar.setContentDescription(getTitle());
ViewCompat.setStateDescription(seekBar, text);

Automated checkers would pass the original: the slider had a label. Only listening to it shows the problem.

2. Some bugs are about safety, not labels

The Volume setting goes down to 0 percent. For most apps, that is harmless. But when eSpeak is TalkBack’s voice, volume 0 silences the whole phone, and a blind user cannot undo it without sighted help or a second speech engine.

No WCAG criterion covers this exactly. That is the point: an audit has to understand who uses the app and how, not just tick criteria. The fix is a sensible minimum volume, or a spoken “Keep this volume?” check that undoes the change automatically.

3. Ads are an accessibility decision

eSpeak shows ads, with a purchase to remove them. Two of the serious findings are about how ads behave with a screen reader:

• A full-screen ad can open right after tapping Settings or Forum. TalkBack focus moves into the ad, so the user may think they’re in Settings while every swipe reads the ad.
• When you come back to the app, an ad can cover whichever screen was open.

For sighted users these are small interruptions. For screen reader users they are disorienting, because focus moves somewhere they didn’t choose. If your app shows full-screen ads, check where TalkBack focus goes when one opens, make sure its close button is easy to find and clearly named, and keep ads away from screens where people are in the middle of a task, like setup or payment.

4. The quietest failures are the worst

Two findings make no sound at all:

• The voice-data installer’s progress bar stays at 0 percent for the whole installation, then the window closes without saying whether it worked. A small code bug counts the bytes in the wrong place.
• The Contact form: if the network fails, the “Please wait” message closes and nothing is said. The user can’t tell whether their message was sent.

Sighted users can glance at the screen. Screen reader users only know what they’re told. Every result, success or failure, needs to be announced.

What works well

The audit isn’t only problems. The Pronunciation Dictionary turned out to be a model screen: real labels, errors announced on the field, edit and delete reachable with a single tap, and nothing hidden behind long-press. The fixes for several other screens are simply “do what the Dictionary does”.

What happens next

Most of the fixes will go into a coming update of the app, serious ones first. The full report, with every finding and its fix, is public: sample accessibility audit report.

If you build apps, check these this week

1. Turn on TalkBack and move every slider in your app. Do you hear a name and a meaningful value?
2. Find every setting that could lock a user out, and add a safe minimum or an undo.
3. Open your app’s main screens while an ad or pop-up is due. Where does focus go?
4. Make every long task, and every failure, say something when it finishes.
5. Find your best-built screen, and copy its patterns everywhere else.

If you’d like this done for your own app, here is how my audits work.