Non-functional

Accessibility testing for banking and finance apps

Accessibility testing checks web and mobile finance apps against WCAG 2.2 Level AA for customers who use screen readers, keyboards, or large text, covering login, one-time codes, card and amount inputs, payments, statements, and balance charts. FintechAssuranceLabs delivers a WCAG 2.2 AA audit report, screen reader test results, a prioritised remediation list, and a retest report.

What accessibility testing covers in finance apps

Sources in this section were checked on 2026-09-16: WCAG 2.2 (W3C Recommendation, updated 12 December 2024) and ETSI EN 301 549 V4.1.1 (2026-09). Legal scope and citation status: EAA and WCAG testing requirements.

Login, one-time codes, and authentication steps with time limits

Session timeout during a payment. SC 2.2.1 Timing Adjustable requires that, for each time limit set by the content, the user can turn it off, adjust it, or extend it after a warning with at least 20 seconds to act, unless the real-time, essential, or 20 hour exception applies. Tests idle on the transfer review screen with a screen reader running and check that the warning is announced, one keyboard action extends the session, and the entered payee and amount survive.
One-time code expiry. The W3C Understanding document for SC 2.2.1 states that time limits for security reasons, such as time-limited two-factor authentication tokens, "can be considered essential, and may be exempt". Where a team relies on that exemption, tests check that the remaining time can be read by the screen reader, the expiry message is announced, and "Resend code" is reachable by keyboard without clearing the form.
3-D Secure challenge. Focus moves into the challenge frame, the frame has an accessible name, the result is announced, and focus returns to the checkout after approval, failure, or a challenge timeout. Functional cases: 3-D Secure challenge flow testing.

Card number and amount inputs

Input purpose. WCAG 2.2 section 7 lists input purposes including cc-number, cc-exp, cc-csc, and transaction-amount. SC 1.3.5 requires the purpose of each input field collecting information about the user to be programmatically determinable when the field serves a listed purpose and the technology supports it. Tests confirm that browser card autofill fills the right fields.
Formatting masks. A card number mask that inserts spaces while typing can move the caret, so the screen reader repeats or drops digits. Tests edit digits mid-number with NVDA and VoiceOver.
Errors. A failed card number check, an unsupported card type, or an amount over the daily limit is described in text (SC 3.3.1). On the web, the message is exposed as a status message that the screen reader announces without moving focus (SC 4.1.3).
Custom amount keypads. Each key has a name and role (SC 4.1.2) and a target of at least 24 by 24 CSS pixels unless an exception such as spacing applies (SC 2.5.8).
Sliders. SC 2.5.7 requires functionality that uses dragging to be achievable by a single pointer without dragging, unless dragging is essential or the user agent determines the functionality and the author has not modified it. Loan amount and term sliders in consumer lending and buy now pay later offers need a text field or step buttons, and the new repayment total is announced.

Statements, PDF disclosures, and balance charts

Transaction lists. Statement tables expose column headers (SC 1.3.1), and debits and credits are distinguishable without colour (SC 1.4.1). At a 320 CSS pixel width (SC 1.4.10), a data table may scroll in two dimensions, while each cell still reflows unless its own content needs two-dimensional layout.
Downloadable PDFs. EN 301 549 V4.1.1 clause 10.0 applies clause 10 to downloadable documents, such as PDF statements, pre-contract credit information, and return copies from tax software. Note 11 of that clause names ISO 14289-1 (PDF/UA-1) and ISO 14289-2 (PDF/UA-2) as the technical standards for accessible PDFs. Tests check tags, reading order, table headers, language, and how screen readers read the amount columns of each template.
Balance and portfolio charts. A chart has a text alternative that serves the same purpose, such as a summary or a data table (SC 1.1.1). Lines and points needed to read the chart reach a 3:1 contrast ratio against adjacent colours (SC 1.4.11), gains and losses do not rely on red and green alone (SC 1.4.1), and each value tooltip is reachable by keyboard (SC 2.1.1). On investing and trading apps, tests also cover the order ticket next to the price chart.
Large text. Text resizes to 200 percent without assistive technology and without loss of content (SC 1.4.4), and Android 14 supports font scaling up to 200 percent. Tests look for truncated balances, fees, and APR values at the largest iOS Dynamic Type and Android font sizes.

Assistive technology and environments

Web flows run with NVDA and JAWS on Windows, VoiceOver on macOS, keyboard only, and 400 percent zoom. App flows run with VoiceOver and TalkBack on real devices against EN 301 549 clause 11, which also covers in-app web views, on the device matrix of mobile app testing. The audit report marks each result as a tool or manual finding.

Segments

Standards

European Accessibility Act, with WCAG 2.2 and EN 301 549

