Building accessible Android apps for people with low vision

Using accessibility features for visually impaired users is an essential part of Android development. An app may work correctly with touch input and still be difficult to use when a person relies on TalkBack, magnification, large text, or a Braille display. Accessibility should therefore be considered while designing the interface, rather than added after the main screens are complete.

For Australian developers, this also supports a broad local audience. People may use an app on public transport in Sydney, outdoors in bright Queensland sunlight, or with an Australian English voice setting. Clear controls and predictable navigation make a practical difference in each of these situations.

Android provides many built-in tools for accessible mobile applications. Views can expose useful labels, buttons can receive keyboard or switch focus, and layouts can respond to font scaling. These capabilities work best when the interface has a sensible structure and does not depend on colour or tiny touch targets.

The examples below focus on Android views and common Kotlin or XML patterns. The same principles apply to shopping apps, banking tools, community services, and educational projects published for the Australian Google Play market.

Start with meaningful content descriptions

A screen reader needs a short, useful name for an image button or decorative control. In XML, an icon that performs an action should have a contentDescription that explains the action rather than the image itself.

<ImageButton
    android:id="@+id/saveButton"
    android:layout_width="48dp"
    android:layout_height="48dp"
    android:src="@drawable/ic_save"
    android:contentDescription="@string/save_note" />

The string might be “Save note”, not “floppy disk icon”. If an image is purely decorative, set android:contentDescription="@null" so TalkBack does not announce unnecessary information. Text displayed beside an image usually provides the accessible name, so repeating it in the description creates noise.

Avoid adding descriptions to every view automatically. A heading, label, input field, and action should have a logical reading order. For custom components, use accessibility delegates or standard Android widgets where possible, because familiar controls already expose roles and states to assistive technology.

Make touch, text, and colour adaptable

A visually impaired user may enlarge system text or display content with magnification. Use sp for text and avoid fixed heights that cut off enlarged words. A button should be able to grow vertically, and a form should remain usable when the device is set to a large font scale.

Interactive controls should have a touch target of at least 48dp by 48dp. This helps users with low vision who need to zoom in and users with limited dexterity. Extra padding can enlarge the clickable area without making the visual icon appear oversized.

Colour alone must never communicate an error, selection, or status. Pair colour with text, an icon, or a change in shape. Test contrast in both light and dark themes, and check the interface in bright outdoor conditions. This matters for someone checking a community app in Melbourne sunlight or reading a map while walking through central Brisbane.

Organise focus and screen-reader navigation

TalkBack reads controls according to the accessibility tree and focus order. Place views in a natural sequence: title, supporting information, input fields, validation messages, and then the main action. A visually attractive layout can still be confusing if the reading order jumps between unrelated columns.

When content changes, announce important updates without moving focus unexpectedly. For example, after a form submission, place an error message near the relevant field and expose it to accessibility services. A loading indicator should communicate its state, while a progress update should not repeatedly interrupt the user.

The following choices provide a useful baseline for common Android components:

For a list or RecyclerView, consider whether each row should be announced as one meaningful unit. A weather item could be read as “Sydney, 22 degrees, partly cloudy” rather than forcing the user through separate decorative icons and duplicated labels. Stable ordering is especially helpful in apps used with Bluetooth accessories or external keyboards.

Support TalkBack, magnification, and Braille

TalkBack users navigate by swiping, exploring by touch, and using gestures to move through headings, links, buttons, and controls. Headings should be identified with suitable accessibility properties or semantic roles where the framework supports them. Avoid gesture-only actions that have no visible or accessible alternative.

Magnification can change which part of a screen is visible, so avoid placing essential actions in cramped overlays or relying on precise drag gestures. Scrollable areas should scroll with standard Android behaviour. A user should be able to dismiss a panel with a clearly labelled button as well as a swipe gesture.

Braille displays and keyboard navigation depend on meaningful focusable elements. Do not mark large containers as focusable unless they have a genuine purpose. When a custom view handles clicks, expose its clickable state and action, or replace it with a standard Button, CheckBox, or Switch.

Add accessible preferences and practical feedback

An accessibility settings screen can let users choose larger text, spoken feedback, simplified layouts, or vibration patterns. Store simple preferences with SharedPreferences or DataStore, and apply them consistently across activities. A setting labelled “Use high contrast” should affect text, controls, and status indicators rather than changing a single colour.

Audio and haptic feedback can supplement visual information. For example, a delivery app may provide a spoken status and a vibration when an order is ready. Feedback should remain optional, avoid repeated announcements, and respect Android’s volume and Do Not Disturb behaviour.

Connectivity features also need accessible status messages. If an app pairs with a wearable or another phone, report “Connected”, “Searching”, or “Connection failed” in text that TalkBack can read. A developer working through Bluetooth data transfer should expose connection progress and error states instead of communicating them only through changing icons.

Test with real assistive technology

Turn on TalkBack from Android accessibility settings and complete the main tasks without looking at the screen. Check whether every control has a useful name, whether focus moves predictably, and whether dialogs return focus to a sensible element after closing. Test portrait and landscape layouts, large fonts, dark mode, and magnification.

Android Studio’s Accessibility Scanner can identify small touch targets, missing labels, and contrast concerns. It is useful for finding obvious defects, but automated tools cannot judge whether instructions are understandable or whether a long announcement is tiring. Manual testing remains necessary.

Include an accessibility test device or emulator in the project workflow. Test different Android versions and screen sizes, including the smaller phones still used by some Australian customers. A service app intended for users across Perth, Adelaide, and regional areas should also remain functional with intermittent connectivity and should not hide essential information behind a remote image or animation.

An accessible Android interface is clear, flexible, and respectful of different ways of interacting. When developers combine semantic labels, adaptable layouts, strong contrast, keyboard support, and real TalkBack testing, visually impaired users can complete tasks independently and with less effort.