Accessibility Testing for Android and iOS Apps

Correctly labelled buttons do not guarantee a usable checkout when focus moves behind an error dialog. A layout survives larger text on the home screen but clips the confirmation amount. Accessibility testing has to follow complete tasks through changing states, not just count labels in a static screen.

Select critical paths: sign in, search, complete a form, correct an error, review a result and sign out. For each task, record the visual route and the nonvisual route. On Android, use TalkBack for screen-reader interaction; on iOS, use VoiceOver. Platform accessibility inspectors and automated checks can reveal missing labels or small targets, but human navigation is needed to determine whether a task makes sense.

Test the same route with text enlargement, display zoom where applicable and a narrow device. A screen may be usable at its default size while an enlarged keyboard covers the submit button. The expected result is not necessarily identical geometry; it is that the user can reach the action and understand the outcome.

Do not turn this matrix into an unsupported claim that every app must implement every feature identically. Test against the product's supported input methods and its actual accessibility requirements, then record any route that blocks a critical task.

Start at the top of the screen and move one element at a time. A useful label identifies both object and action: “Remove saved card ending 42” gives more context than “button.” Avoid reading decorative icons or repeated container text when they add no information. If a row opens details, the row's action should be discoverable without requiring a sighted guess about a chevron.

Check the order after a modal opens, after a loading state completes and after an error appears. Focus should move to a meaningful location and should not fall back to a vanished element. Close the modal and confirm focus returns to a logical point. A correct initial tree can still fail when asynchronous content inserts itself above the current item.

Test grouped controls such as a date picker or quantity stepper as a task. Can the user hear the current value, change it and confirm the change? A label alone does not make an interactive control operable.

Pick a dense form or transaction review, increase the system text setting to the largest size the app supports and enter a long but valid value. Check labels, helper text, errors, totals and buttons. Scroll to the bottom with the keyboard open. Rotate a supported device or use a tablet split view where the product supports those configurations.

Design may wrap text, grow cards or change to a vertical stack. The test should catch content that is visually truncated without a way to expand it. Do not accept an abbreviated monetary amount if that changes what the user believes they are confirming. Check both positive and negative amounts if the app displays them differently.

Repeat with a longer translation, because text expansion and enlarged type interact. A localization test that passes at default text size does not cover the combination. Test right-to-left reading order for locales the product actually supports.

Inspect text over photos, disabled controls, focus outlines and status badges in light and dark themes. An automated contrast calculation is useful for flat colours, but a gradient, translucent overlay or changing image can create weaker regions. Capture the worst background behind the actual text.

For a status chart, switch to grayscale and describe the result without mentioning colour. Labels, patterns or direct values can preserve meaning. For errors, a red border alone does not say what to fix; include text tied to the field and announce it at the right time.

Measure touch targets against the applicable platform guidance and product design, but also test proximity. Two individually large targets can still be difficult if they are packed together or obscured by a system gesture area. Try one-handed use and a device with a screen protector if that is relevant to the audience.

Enable the system reduced-motion preference and open transitions, progress indicators and success states. If the animation disappears, another cue must convey whether the action completed. A spinning loader with no textual status can leave a screen-reader user uncertain for the entire wait.

Let a session expire while a form is open. Determine whether the app warns the user, preserves what can be saved and gives enough time to respond. Timing rules are product-specific, especially for security-sensitive actions, so record the expected behavior before grading the test.

Use haptics and sound as optional feedback, not the only signal for a required action. Mute the phone, turn off vibration and repeat the task. If a game depends on an audio cue, add a visual or text alternative and verify that the alternative communicates the same decision point.

An accessibility test can catch a missing content description or a control that disappears from the semantic tree. It cannot reliably decide whether an error message explains how to recover or whether a spoken sequence is coherent. Keep automated checks as a fast regression signal and assign manual task runs for releases that change navigation, forms or overlays.

Report the screen, input method, text size, focus sequence, expected announcement and actual announcement. A short screen recording with spoken output can make a focus bug much easier to reproduce. Avoid exposing private account content in recordings and logs.

A transaction list may contain dates, merchants, amounts and a status icon. Read several rows with a screen reader and check whether each item conveys its record identity and value. A column header that is visible at the top of the page may not be spoken while navigating a long list. Group information meaningfully without repeating the entire table heading for every cell.

Load more rows, sort the list and open one detail screen. Focus should remain near the user's position or move to a clearly announced result. If new content arrives automatically, it should not interrupt speech with an unbounded stream of announcements. Test an empty result and a loading failure as well as the populated list.

For an interactive chart, offer values in a readable list or another accessible representation. A tester should be able to answer a concrete question such as “Which day had the highest amount?” without interpreting only the plotted colour or touch location. Compare the answer obtained visually with the answer available through the alternative route.

Choose the densest confirmation flow. With TalkBack or VoiceOver running, navigate from the first field to the result, trigger one validation error and correct it. Write down the spoken order, the control name and the place where focus lands after the error and after the modal closes. An automated audit can detect some missing labels but cannot determine whether this complete journey is understandable.

Repeat with the largest text size supported by the app and a longer translated value. Verify that the amount and action button remain visible with the keyboard open. If the flow includes a chart, provide a readable list of values so a user can answer a question such as which day has the highest total without relying on colour or touch position. Finish by disabling sound and vibration; the outcome must still be conveyed.