Guides

How to test 3DS2 challenge flows with 3DS test cards

Scenarios

Launching a fintech product in a new jurisdiction

Deliverables

WCAG 2.2 AA audit report
A result for every WCAG 2.2 Level A and AA success criterion per tested screen, PDF template, and app version, mapped to EN 301 549 clauses 9, 10, and 11, with the failing element and reproduction steps, for the product owner and the compliance lead.
Screen reader test results for payment and onboarding flows
Step-by-step results for sign-up, login, one-time code entry, card entry, transfers, and payment approval with VoiceOver, TalkBack, NVDA, and JAWS, including the spoken output and every step a screen reader user could not complete, for the engineering lead.
Prioritised remediation list
A ticket-ready list of accessibility defects ranked by whether a customer can still complete login, onboarding, or a payment, each with the WCAG 2.2 success criterion, the affected component, and a suggested fix, for the engineering lead.
Retest report
The result of rerunning each failed WCAG 2.2 check and screen reader step on the fixed build, with the build number, pass or fail per defect, and any new defect found, as evidence for the compliance lead and the release manager.

How accessibility testing fits your release process

Baseline audit. Scope lists the flows, the screens and pages per flow, the PDF templates, and the app and browser versions, and the audit report records the WCAG and EN 301 549 versions used. Test users hold synthetic accounts, cards, statements, and transaction histories in your staging environment, so no real account data appears in screen reader transcripts or screen recordings.

On every pull request. Automated rule checks such as axe-core run against design system components and the login, card entry, and transfer pages in your CI. A new violation on those pages fails the build. The checks run inside your pipeline, and test automation can build them if you have no UI test harness yet.

Before each release. A manual regression pass repeats the screen reader and keyboard runs for flows whose components changed, plus the session timeout and one-time code cases. Rule engines cannot tell whether a timeout warning is announced before the session ends, so these cases stay manual. The pass updates the screen reader test results for the release.

When a template or chart changes. A new statement template, disclosure PDF, or chart library version triggers the clause 10 PDF checks or the chart checks before it reaches production.

After fixes. Each item on the prioritised remediation list is retested on the build that carries the fix. The retest report names the build and the result per defect.

Handover and ownership. The remediation list goes into your tracker as tickets with the success criterion, the EN 301 549 clause, and the component. Rule check configuration lives in your repository, and reports and transcripts go to your shared evidence folder. The audit report is test input to the accessibility information you publish and to your own conformity decision; it is not a conformity assessment. Your team owns the fixes, design system changes, the published accessibility information, any disproportionate burden assessment, and the release decision.

Sample deliverable

Sample, synthetic data

consent and disclosure test reportConsent and disclosure test report: child accounts, debt validation notices, money transfers, instalment loans, and insurance sales

