Mobile Accessibility

Why it matters

For many people the phone is the main computer, and many disabled users rely on it precisely because the assistive technology is built in. When an app ignores that technology, the result is not a cosmetic defect but a blocked task: a payment that cannot be confirmed, a form that cannot be sent. Accessibility is also a legal or contractual requirement in many markets, for example for public-sector apps and, in the European Union, for services such as e-commerce and consumer banking under the European Accessibility Act.

For the tester, most mobile accessibility defects come from a few repeating patterns: icon buttons without names, text in fixed sizes, small targets, gesture-only actions and colours that fail in dark mode. A short pass with the screen reader and the system settings on each new screen finds them while they are one-line fixes; after release, the same patterns are spread across every screen of the app.

TalkBack and VoiceOver: what to listen for

TalkBack on Android and VoiceOver on iOS change how touch works. A single tap selects an element and reads it aloud, a double tap anywhere activates the selected element, swiping right or left moves to the next or previous element, and scrolling takes two fingers with TalkBack and three with VoiceOver. Before you switch either one on, set up the accessibility shortcut (holding both volume keys on Android, a triple click of the side or Home button on an iPhone) so that you can switch it off again, and go through the built-in tutorial once.

Then move through each screen from the top, one swipe at a time, and compare what you hear with what you see. Developers set the spoken text through platform properties, such as contentDescription on Android and accessibilityLabel, accessibilityValue and accessibilityTraits on iOS, so most defects come down to one missing or wrong property.

• Name: every control has a short, meaningful accessible name. Icon-only buttons such as plus, minus, heart or share are the most common failure (4.1.2 Name, Role, Value; 1.1.1 Non-text Content for meaningful images).
• Role and state: you hear what the element is (button, switch, checkbox, tab) and its state (on, selected, expanded, disabled), and the state changes when you act.
• Value: after you change a quantity or move a slider, the new value is announced.
• Order and grouping: the swipe order follows the visual and logical order (right to left in Arabic), and a product card is read as one item, not as four fragments.
• Focus and messages: focus moves into a dialog when it opens and back to the control that opened it when it closes, and messages such as "Added to cart" are announced (4.1.3 Status Messages).
• Voice users: with Voice Access on Android or Voice Control on iOS people say the visible label, so the spoken name must contain the visible text (2.5.3 Label in Name).

Touch target size, text size and contrast

WCAG 2.2 sets a floor for targets: 2.5.8 Target Size (Minimum), level AA, asks for at least 24 by 24 CSS pixels, or enough space around a smaller target; 2.5.5 Target Size (Enhanced), level AAA, asks for 44 by 44. The platforms measure in density-independent units, dp on Android and points on iOS, which keep roughly the same physical size on every screen density, and they recommend more: at least 48 × 48 dp on Android, and in Apple’s Human Interface Guidelines a default control size of 44 × 44 points on iOS, with 28 × 28 as the minimum. On a mobile web page laid out at the device width, the browser draws one CSS pixel as one dp on Android or one point on iOS, so the numbers compare directly. Measure the touch area, not the drawn icon: a 24 dp icon with 12 dp of padding on each side has a 48 dp target.

Users who need larger text set it once for the whole phone: the font size setting on Android (up to 200% from Android 14) and Dynamic Type on iOS, whose larger accessibility sizes go beyond 200%. 1.4.4 Resize Text (AA) asks for text that can grow to 200% without loss of content or functionality. Text follows the setting only when the app uses scalable units: sp on Android (dp that also grow with the font size setting) and the Dynamic Type text styles on iOS; text sized in dp or in fixed points stays small. At the largest sizes, look for clipped or truncated labels, overlapping text, buttons pushed off the screen and screens that no longer scroll.

Contrast follows 1.4.3 Contrast (Minimum): 4.5:1 for normal text and 3:1 for large text (at least 18 point, or 14 point bold). WCAG means typographic points, which Understanding WCAG puts at about 24 and 18.5 CSS pixels, so text of 18 dp or 18 iOS points is not yet large by WCAG; Apple’s HIG applies 3:1 from 18 of its own points, so agree with your team which threshold you test against. 1.4.11 Non-text Contrast asks for 3:1 for icons, field borders and the visual state of controls. Measure every screen in light and dark mode: the grey #616161 reaches 6.19:1 on white but only 3.02:1 on the dark background #121212, so a colour that passes in one theme can fail in the other.

Try it: Color Converter

