How to Design Mobile Apps for People with Low Vision

An emulator and a flagship phone can create a false sense of quality. Many mobile app problems appear only on devices with slower processors, less memory, weaker cameras, or older operating systems.

Why it matters

Users do not experience “low FPS” or “slow cold start” as technical events. They see a freeze, tap twice, or close the app. The Josh case shows how optimizing startup across device classes improved the experience, especially for older and low-end phones.

A minimum test matrix

• One current flagship.
• One mid-range device with a common OS version.
• One affordable device with limited memory.
• Slow connectivity and Wi‑Fi-to-mobile transitions.
• Low battery and background load.

Compare more than launch time. Test scrolling, keyboard opening, image loading, rotation, resume after backgrounding, and behavior under memory pressure. Record the journey in which a defect appears, not only the defect itself.

An affordable device is not a “worse” user. It is a real environment in which the product must keep its promise. Testing there reduces drop-off, negative reviews, and expensive emergency fixes after release.

Source: Android Developers: Josh app startup case study.

A mobile interface must remain readable beyond the designer’s mockup. Users may enlarge system text, change contrast, enable spoken feedback, or view the screen in bright light. If the layout breaks, that is a product problem, not a personal failure.

Typography that scales

Use relative sizing and test long headings, localized text, and increased line height. Do not clip content to preserve a card’s exact height. Users should see the complete title, error, and primary action.

Contrast is more than black and white

Check text, icons, input borders, disabled states, and errors. Color should not be the only way to communicate status; add a label, shape, icon, or position.

Android guidance recommends consistent and adaptive experiences across form factors and settings. In practice, test a set of states and journeys, not one screenshot.

• Increase system text to the largest useful setting.
• Test long localized strings.
• Remove color and check whether meaning remains.
• Check focus, spoken labels, and touch targets.

Accessible typography rarely requires complex solutions. It requires discipline in the component system and a willingness not to trade meaning for decorative precision.

Source: Android Developers: What a great user experience looks like.

Mobile accessibility is not a separate mode for a small group of people. It determines whether text can be read, controls can be tapped, messages can be understood, and a journey can be completed under different conditions.

A basic checklist

• Text and controls have sufficient contrast.
• The UI works with enlarged system text.
• Every interactive element has a meaningful label.
• Functionality does not depend on color alone.
• Focus order matches reading order.
• Errors explain both the issue and the recovery path.

Test with VoiceOver and TalkBack, a keyboard where possible, large text, and bright light. Automated checks find some problems but cannot replace real users and journeys.

Accessibility as product quality

Clear labels, large touch targets, and understandable states help everyone: people with temporary injuries, users on the move, older audiences, and people on weak connections. Android quality guidelines connect a good experience with consistency, adaptability, and usability across devices.

Build accessibility into the design system, components, and Definition of Done instead of leaving it until the end of a release. Problems are cheaper to fix, and the team gets a stable standard for every new screen.

Source: Android Developers: What a great user experience looks like.