Accessibility ≠ Overlay · 23
Accessibility ≠ Overlay: when mobile apps create barriers too
📅 October 2026 ⏱ 7 min read
Digital barriers do not stop at the browser. A mobile app can prevent someone from ordering food, checking an appointment or buying a product if its controls do not work with assistive technology.
An attractive app is not always accessible
Unnamed icons, mandatory gestures and confusing forms can block everyday tasks. Inclusive interfaces support different ways of interacting.
Buttons and icons need names
Every button should announce its purpose, such as ‘Add to basket’ or ‘Open menu’, as well as relevant states.
Images that convey meaning
Product photographs and informative icons need suitable text alternatives. Decorative images should not clutter screen-reader output.
Gestures, focus and navigation
Important actions should not depend solely on complex gestures. Focus and reading order need to remain logical.
Clear forms and errors
Labels, instructions and error messages should explain what is required and how to fix mistakes. Dynamic updates need accessible announcements.
Text, contrast and orientation
Support larger text, sufficient contrast and usable layouts when the device orientation changes, except where a specific orientation is essential.
How to test an app
Complete a real task with VoiceOver on iOS and TalkBack on Android. Check control names, focus, forms, confirmations and gesture alternatives.
What Blind Reader does
Blind Reader is installed on websites and supports web navigation, forms and shopping alongside screen readers. It does not automatically repair every native mobile app.
Build accessibility in
A visual overlay is not a substitute for accessible design. People should be able to understand and complete tasks independently.