TalkOver, revisited

2026-09-17T00:00:00Z

Once upon a time, long before the age of AI, I proposed rewriting Android's TalkBack code so that it would work more like VoiceOver on Apple devices. My grand invention was to be called "TalkOver."

I never got past the name. The idea stayed with me long enough that I finally asked the question properly: how far apart are these two gesture models? Would TalkOver have needed a rewrite, or was the gap smaller than it looked from the outside?

I did not ask a forum. Google has published TalkBack's source, so I read it. Two files answer the question. gesture_preferences.xml defines every gesture slot TalkBack recognizes, from a one-finger swipe to a four-finger triple-tap. donottranslate.xml names more than a hundred actions you can bind to any slot, and it records the default binding for each one. That is ground truth, not a summary of ground truth.

The gap is smaller than TalkOver assumed

Several of VoiceOver's core gestures are already TalkBack's defaults under different names.

VoiceOver	TalkBack default
Swipe right or left moves to the next or previous item	Identical: `NEXT` and `PREVIOUS`
Swipe up or down adjusts the rotor's current setting	Same idea: `SELECTED_SETTING_NEXT_ACTION` and `SELECTED_SETTING_PREVIOUS_ACTION`
Two-finger tap pauses or resumes speech	Identical: `PAUSE_OR_RESUME_FEEDBACK`
Two-finger double-tap is the "magic tap" (play, pause, or answer a call)	Identical intent: `MEDIA_CONTROL_OR_VOICE_INPUT` on the same gesture

The younger engineer who named TalkOver would have rewritten four gestures that needed no rewriting.

Where they diverge, and what closes the gap

The real differences are narrower than "these are different apps," and most of them are one settings screen away from closing.

VoiceOver	TalkBack default	What closes it
Three-finger swipe up or down scrolls the page	Bound to setting selection; scrolling lives on two-finger swipes	Rebind the three-finger swipes to `SCROLL_UP` and `SCROLL_DOWN`. Both are assignable actions.
Two-finger swipe up reads the whole screen from the top	Scrolls up	`READ_FROM_TOP` exists as an action. It is not on that gesture by default.
Two-finger swipe down reads from the current position	Scrolls down	`READ_FROM_CURRENT` already sits on the two-finger triple-tap. Bind it to the swipe as well if you want the VoiceOver gesture, not only the result.
Four-finger tap at the top or bottom jumps to the first or last item	Unbound	`FIRST_IN_SCREEN` and `LAST_IN_SCREEN` exist and sit idle. The four-finger triple-tap slot is unassigned and waiting.
Three-finger swipe left or right moves a page	Android has no general page concept	The closest fit is the four-finger swipe left or right, which is already `PREV_CONTAINER` and `NEXT_CONTAINER`.

Then there is the one gap no settings screen closes. VoiceOver's two-finger scrub, a "z" drawn on the glass, goes back or dismisses whatever is open. TalkBack has no scrub gesture type at all. Its back gesture is a one-finger swipe down and then left, an angle swipe. The intent is the same, the shape is different, and there is no remap for that, because the shape does not exist on the Android side.

What I would tell that younger engineer

TalkBack did not need a rewrite. It needed someone to open Settings, Accessibility, TalkBack, Customize gestures, and treat it as the fully remappable surface it already is. TalkOver, as I imagined it, mostly ships today. You only have to know which handful of gestures to move.

The one thing it cannot do is invent a gesture type that Android's touch model does not support. That part of the old idea was right, for reasons I could not have articulated at the time.

Every binding in this post comes from gesture_preferences.xml and donottranslate.xml in the google/talkback repository. If Google changes a default, those two files will say so before any support article does.

Accessibility is a build error, not a review comment

2026-09-17T00:00:00Z

I have written the same finding hundreds of times: insufficient contrast, secondary text, dark mode, 1.4.3, fails. I have written it for enterprise clients, for a state agency, and for freelance clients who paid me to find it. Every time, somebody fixed it, and every time, it came back a release later.

I am done writing that finding. On this site, it cannot exist.

The rule

Every color in my design tokens can declare which backgrounds it sits on and what ratio it owes against each one:

"textMuted": {
  "value": "#4A5561",
  "$contrastAgainst": ["bg", "surface", "bgSubtle"],
  "$minRatio": 4.5
}

When the tokens compile, a script checks every pair with the WCAG 2.x formula. If any pair falls short, the script prints the pair, the ratio it got, and the ratio it needed, and then it exits. No CSS is written, and the site does not build. There are eighty-one pairs across three themes, checked on every deploy.

What it caught on day one

I required the focus ring to reach 3:1 against both the page and the primary button. The build stopped me: 1.55:1 against the button in the light theme.

The build was right. The ring sits two pixels outside the control, so the color next to it is the page, not the button. I had written a requirement that does not exist in WCAG, and the build would not let me ship it. Nobody reviewed that mistake. Nobody had to.

Why tokens and not a linter

A linter looks at a rendered page. It cannot see the theme that is not active, the state nobody triggered, or the component that is absent from the page it is checking. I know this because I run linters for a living, and then I test by hand, because linters miss things.

A token file is the one place where every color and every background exist together before any of them is drawn. Check there, and you have checked all of it, in milliseconds, before a human looks.

I apply the same rule to anything a machine can decide. On this site, a post with an image and no alt text does not build. A post whose headings skip a level does not build. If a machine can decide it, the machine decides it first.

What is left for me

The audit still has work in it: focus that lands on the body after a dialog closes, a live region that mounts with its message already inside and never speaks, a carousel that moves because nobody stopped it. Those need a person with a screen reader. I am that person.

Contrast never needed me. It needed a build step.

Meredith Boyce: writing