Accessibility — Bilingual, RTL & Regulatory Comprehension

In banking, accessibility is usually scoped to contrast ratios and screen readers. That scope is too narrow for a regulated onboarding journey, and treating it narrowly is how banks end up with products that are technically conformant and practically unusable. My working definition: a customer cannot give informed consent to something they cannot read. Everything below follows from that. This is not a softening of the standard — it sits inside it. WCAG's Understandable principle covers reading level, unfamiliar terminology, and error prevention on legal and financial commitments. Those success criteria are the ones that actually bite in a KYC journey, and they are the ones most often skipped.

I proposed Arabic-first for the Egypt journey. It was rejected — the decision-makers sat in Dubai and could not review Arabic. I proposed letting the customer switch language anywhere in the journey. That was rejected too, on real technical grounds: free-text answers would have to be reconciled across two languages. So I stopped arguing about language and started arguing about consent. In a branch, the officer reads the FATCA and sanctions questions aloud in Arabic, interprets them, and often answers on the customer's behalf. The customer then signs — usually without reading. A human was supplying the comprehension. Removing that human from a digital journey does not remove the bank's obligation; it transfers it to the interface. Framed as a preference, the request loses to development cost. Framed as informed consent, it becomes something nobody in the room can comfortably vote against. That reframing is what carried the decision — the technical argument only proved it was affordable.

Every screen in the journey has a full right-to-left counterpart. The layout mirrors: the progress stepper reverses, the guidance rail moves to the opposite side, navigation and directional icons flip, the composition inverts. The same FATCA declaration in both directions. Parity extends to every state — filled, empty, error, multi-entry — not to a selected set of hero screens. What deliberately stays in English: the declaration answers themselves. FATCA is filed with a foreign authority in the customer's own words, so the answers are English by requirement regardless of interface language. Recognising that is what made the switch cheap enough to build.

Explanation of a regulatory term, available in either language, switched in place without losing position — and in both directions, which matters for the foreign resident who handles everyday Arabic but wants sanctions questions in English. In testing, five of ten participants began in English. Nearly all of them switched to Arabic at exactly this step. The same behaviour was reported again after the controlled release.

Eight of ten tested participants did not understand FATCA or PEP terminology. About two of ten had real working knowledge of it. Almost all of them already held accounts at several banks — so this was never financial literacy. They had answered these questions before, out loud, to someone who translated them. The response was contextual explanation at the point of the question rather than a help centre, and terminology rewritten for comprehension rather than reproduced from the compliance form.

Validation designed to stop the error rather than report it, with messages that survive translation and mirroring. Error states have full RTL counterparts — they are the states most often left behind in a bilingual build, and the ones a stressed customer is most likely to meet.

About ninety per cent of what the journey needs is read from the customer's documents rather than from their fingers. This is the single largest accessibility decision in the whole journey, because typing is the highest-friction and most error-prone act in any form: for someone with a motor impairment, for someone who reads either language with difficulty, or simply for someone using a phone keyboard on a moving bus. Removing the typing removes the barrier and the error class together. It is also the single largest decision for reducing journey time — one decision serving both goals.

Seven of ten tested participants paused and returned in a later session. The journey is staged rather than continuous, each stage cognitively bounded, with a review structure that holds sections separately and editably so returning does not mean restarting.

Mashreq runs one shared design system across Egypt, the UAE and Pakistan, owned by a separate team. When I joined, it supported left-to-right only — so early Arabic work meant flipping components by hand, screen by screen. I raised RTL support as a system requirement rather than a project workaround. The system was later updated to support both directions, and most of the components that entered it with RTL support came from our work. I contributed components directly — the meeting-location selection card, the accordion, and the RTL variants — which the system team reviewed and absorbed. I do not own that design system. I contributed to it, and the distinction matters: the accessibility gain was durable because it landed in the shared layer, not in my files.

I tested this journey myself, screen by screen, as part of my own design QA pass — keyboard-only walkthroughs, zoom, error states in both languages. What follows is the honest ledger: each practice, the WCAG criterion it maps to, and how it was verified. What was not done, stated plainly: no formal conformance audit was commissioned, and the journey was not tested with a screen reader (NVDA, JAWS, VoiceOver). The accessible names are in place for it; the assistive-technology pass itself did not happen. So the accurate claim is: designed against WCAG 2.1 AA, self-tested for keyboard, zoom, errors and timing — not certified, and not screen-reader-verified. That sentence survives any interview. A certification claim without an audit behind it does not.

What Mashreq shares across Egypt, the UAE and Pakistan is closer to a UI component library than a full design system: it provides the components and their visual states, but not the usage rules — when a button should be disabled, how an error must be voiced, where a summary banner belongs. That governance layer is the part I have publicly argued it lacks. Which means every behavioural decision above — the three-signal error pattern, the focus behaviour, the disabled-state logic — was made by me, per screen, and held consistent across six systems and two languages without a written rule to lean on. The consistency was manufactured, not inherited. I contributed components back — the meeting-location card, the accordion, the RTL variants — and the system team reviewed and absorbed them.

The accessibility work here was not an overlay added at the end. It was the argument that decided the product's language architecture, and it is the reason the journey survives its own hardest step. The general principle I took from it: when a digital journey removes a person, it inherits that person's job. The branch officer was an accessibility feature. Everything I built was an attempt to replace what they were quietly doing.