Can a screen reader user log in and pay in your mobile app?

Sources checked on 9 November 2026.

This guide is for a product owner, CTO or ecommerce lead who wants to check whether a customer with a disability can complete a purchase in the app. It describes a test method, not the result of auditing a specific app.

Login and payment are where a single barrier stops the whole journey: an unlabelled button, a code to transcribe with no way to paste it and no other method, an error shown only in colour, or a time limit that ends the session. Since 28 June 2025 the European Accessibility Act has covered services including ecommerce. See the European Accessibility Act — European Commission. This article is not legal advice; the scope of obligations is assessed separately.

WCAG 2.2 was written mainly for web content, but its criteria are widely used as a reference for mobile apps too. Full text: WCAG 2.2 — W3C. The list below is not complete; it highlights criteria that can decide whether a purchase can be completed. The descriptions are summaries; the exact conditions and exceptions in the W3C documents apply.

One especially relevant criterion is authentication without a cognitive function test, described in Accessible Authentication (Minimum) — W3C.

Another is minimum touch target size, described in Target Size (Minimum) — W3C.

• 1.1.1 Non-text Content: icons and image buttons have a name the screen reader announces.
• 1.4.4 Resize Text: in web content, text can be resized up to 200% without assistive technology and without loss of content or functionality (except captions and images of text). In an app, treat this as a practical reference point for system text size.
• 2.2.1 Timing Adjustable: for each time limit, the user can turn it off or adjust it (over a range of at least ten times the default) before encountering it, or is warned before time expires and given at least 20 seconds to extend it with a simple action, at least ten times. The exceptions are narrow: the limit is a required part of a real-time event (such as an auction) and no alternative is possible, the limit is essential and extending it would invalidate the activity, or the limit is longer than 20 hours.
• 2.5.8 Target Size (Minimum): in web content, a target is at least 24 by 24 CSS pixels or has enough spacing from other targets; the criterion also has exceptions (e.g. an equivalent target, inline text, user agent controls, essential cases). In an app, treat this as a practical reference point.
• 3.3.1 Error Identification: errors are described in text, not only in colour.
• 3.3.8 Accessible Authentication (Minimum): no step of authentication requires a cognitive function test (such as remembering a password, transcribing a code or solving a puzzle) unless an alternative method without such a test or a mechanism to assist, such as pasting or a password manager, is available. A test that asks the user to recognise objects, or to identify non-text content (such as a photo) the user previously provided, is also an exception.
• 4.1.3 Status Messages: messages such as “payment in progress” or “card declined” are announced without moving focus.

A simulator or automated tool helps, but it cannot replace walking the path with a screen reader on a real phone. Android describes combining manual and automated testing in Accessibility testing — Android Developers.

Screen reader basics on iOS: VoiceOver — Apple Developer.

Screen reader basics on Android: TalkBack — Google Help.

If the app is built with React Native, component accessibility properties are described in Accessibility — React Native.

1. At least one iPhone with VoiceOver and one Android phone with TalkBack, on versions your customers use.
2. A test account and a test payment environment so the full path can be completed without a real transaction.
3. The largest system text size and bold text enabled.
4. A list of the path's steps from opening the app to the order confirmation.
5. A recording method: a screen recording with the screen reader audio and a short note for each issue.

Complete login using only screen reader gestures, without looking at the screen. At each step, note what the screen reader announces and compare it with what the user needs.

1. Fields: do the email, phone and password fields have clear names, not just a placeholder that disappears once typing starts?
2. Password managers and pasting: can the user paste a password or code and use system autofill?
3. One-time code: can an SMS or email code be pasted or filled in automatically, rather than transcribed from memory?
4. Biometric login: is there an alternative for people who cannot use it?
5. Login error: does the screen reader announce what went wrong and what to do next?
6. CAPTCHA or similar checks: is there a variant that does not require recognising images or solving puzzles?

Payment can combine app screens with payment provider components and additional bank authentication. Test the whole flow, because the user cannot see where one system ends and the next begins.

Pay particular attention to the hand-off to the payment provider's form and the return to the app: does the screen reader focus land somewhere sensible, and is the payment result announced?

1. Basket: are the product name, quantity, price and remove button read together in a clear order?
2. Changing quantity: does the screen reader announce the new quantity and total after a change?
3. Delivery details: do fields have names, and are required fields marked by more than an asterisk or colour?
4. Payment method: is the selected option announced as selected?
5. Card form or redirect: do the payment provider component and the bank screen work with the screen reader?
6. Payment result: are success and decline announced, and after a decline does the user know how to try again?
7. Confirmation: can the order number and key details be read and saved?

Walk the whole path again with the largest system text size. Check that the pay button does not disappear off screen, prices are not truncated and every field can be scrolled to. On iOS, text scaling is described in Scaling fonts automatically — Apple Developer.

Also check button size and spacing, especially for adjacent actions such as “Pay”, “Cancel” and “Change”. If a payment session or code expires, establish whether the user is warned and can extend the time. The criterion is described in Timing Adjustable — W3C.

Fix what prevents a purchase first. Issues that make the path harder but do not block it go on the next list. Record the observation rather than jumping to a technical solution.

This script checks the most important path, but it does not replace a full accessibility audit or a legal assessment. Know its limits before the result feeds into a decision.

If the test reveals many issues in an older app, the guide repair, modernise or rewrite a mobile app may help.

• Other app screens such as search, account or returns.
• All assistive technologies, for example switch or voice control.
• Third-party provider components in every configuration customers may have.
• Assessment of legal compliance and the documentation required of the business.
• Testing with people with disabilities, which can reveal issues the team does not see.