Using Braillito with VoiceOver and TalkBack
Braillito is built to be used with VoiceOver on iPhone and TalkBack on Android, and that work is in the code: the app detects the screen reader by itself, braille cells are announced by their dots, games that need sight are hidden, and automatic checks block some accessibility mistakes before release. What we do not have is an external audit that certifies it.
This article keeps those two things apart on purpose. First, what a screen reader is and how to use it, with gestures checked against Apple's and Google's documentation. Then, what exactly is in our code. And at the end, a whole section on what we cannot claim.
Key points
- A screen reader is not a mode of the app: it is part of the system. VoiceOver and TalkBack come with iOS and Android, and they do the talking. The app supplies the labels they read.
- There is no separate "accessible version" of Braillito. It is the same app, the same course and the same exercises, adapted when a screen reader is running.
- The app detects VoiceOver and TalkBack by itself, when it opens and if you turn them on or off mid-session. There is nothing to set up; the old setup question was removed in March 2026.
- There is no external audit, no declared WCAG level, and no braille display input. And three screens still give no spoken feedback under VoiceOver on iPhone: we name them below.
About this article
This article is written by the Braillito team and describes its own product. That does not invalidate it, but it changes how to read it, so here is where each claim comes from.
The claims about our code can be checked: they name the file or the rule. The claims about VoiceOver and TalkBack gestures come from Apple's and Google's official documentation, linked in each case.
What this article does not contain is a test report on real devices. We do not say "works perfectly with screen readers", because that sentence, written by the people who made the app and with no independent test behind it, is worth nothing. If you have tried many apps that promised accessibility and did not deliver, you know why.
What a screen reader is
A screen reader is a program in the operating system that turns what is on screen into speech (or braille, if a braille display is connected) and replaces normal touch use with its own set of gestures. It is not a feature of the app: it is a layer above every app.
The two that matter on mobile are built in and free:
| Screen reader | System | Maker | Cost |
|---|---|---|---|
| VoiceOver | iOS, iPadOS, macOS | Apple | Included |
| TalkBack | Android | Included |
The practical consequence for developers, rarely explained: a screen reader cannot guess what a drawing means. If a braille cell is drawn as six circles and nothing else, the screen reader has nothing useful to say. Someone has to write "dots 1 and 3" into the code. That is, literally, most of the accessibility work in an app like this.
How to turn them on
| VoiceOver (iPhone) | TalkBack (Android) | |
|---|---|---|
| In settings | Settings › Accessibility › VoiceOver | Settings › Accessibility › TalkBack › Use TalkBack |
| Shortcut | Triple-click the side or Home button, if the Accessibility Shortcut is set up | Press and hold both volume keys for a few seconds |
| By voice | Ask Siri to "turn on VoiceOver" | — |
Sources: Turn on and practice VoiceOver on iPhone (Apple) and Get started on Android with TalkBack (Google).
Apple also offers VoiceOver Practice, inside Settings › Accessibility › VoiceOver, where you can try gestures without affecting your iPhone or its settings. If you are teaching braille to someone who has just started with VoiceOver, start there, before opening any app.
Basic VoiceOver gestures
These are the gestures Apple documents in the iPhone User Guide. They work in any app, Braillito included.
| Action | Gesture |
|---|---|
| Select the next item | Swipe right |
| Select the previous item | Swipe left |
| Activate the selected item | Double-tap |
| Read everything from the top | Two-finger swipe up |
| Read from the current item | Two-finger swipe down |
| Scroll one page | Three-finger swipe up or down |
| Go back | Two-finger scrub: move two fingers back and forth three times, like a "z" |
| Change the rotor setting | Rotate two fingers, like turning a dial |
Source: Learn VoiceOver gestures on iPhone (Apple).
The rotor pays off the most and is the least known. Rotating two fingers on the screen chooses a unit of navigation (headings, links, form controls) and then swiping up and down jumps between them instead of going item by item. In an app with many screens, it is the difference between three gestures and forty.
Basic TalkBack gestures
The ones Google documents for TalkBack:
| Action | Gesture |
|---|---|
| Move to the next item | Swipe right |
| Move to the previous item | Swipe left |
| Select an item | Tap |
| Activate the selected item | Double-tap |
| Scroll | Two-finger swipe up or down |
| Open the TalkBack menu | Swipe down then right, or three-finger tap |
| Next reading control | Swipe up then down |
| Previous reading control | Swipe down then up |
Source: Use TalkBack gestures (Google).
TalkBack's reading controls are the equivalent of VoiceOver's rotor: they change what each swipe moves through (characters, words, headings, controls), and they are what makes a long screen navigable.
What is in the code of the iPhone and Android apps
Figures counted in our app's source code on October 7, 2026:
| What | How many |
|---|---|
Accessibility labels (accessibilityLabel) |
426 |
Accessibility roles (accessibilityRole) |
266 |
| Explicit announcements to the screen reader | 64 |
Counts say little on their own, so here is what they do, concretely:
- The app detects the screen reader. It asks the system whether VoiceOver or TalkBack is on when it opens, and listens for changes during the session. Until March 2026 the app asked during setup; that question was removed because the system already knows.
- Braille cells are announced by their dots, for example "Braille sign, dots 1 and 3", and feedback says which dots were the answer ("Correct: … — dots …").
- Games that depend on sight are hidden when a screen reader is on. It is better to say "this game is not for you" than to offer it and have it be a trap.
- The app does not talk over your screen reader. Its own voice is turned off when it detects VoiceOver or TalkBack; otherwise the two would talk over each other, one of the fastest ways to make an app unusable.
- Two automatic checks block code before release. One stops game labels from giving away the answer (announcing "option 2: the letter M" in an exercise about guessing the letter would be useless). The other requires any screen that declares a live region to actually announce its changes, because on iPhone a live region alone says nothing to VoiceOver.
That second rule has three exceptions recorded in the code itself, and we name them because a list of exceptions that is not shared outside pressures nobody. According to our own note, on iPhone these are currently silent for VoiceOver:
- The entry flow, when it switches between phases.
- The success or failure card at the end of a game.
- The combo counter during games.
They are listed in the code so they are not forgotten, and the rule stops any new screen from joining them.
What we cannot claim
This is the section that makes the rest of the article worth something.
A label that exists is not a label that is heard. Every count in this article measures presence, not function. Our own internal review once found an important button whose label was in the code, had passed review, and was still announced as just "button", with no name. Checks and counts catch missing labels; they do not catch focus that never arrives, a nonsensical order or a gesture that cannot reach an element.
There is no external audit. Nobody outside the team has formally evaluated Braillito against WCAG.
We do not declare a conformance level. We aim for WCAG 2.1 level AA and do not claim to meet it. Declaring a level without an evaluation behind it is exactly the kind of promise that harms people who rely on it to decide whether they can use a tool.
We have not tested every combination. There is no systematic test run on every screen reader, device and system version.
And the most uncomfortable one: our automatic checks read the accessibility tree; they do not listen to a screen reader. They are a good, cheap way to catch the most common fault, an unnamed control. But they do not replace going through the whole app with VoiceOver on, on a real phone, and that complete test, with its report, has not been done yet. When it is, it will be published and this section will change.
Braille displays are not an input. The app's text is real text, so a braille display connected to your screen reader shows it like any other text. But you cannot answer exercises with the display. See refreshable braille displays for how displays work with phones.
The course is grade 1 only. Braillito teaches braille letter by letter, not contracted English braille. Our comparison of braille apps says which apps do grade 2 better than us.
How to start, if you use a screen reader
An order that lowers the chance of tripping up in the first five minutes:
- Have your screen reader on before opening the app. VoiceOver and TalkBack are part of the system, not of Braillito. The app will notice them by itself.
- Start with the first world even if you already know braille. The first lessons are also where you learn how announced cells sound, which is a new convention even if braille is not.
- Listen to each game's explanation before starting. It tells you what you will find and where.
- Use the rotor or reading controls to jump by headings instead of moving item by item.
- If something does not work, do not assume it is your fault. Tell us which screen it was: that is what fixes the list above.
How to report a barrier
If a screen cannot be read with your screen reader, an exercise cannot be finished without sight, the contrast is not enough, or something breaks when you enlarge the text, tell us. Concrete reports are the only thing that moves the list of limitations.
What helps us: which screen or lesson it was, which device and which screen reader, and what you expected to happen. Write to [email protected], or call +1 305 462 4160 if writing is the barrier. Our full accessibility statement says the same, and it is the official document.
We treat these reports as bugs, not suggestions.
Frequently asked questions
Does Braillito work with VoiceOver and TalkBack?
It is built for that, and there is specific work in the code: automatic screen reader detection, cells announced by their dots, sight-dependent games hidden, and automatic checks that block some mistakes before release. There is no external audit to certify it, which is why we say "built for" and not "certified", and there are three screens we know are silent under VoiceOver on iPhone. The honest way to settle it is to try it during the free trial.
Do I need to turn anything on inside the app?
No. The screen reader is turned on in the system, and the app detects it by itself, including if you turn it on or off while using the app.
Can I use Braillito with a braille display?
You can read on it whatever your screen reader shows, because the app's text is real text. What you cannot do is use it to answer the exercises: Braillito does not accept display input.
Is Braillito useful if I am totally blind?
The course is designed to be completed without seeing the screen: cells are announced by their dots, results are spoken, and games that need sight are hidden. That said, learning braille on a screen has a limit no app solves: a screen has no raised dots. An app teaches the system (which dots make each letter); touch is trained on paper, a slate or a braille display. More in how to learn braille.
What happens if I find something that does not work?
Write to [email protected] with the screen, the device and the screen reader you were using, or call +1 305 462 4160. We reply within five business days.