Consent and disclosure test report: child accounts, debt validation notices, money transfers, instalment loans, and insurance sales
Check ID	Flow	Requirement reference	What the test checked	Evidence file	Result
CD-01	Family banking: parent adds a child profile in the mobile app	COPPA Rule, 16 CFR 312.5(a)(1): an operator is required to obtain verifiable parental consent before any collection, use, or disclosure of personal information from children	The app sends no child name, date of birth, or photo to the backend before the parent completes a card transaction consent under 16 CFR 312.5(b)(2)(ii)	CD-01_coppa-312.5-a-1_request-capture.har	Passed: 6 of 6 test cases, and no request before the consent record contains a child field
CD-02	Family banking: EU teen account sign-up in the mobile app	GDPR, Regulation (EU) 2016/679, Article 8(1): where consent under Article 6(1)(a) applies to information society services offered directly to a child, processing of the personal data of a child below 16, or below a lower Member State age that is not below 13, is lawful only if and to the extent that the holder of parental responsibility gives or authorises consent	Test users one year below and at the configured age for each Member State in scope are routed to parental consent below that age and to their own consent at that age, and the age configuration rejects a value below 13	CD-02_gdpr-art8-1_age-routing-per-member-state.csv	Passed: 15 of 15 test cases, 14 for age routing across 7 Member State configurations and 1 for the minimum age rule
CD-03	Debt collection: electronic validation notice generation	Regulation F, 12 CFR 1006.34(c)(2)(viii): a debt collector must provide an itemization of the current amount of the debt reflecting interest, fees, payments, and credits since the itemization date	For a synthetic account, 1,200.00 XTS on the itemization date plus 36.00 XTS interest and 25.00 XTS fees minus 150.00 XTS payments equals the 1,111.00 XTS current amount on the notice	CD-03_regf-1006.34-c-2-viii_itemization-recalc.csv	Passed: 5 of 5 test cases, including an account with a payment credited after the itemization date
CD-04	Debt collection: validation period end date on the notice	Regulation F, 12 CFR 1006.34(c)(3)(i): the notice must state the date the debt collector will consider the end of the validation period, and 12 CFR 1006.34(b)(5) ends that period 30 days after the consumer receives the notice or is assumed to receive it on a date at least five days after it is provided, excluding legal public holidays, Saturdays, and Sundays	A notice provided on 2026-11-23 has an assumed receipt date no earlier than 2026-12-01, because 2026-11-26 is Thanksgiving Day, so the stated end date is no earlier than 2026-12-31	CD-04_regf-1006.34-c-3-i_end-date-holiday-calendar.pdf	Failed: the notice states 2026-12-30 because the business day calendar omits Thanksgiving Day, defect DEF-214, high severity, release blocker
CD-05	International transfer: review screen before payment in the mobile app	Regulation E, 12 CFR 1005.31(b)(1)(iv): a remittance transfer provider must disclose the exchange rate used for the transfer, rounded consistently for each currency to no fewer than two and no more than four decimal places, using the term Exchange Rate or a substantially similar term	The Android and iOS review screens show the rate for each of 4 test corridors with the same rounding per currency, between two and four decimal places, under the label Exchange Rate	CD-05_rege-1005.31-b-1-iv_rate-display-per-corridor.pdf	Failed: one corridor shows the rate with six decimal places on Android, defect DEF-221, medium severity, fix before release after DEF-214
CD-06	International transfer: order of disclosure and payment steps	Regulation E, 12 CFR 1005.31(e)(1): except as provided in 12 CFR 1005.36(a), the pre-payment disclosure must be provided to the sender when the sender requests the remittance transfer, but prior to payment for the transfer	The pre-payment disclosure renders before the payment step on web, Android, and iOS, and a deep link that opens the payment step directly returns the sender to the disclosure	CD-06_rege-1005.31-e-1_step-order-per-channel.mp4	Passed: 9 of 9 test cases
CD-07	Buy now pay later: loan agreement screen for a 12-month plan with a finance charge	Regulation Z, 12 CFR 1026.18(e): the creditor shall disclose the annual percentage rate, using that term, and 12 CFR 1026.22(a)(2) treats the rate as accurate if it is not more than 1/8 of 1 percentage point above or below the rate determined under 12 CFR 1026.22(a)(1)	The APR on the agreement for 1,000.00 XTS financed and 12 monthly payments of 90.00 XTS matches an independent actuarial reference model within the 1/8 point tolerance	CD-07_regz-1026.18-e_apr-reference-model.xlsx	Passed: disclosed APR 14.45%, reference model 14.4521%
CD-08	Insurance: renters policy purchase in the mobile app, EU market	Insurance Distribution Directive (EU) 2016/97, Article 20(5): for non-life insurance products listed in Annex I to Directive 2009/138/EC, the information in Article 20(4), due prior to the conclusion of a contract, shall be provided by way of a standardised insurance product information document on paper or on another durable medium	Before the buy step, the app offers a downloadable PDF with the title required by Article 20(7)(f) and the items listed in Article 20(8)(a) to (i)	CD-08_idd-art20-5_blocked-run-log.txt	Blocked: the staging document service returns HTTP 503, and the check reruns after the service stub is deployed

Amounts use XTS, the ISO 4217 code reserved for testing; accounts, corridors, dates, defect IDs, and evidence file names belong to a fictional release, and no real child, parent, or consumer appears.

Questions

What is accessibility testing?

Accessibility testing checks whether people with disabilities can use a product with assistive technology such as screen readers, keyboard navigation, magnification, and large text. For a finance app, accessibility testing measures each screen against WCAG 2.2 success criteria and runs login, onboarding, and payment flows with VoiceOver, TalkBack, NVDA, or JAWS to find the steps a customer cannot complete.

How to perform accessibility testing?

To perform accessibility testing, choose the flows that carry money or identity, such as login, onboarding, and payments. Run automated rule checks on each screen, then test each flow by hand with a keyboard, a screen reader, text at 200 percent, and a 320 CSS pixel wide viewport. Record each failure against its WCAG 2.2 success criterion and retest after the fix.

Why is accessibility testing important?

Accessibility testing is important because a customer who cannot finish login, a transfer, or a loan application with assistive technology cannot use the financial service at all. In the EU, Directive (EU) 2019/882, the European Accessibility Act, sets accessibility requirements for consumer banking and e-commerce services provided to consumers after 28 June 2025, and Member States set the penalties.

Scope your accessibility testing

Send the flows in scope, supported browsers and app versions, your PDF statement and disclosure templates, and your release dates, and we return a test scope for the four deliverables.

Scope your testing