How to test banking screens with a screen reader

Banking screen reader testing checks whether people using screen readers can understand and operate banking journeys, including authentication, balances, payments and account management. It combines manual testing with assistive technology and targeted automated checks. Testers verify that controls have meaningful names, information is announced in a useful order, and errors or transaction updates are communicated before a customer commits an action.

How to plan banking screen reader testing

Choose the combinations of operating system, browser and screen reader that the bank supports. For example, a desktop web portal might be tested with NVDA and Firefox, while a mobile banking app requires tests with VoiceOver on iOS or TalkBack on Android. Treat each combination as a separate test configuration, and record versions so that failures can be reproduced.

Use a test environment with accounts that represent relevant states: an account with transactions, one with no activity, a payment beneficiary, and a user who can approve a corporate payment if that workflow is in scope. Keep account details and payment destinations controlled. Confirm that test transactions cannot reach real recipients or payment rails.

Define expected behaviour for each journey before testing. The expectation should describe what a customer needs to hear and do, rather than prescribe an exact spoken sentence that may vary by screen reader. Include the accessible name and purpose of each control, the expected reading order, and what should be announced when the page or transaction state changes.

Test a complete banking journey

Start with sign-in. Check that the screen reader announces the page title, identifies the username and password fields, and communicates required input or authentication errors. Test keyboard operation as well as spoken output. For one-time passcodes, verify that instructions explain where the code comes from, how long it remains valid where relevant, and how to recover from an invalid or expired code.

On an account overview, check that account names, account types and balances are distinguishable. A list of several accounts should let a customer identify which balance belongs to which account. For transaction history, verify that dates, descriptions, amounts and debit or credit status remain understandable when read in sequence. Tables need meaningful column and row context; a visual layout alone does not provide that context to a screen reader.

For a payment, test the whole flow from beneficiary selection to review and submission. Check that each field has a clear accessible name and that amount, currency, payee and payment date are announced with enough context to catch mistakes. Validation errors should identify the affected field and describe how to correct it. After submission, verify that the result is announced and that a reference or status is available without requiring the customer to search the page manually.

Pay particular attention to changing content. If a balance refreshes, a payment is processing, or a validation message appears, check that the update is conveyed without unexpectedly moving keyboard focus. Confirm that a loading state does not leave the user waiting without feedback. When a confirmation step is required, test that its purpose is clear and that the customer can review the transaction details before authorising it.

Record and verify findings

A useful defect report includes the tested platform and assistive technology, the account state, reproduction steps, expected announcement and actual announcement. Capture evidence without exposing real customer data. Where recordings are permitted, follow the organisation's privacy and evidence-handling rules.

Automated accessibility checks can identify some issues, such as missing names or certain markup problems. They cannot establish that a payment flow is understandable when read aloud or that a status update arrives at the right point. Use them alongside manual screen reader testing, and confirm fixes by repeating the affected steps with the same configuration.

Worked example: transfer confirmation

Create a test transfer between controlled accounts. Navigate the form using the keyboard and screen reader, enter a valid amount, then review the confirmation page before submitting. Verify that the payee, amount, currency and date are announced clearly, and that the confirmation action has an unambiguous name. Submit the transfer and check that the outcome is announced, the resulting status is available, and no duplicate transfer occurs if the customer returns to the page or retries after a delayed response. Repeat with an invalid amount and confirm that the error is associated with the relevant field and gives a clear correction path.

Link these checks to the relevant accessibility and banking acceptance criteria. A screen reader pass supports evidence for a journey; it does not establish that every screen reader, platform or banking workflow works correctly.