Banking application accessibility testing evaluates whether customers with disabilities can use banking websites and mobile apps to complete essential tasks with assistive technology and accessible interaction methods. It checks the interface against the organisation's chosen Web Content Accessibility Guidelines (WCAG) version and tests real journeys such as signing in, reviewing balances and making payments, including errors and security checks.
How to test accessibility in banking applications
Start by identifying the applications, platforms and customer journeys in scope. Include web and native mobile experiences, supported browsers and operating systems, and any third-party identity or payment screens. Confirm the WCAG version and conformance level the project is targeting. Accessibility obligations vary by jurisdiction, so testing criteria should reflect the bank's applicable requirements rather than assume one universal standard.
Prioritise journeys by customer impact. A useful initial set includes account opening, authentication, balance and statement access, adding a beneficiary, transferring money, card controls and support. Map each journey's normal path and important failure states. A transfer that works with a mouse but traps keyboard focus at confirmation remains inaccessible.
Combine automated checks with manual testing
Run accessibility analysis tools against representative pages and states. These can detect some issues, such as missing accessible names, invalid attributes, certain contrast failures and structural problems. Review each finding: automated results can include false positives, and a clean scan does not establish that a journey is usable or conforms to WCAG.
Test with a keyboard, without a mouse. Check that focus follows a logical order, remains visible, reaches every control and can leave dialogs and menus. Confirm that focus moves appropriately after actions such as opening a modal or displaying a validation error. Test zoom and text resizing, page reflow, contrast, visible focus indicators and touch interaction on mobile. Check that instructions and status messages do not rely on colour alone.
Use screen readers with the supported browser and operating-system combinations. Check that headings, landmarks, form labels, button names, input requirements and error messages are announced clearly. Dynamic updates, such as a changed transfer total or a payment status, may need suitable semantics and focus handling so that users receive the update without losing their place. Test magnification and speech input where relevant to the intended user groups.
Treat authentication as part of the journey. Test password managers, one-time passcodes, biometric prompts and multi-factor authentication using supported assistive technologies. Check that a code can be entered without unnecessary time pressure, errors are explained, and users can recover from a failed step. Preserve the bank's security controls in the test environment; accessibility testing should not depend on bypassing authentication.
Check banking-specific risks and dependencies
A journey may cross the bank's interface, an identity provider, a payment service or a device-level prompt. Record which component owns each defect and test the integrated experience as well as the bank-controlled screens. Differences between production-like and test environments, including unavailable authentication services or changed content, can hide failures.
Use synthetic accounts and transactions with known permissions and balances. Avoid exposing customer data in screenshots, logs or test reports. Confirm that test data covers relevant account types and transaction states, and reset it safely between runs. Also test session expiry, rejected payments and service errors: customers need to understand what happened and what action is available without relying on visual cues.
Automated checks fit well in continuous integration (CI) for repeatable page-level checks. Manual keyboard and assistive technology testing remains necessary for interaction, meaning and task completion. Track defects against the affected journey, platform, assistive technology and relevant accessibility criterion so teams can reproduce and retest them.
Worked example: making a transfer
Test a transfer using a keyboard and a screen reader:
- Sign in through the approved test authentication flow, then move to transfers using keyboard navigation.
- Choose a test beneficiary, enter an amount and review the accessible names and instructions for each field.
- Enter an invalid amount. Confirm the error identifies the field, explains the problem and is announced; check that focus moves or remains where the user can respond.
- Correct the amount, continue to review, and verify the payee, amount and date are available to assistive technology before confirmation.
- Submit the transfer and check that the resulting status is announced and recorded accurately. Repeat with a rejected or unavailable service response to verify the recovery path.
Record the browser or device, assistive technology, test data, expected result and observed result. Retest the full journey after a fix, since a change to labels or focus management can affect later steps.
Frequently asked questions
Can an automated accessibility scan certify a banking application?
No. Automated scans identify some detectable issues, but they cannot confirm that every control makes sense, that a complete banking journey works with assistive technology, or that all applicable criteria are met. Use them alongside manual testing and an agreed conformance assessment.
How should teams test a banking CAPTCHA accessibly?
Test whether the CAPTCHA offers an accessible way to complete the challenge and whether its instructions, controls and failure messages work with keyboard and assistive technology. Verify the complete recovery path in the real authentication flow, and assess whether the challenge can be avoided or replaced without weakening required security controls.
Should accessibility testing include PDF bank statements?
Yes, when customers access statements as part of the banking service. Check that documents have meaningful structure, selectable text, correct reading order, labelled tables and accessible form fields where applicable. Test the delivered file with relevant assistive technology, since an accessible account page does not make its downloaded documents accessible.
How can teams keep accessibility evidence safe?
Use synthetic customer records and transactions, restrict access to test evidence, and redact personal or authentication data from screenshots and logs. Store only the information needed to reproduce and retest a defect, following the bank's data-handling controls.