Mobile accessibility determines whether someone can complete a task using an interaction method that works for them. They might use VoiceOver, navigate Android with TalkBack, enlarge text, or use switches. QA's central question is concrete: can the person independently sign in, find information, correct an error, and complete the action?
An attractive screen does not guarantee an accessible journey. An icon may have no accessible name, an error may appear outside focus, or a payment button may disappear with enlarged text. These defects can block use as completely as a broken API.
Where to begin
Choose a critical journey and prepare its states: first launch, authenticated user, empty list, populated list, API error, and open keyboard. Record the device model, OS version, build, language, screen reader version, and system text settings. Results depend on their combination, so “tested with VoiceOver” without environment details provides little help with reproduction.
Start on a real device and use the screen reader's built-in tutorial. Enabling a screen reader changes the meaning of an ordinary single tap; unfamiliarity with gestures can easily be mistaken for an application defect.
Element names, roles, and states
Users should understand what an element is, what it does, and its current state. “Cart, 3 items” is a useful name for a cart button; an internal image name such as “cart_icon_24” is not. A switch should announce whether it is on, and a selected tab should expose that state semantically.
Check context as well as individual labels. Repeated More details buttons in an order list need enough context to identify the right order. Decorative images should not clutter reading order. Conversely, grouping multiple elements must not hide an available action.
Reading order and focus management
Navigate with sequential swipes, then explore by touch. All essential elements should be reachable in an order that fits the task. Opening a modal should move focus inside it; the obscured background should not intercept navigation. Closing it should return users to a logical continuation point.
Also check list refreshes, deletion of a selected row, back navigation, and keyboard appearance. Resetting focus to the start of a long screen after every quantity change can make a technically accessible interface difficult to use.
Large text and scaling
On iOS, test Dynamic Type, including supported accessibility sizes. On Android, change font size and display scaling. In every state, check whether users can read prices, errors, and action terms; reach buttons; scroll; and close dialogs.
A truncated description may sometimes be intentional, but a missing order total or unreachable confirmation creates a functional barrier. Test long translations, large numbers, supported landscape orientation, and enlarged text together with an open keyboard.
Target size, color, and gesture alternatives
Measure the touch area, beyond the visible icon. Official Android guidance specifies a target of at least 48 × 48 dp. Check spacing between neighboring actions separately: enlarging an invisible hit area must not make opening a row trigger deletion.
Explain errors in text and convey selection through more than color. Check accessible alternatives for drag-and-drop, complex swipes, and long presses. Measure contrast against the product's chosen standard, including dark themes and text over images. WCAG contrast criteria exempt inactive elements; their legibility can still be assessed as a usability concern without automatically declaring a standards violation.
Messages, sound, and motion
After saving or encountering an error, users should learn the outcome without visually searching the screen. Check announcements of significant changes and the ability to revisit them. Excessive announcements also interfere: a timer announcing every second can interrupt form reading.
Check supplied captions for video and visual equivalents for important sounds. With reduced motion enabled, assess transition animations: meaning and control should remain available. A system setting alone does not establish correct application behavior.
Practical example: checkout
Prepare a test account with two products in its cart. Enable TalkBack or VoiceOver and complete the journey without visual guidance.
- →Find both products and change one quantity: the name, new quantity, and total are announced, and focus stays in a logical location.
- →Remove the second product: exactly that item is removed, the screen reader can perceive the result, and one cart row remains.
- →Submit the form with the required address empty: the field is reachable, its error is announced and associated with it, and no order is created.
- →Correct the address and confirm: one test order is created, its number is readable, and repeating the gesture creates no duplicate.
Repeat with the largest agreed text size. The measurable outcome is independent completion of all four steps without unreachable actions or lost required information. Completion time can support comparisons between versions, but an arbitrary speed target does not replace an accessibility assessment.
What tools provide and how to report defects
Accessibility Scanner, inspectors, and automated audits identify some technical problems. They cannot determine whether a label makes sense or a task can be completed. Android explicitly recommends combining manual testing, tools, automation, and user feedback; Apple also recommends testing interactions with assistive technologies, including VoiceOver.
Record the navigation method, current focus, actual spoken output, and expected behavior in a defect. Attach a recording or transcript without personal data. “The payment button cannot be reached at checkout” is more useful than “poor accessibility.”
Key takeaways for QA
Evaluate accessibility through completed user journeys. Semantics, focus, text, alternative controls, and feedback all matter. Automated audits are one part of the process, and one successful journey does not establish application-wide standards compliance. QA's most valuable finding is a reproducible barrier with clear user impact.