Pointer, gesture and orientation criteria on a touch screen

Guideline 2.5 Input Modalities in WCAG 2.2 was written with touch screens in mind, and the lesson on pointer and motion accessibility teaches its criteria in depth. Screen reader users meet the same problem from another side: with TalkBack or VoiceOver on, a swipe moves the focus instead of reaching the app, so gesture actions must also be offered as accessibility actions, which VoiceOver lists under Actions in its rotor and TalkBack in its actions menu. On a phone, each criterion becomes a concrete test:

• 2.5.1 Pointer Gestures (A): anything done with a multipoint or path-based gesture, such as pinch to zoom, swipe to delete or swipe between cards, can also be done with one finger and no path, such as single taps: plus and minus buttons, a Delete button, next and previous buttons.
• 2.5.7 Dragging Movements (AA): reordering a list, moving a map or moving a slider thumb also works without dragging, for example with move up and move down buttons, pan buttons or a tap on the slider track.
• 2.5.2 Pointer Cancellation (A): the action happens when the finger lifts, not when it touches. Press a button, slide the finger off it and lift: nothing should happen, or the action can be undone afterwards. Standard platform buttons behave this way; custom touch handlers often do not.
• 2.5.4 Motion Actuation (A): a feature triggered by shaking or tilting the phone also has an on-screen control, and the motion response can be turned off so that a tremor or a moving wheelchair does not trigger it.
• 1.3.4 Orientation (AA): screens work in portrait and landscape unless one orientation is essential, as for a piano keyboard app. People with a phone fixed to a wheelchair or bed mount cannot rotate it.

Platform checkers and what they cannot judge

Each platform has a free checker. Android’s Accessibility Scanner app scans the screen you are on and suggests fixes for missing content labels, small touch targets, clickable items and low text and image contrast. Xcode’s Accessibility Inspector shows the label, value and traits of any element of an app running in the iOS Simulator, runs an audit that reports issues such as missing descriptions, small hit regions, low contrast, clipped text and missing Dynamic Type support, and includes a colour contrast calculator. The same kind of checks can run inside UI tests, with AccessibilityChecks.enable() in Espresso and performAccessibilityAudit() in XCUITest.

These tools check rules on one screen state at a time; they do not judge meaning. They find a button with no name, but not a name that is wrong. They cannot tell whether the reading order makes sense, whether a swipe has an alternative, where the focus lands after a dialog closes, or whether a long form still works at the largest text size. Let them catch the mechanical defects early, and spend your manual time on the screen reader pass, the settings and the gesture checks.

Worked example: a cart screen on both platforms

A shopping app’s cart lists products with a quantity stepper (minus and plus icons, where minus stops at 1), removes an item with a swipe to the left and ends with a Checkout button. The tester walks the screen with TalkBack on an Android phone and VoiceOver on an iPhone, repeats the walk at the largest text size and in dark mode, runs the platform checkers and rotates the phone. Each finding is recorded with the criterion or guideline it fails:

• Minus and plus are announced as "button" with no name on both platforms: 4.1.2. Expected: "Decrease quantity, Blue shirt" and "Increase quantity, Blue shirt".
• After a tap on plus, the new quantity is not announced: 4.1.2, because the change does not reach the screen reader.
• Swipe to delete is the only way to remove an item, and the custom swipe is not offered as an action: 2.5.1. Expected: a Remove button in each row, also available as an accessibility action.
• The stepper buttons are 32 × 32 (dp on Android, points on iOS): they meet 2.5.8 but are below Android’s 48 dp and Apple’s 44-point default, and Accessibility Scanner flags them. Reported against the target the team agreed.
• At 200% font size the price is cut off and the Checkout label is truncated: 1.4.4.
• The "Free delivery" note in #616161 passes on white but drops to 3.02:1 in dark mode: 1.4.3, in dark mode only.
• The screen is locked to portrait: 1.3.4, since nothing about a cart needs one orientation.

Try it: Test Case Generator Try it: Pairwise Testing Generator

Frequently asked questions

References

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)The informative explanation of each WCAG 2.2 guideline and success criterion: intent, who benefits, examples and techniques (not normative).
• Test your app's accessibilityAndroid Developers (Google)How to test an Android app's accessibility manually with TalkBack and other services, and automatically with the platform's testing tools.
• Accessibility — Human Interface GuidelinesAppleApple's accessibility design guidance for iOS and other platforms: VoiceOver, Dynamic Type, contrast, touch targets and motion.