Inclusive Apps: A Checklist for Blind and Low-Vision Users

An inclusive app is one that a blind or low-vision person can use to finish its main tasks, with a screen reader, large text or high contrast, and voice where it helps. To judge whether an app meets that test, check its labels, focus order, contrast, speech feedback, touch target size and voice alternatives, then confirm the results by testing with real users. The checklist below is written for product teams, reviewers and buyers who want a practical way to decide.

Key takeaways

• Every control needs a clear name that a screen reader can announce.
• Focus should move in the same order as the screen and the user's task.
• Contrast and text size should follow the WCAG contrast levels, and the app should respect the phone's text settings.
• Important changes should be announced by speech or sound, not only by colour or a moving element.
• Voice alternatives help when a gesture or a small target is hard to use.
• Test with blind and low-vision users, not only with automated tools.

The inclusive apps checklist

The table below gives six checks, what a good result looks like, and a quick test a reviewer can run in a few minutes on each main screen.

Screen reader labels and focus order

A screen reader reads what the app tells it. A button labelled only as an icon, or a field with no name, leaves the user guessing. Good labels say what the control does, such as Add to cart or Search by name, and avoid repeating the screen title on every item. Check that labels are announced in the order a person would use them, because a focus order that jumps between the header, a banner and the form creates confusion and wasted time.

Watch for pop-ups. When a dialogue opens, focus should move into it, and when it closes, focus should return to the control that opened it. A user who is left in the background of a closed dialogue cannot tell what has happened.

Contrast, text size and touch targets

Low vision users often rely on high contrast and large text. The app should meet the contrast levels set in WCAG and should respond to the text size set on the phone. Test both. Turn text size up, then check that buttons do not overlap, that labels are not cut off, and that the main action remains on screen.

Touch targets matter for users with tremor, low vision or limited dexterity, and for anyone using the phone while walking. Controls should be large enough to hit without precision and spaced so that a neighbouring control is not pressed by mistake. Avoid tiny icons placed close together at the bottom of the screen.

Speech feedback and voice alternatives

A blind user cannot see a success tick or a red error border. Each important state change needs a spoken or audible message: a file saved, a payment failed, a request sent. The message should say what happened and what the user can do next. Silent state changes, where the only signal is a colour or an animation, are a common failure.

Voice alternatives give a second route to the same task. The MIRA voice assistant is one example of a voice-first route, activated by a single button press. Within any app, check whether the main tasks can be started and finished by voice, and whether a user who hears a question can answer it without needing a screen.

How to test with real users

An automated checker can find missing labels and low contrast. It cannot tell you whether a task makes sense to a blind person. For that, run a short test with blind and low-vision users.

1. Recruit three to five users with a range of vision, including some who use screen readers and some who use large text.
2. Give each person one or two real tasks, such as booking an appointment or reading a bill, and ask them to think aloud.
3. Do not help unless the person is stuck for a long time. Note every point of hesitation, repeat and failure.
4. Ask what they expected to happen at each failure, and what would have helped.
5. Fix the most common failures first, then test again with a different user.

Keep the notes specific. A line that reads The save button was not announced is more useful to a developer than a general comment that the app is hard to use. Share the notes with the team, and use the same tasks for each release so that changes can be compared.

For a closer look at how an accessibility app differs from a screen reader, read the screen reader vs accessibility app guide. Then pick the top three checks from the table and run them on your next release.