Playbook, fintech app
A barrier at verification is not an inconvenience, it is a closed account
On most products an accessibility barrier costs somebody a task. Here it can cost them the account, because nothing works until an identity check completes and the check is usually a camera pointed at a face or a document. Somebody with a tremor, low vision or a screen reader can be stopped at that step permanently, and unless an alternative route is published there is no second way through.
Why this is not the general answer
The handling pattern for accessibility requests holds across every trade. What follows is the part that does not.
- The blocking step is a check rather than a screen, so the usual advice about keyboard order and contrast does not reach it: a capture requiring steady hands and a judgement about lighting is a different kind of barrier.
- Failing the check has consequences no other product has, since an unverified account cannot hold funds, receive a payment or be closed cleanly, which turns an accessibility issue into a money problem within days.
- The assistant must not help anybody get past a verification step, so the ordinary support instinct of offering a workaround collides here with a rule that exists for good reasons, and the only safe route is a published alternative process.
- Statements, notices and fee documents in an alternative format are a separate request with a separate route, and treating it as the same thing leaves somebody waiting for the wrong team.
How it arrives
- i cannot complete the selfie check with my screen reader
- the document scan will not accept my photo and i have low vision
- is there another way to verify without using the camera
- can i get my statements in large print
- do you have an accessibility statement
- my hands shake and the app keeps timing out on the id step
What has to be indexed for this to work
| The alternative verification route, if you have one | What somebody does when the standard capture is not usable: which route to contact, what is asked for instead, and how long it takes. Where no alternative exists, the honest published answer is that it is being worked on, because silence here reads as a refusal to open accounts to certain people. |
|---|---|
| The accessibility statement, with its scope and date | Which parts were assessed, when, and the exceptions you already know about. On a money app the scope must say whether the verification flow was included, since that is the step people are actually stopped at and the one most likely to have been assessed last. |
| Alternative formats for statements, notices and fee documents | Which documents are available in which formats, who to ask, and the timescale. These are the papers people need for a landlord, a claim or an accountant, so a slow route has consequences beyond the request itself. |
| The named destination for an accessibility request | A specific team and a response period. Without one these are answered kindly by whoever is nearest and quietly go nowhere, which in this trade means somebody is left without a working account. |
The reply
If the standard identity check is not usable for you, there is a separate route rather than a trick for getting the capture to work, and it is set out with what to contact and what is asked for instead [1]. I would not suggest a workaround for a verification step even if I knew one, because that is a check we are required to run properly. Statements and notices in alternative formats are requested through the route on the same page [2]. I cannot see your account or test how a screen behaves with your software. Leave your name, an email and which step stopped you, and it goes to the team who handle accessibility.
It names the alternative route first because that is the only thing standing between this person and a working account. Refusing to offer a workaround is stated plainly rather than quietly avoided, so the customer understands the refusal is about the check and not about them. Asking which step stopped them turns a general complaint into something a team can reproduce.
Where it stops
The trigger. Any report of a barrier in the app, any request for an alternative to the standard identity check, and any request for a document in another format.
This needs the team who handle accessibility rather than a page. Leave your name, an email, which step stopped you and what you are using to access the app, and it will go across today. If your account cannot be used at all in the meantime, say that in the message so it is treated accordingly.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never suggest a way to get a rejected identity capture accepted, however practical the suggestion sounds.
- Never claim the app works with a particular screen reader or assistive tool, since that is a test result rather than something a document can support.
- Never claim conformance beyond your own published statement, including saying the app is fully accessible.
- Never treat a barrier as a preference, or offer a workaround as though it had settled the matter.
Questions
- We have no alternative verification route. What should it say?
- That there is currently no published alternative, and then take the details for a person. That is a bad answer and it is better than an improvised one, and the volume of it makes the case for building the route far more effectively than any internal argument will.
- Is it not helpful to give tips for the document photo?
- Publish general capture guidance if you want it published, and let the assistant quote it. What it must never do is respond to a rejection by suggesting what to change, because from a chat box there is no way to tell a customer with a tremor from somebody working through documents that are not theirs.
- Should the widget itself be in scope of the statement?
- Yes. It sits on the same page as everything else you assessed, and a support channel that some customers cannot operate is a poor advertisement for a statement about access. It is also frequently the only route left to somebody the app has already stopped.
Keep reading
- Everything for a fintech appFees, limits and identity checks are safe ground. Balances, transactions and anything reading as a personal recommendation are not.
- Handling accessibility requests in generalTwo different things arrive as one message. A published accessibility statement answers the first. The second is a request, and it needs a person.
- The document exists, and the charge on it cannot be discussed hereStatements, fee breakdowns and tax paperwork on a money app. What the schedule explains, and why no charge on an account can be read.
- Publishable to the decimal point, and unquotable in the same breathMargins, thresholds and free allowances can be quoted exactly. A rate at this minute, and what a conversion costs today, cannot.
- Nothing switches off cleanly while money is still pointed at the accountClosure is not cancelling a subscription: a balance to move, arrangements still pointed at it, and a file that survives it.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.