The Monochrome Test: Auditing Colour-Only Status Messages in UK Banking Apps

Status messages are the quiet infrastructure of a banking app. A payment fails, a transfer sits pending, a standing order is amended, a payee is confirmed. Each of these moments depends on the customer recognising what has happened and knowing what to do next. When that recognition rests on colour alone, the interface is asking some customers to guess.

Colour is a useful shorthand, but it is a poor sole carrier of meaning. WCAG 1.4.1, Use of Colour, is unambiguous: colour must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. In a banking context, the stakes are practical rather than theoretical. A customer who cannot distinguish a red failed-payment banner from an amber pending one may retry a payment that has already been sent, or assume a transfer has completed when it has not.

This guide sets out an audit routine for teams that need to test status messages properly. It is written for UK banking apps, but the method applies to any service where money movement and colour coding meet.

Why colour alone is a fragile shorthand

Colour vision deficiency affects a significant proportion of the population, and it is not limited to the familiar red-green confusion. Low vision, monochrome display settings, bright sunlight, privacy screens, and high-contrast modes can all flatten colour differences. A status message that depends on a subtle green tint against a white card is not robust in any of those conditions.

The problem is rarely a single red dot. It is the compound cue: a coloured pill, a coloured icon, a coloured left border, and a label that says only 'Completed'. Remove the colour and the label may still be true, but the difference between 'Completed' and 'Pending' may disappear if both use the same neutral text treatment. The audit must therefore examine the whole status pattern, not just the most obvious badge.

Start with a status inventory, not a screenshot

Before testing individual screens, list the status states the app can express. A useful inventory covers at least: payment sent, payment failed, payment pending, payment reversed, transfer scheduled, transfer cancelled, payee confirmed, payee blocked, standing order amended, Direct Debit cancelled, and card payment authorised. Add any state that changes what the customer can do next.

For each state, record where it appears: transaction list, payment receipt, home-screen banner, notification centre, email confirmation, SMS alert, in-app inbox, and support chat. The same status may be rendered differently across those surfaces, and a design system that passes in one context may fail in another. A green tick in a push notification is not the same artefact as a green tick in a transaction row.

Capture each state in its default, dark-mode, and high-contrast variants if the app supports them. Note the text, icon, colour token, position, and any animation. The inventory becomes the test plan.

The monochrome test and its limits

Monochrome testing is simple and revealing. Set the device to grayscale, or capture screenshots and convert them to grayscale, then ask whether the status remains distinguishable without explanatory notes. If two states become visually identical, the interface has a colour dependency.

Do not stop at grayscale. Colour-blindness simulators can approximate deuteranopia, protanopia, and tritanopia, but they are not a compliance test and they do not replicate low vision, glare, or cognitive load. Use them as a prompt for discussion, not as evidence of success. Where possible, include people with colour vision deficiency in usability testing; their descriptions of what they notice, and what they miss, are more useful than a simulator screenshot.

A practical routine is to test each status message in four conditions: full colour, grayscale, a colour-blindness simulation, and a high-contrast or inverted display mode. Record what remains legible, what remains distinguishable, and what collapses into ambiguity.

Pair every cue with a second channel

The remedy is rarely to remove colour. It is to add a second, non-colour channel. Text is the most reliable. 'Payment failed' is clearer than a red cross, and 'Payment pending' is clearer than an amber clock. Where space is tight, an icon can carry meaning, but only if it is unambiguous and has an accessible name. A red circle with an exclamation mark may be recognisable to some; a red circle alone is not.

Icons and text should agree. A green tick beside the words 'Payment failed' is worse than colour alone because it creates contradictory signals. Audit for consistency between icon, label, colour, and the action offered. If a status message includes a button such as 'Try again' or 'View details', the button should make sense without the colour cue.

Also check the accessible name and live-region behaviour. A status that appears dynamically should be announced by screen readers in a way that includes the status text, not just the colour token. WCAG 4.1.3, Status Messages, is relevant here: the message should be available to assistive technology without requiring focus.

Edge cases that design systems miss

Design systems tend to document the happy path. The awkward cases are where colour-only cues cause the most harm.

A pending transaction that later fails may change colour but keep the same label. A partial payment may show a green element for the successful portion and a red element for the failed portion in the same row. A scheduled transfer may be amber today and green tomorrow, but the word 'Scheduled' may remain unchanged. A reversed payment may look like a refund. A blocked payee may use the same red as a failed payment, inviting the customer to retry something that should not be retried.

Dark mode is another common gap. A red that works on white may lose contrast on a dark background, and a green that reads as positive in one theme may read as muted in another. High-contrast modes can override brand colours entirely, which is helpful for contrast but can remove the only distinction if the design relies on hue.

Notifications deserve separate scrutiny. Push notifications, SMS alerts, and emails often strip icons and rely on a single line of text. If that text says 'Your payment was unsuccessful' the position is sound. If it says 'See app for details' and the app uses colour alone, the notification has merely moved the problem.

A repeatable audit routine

A workable routine has six steps.

1. Inventory the status states and surfaces, as above.
2. Capture evidence in colour, grayscale, simulated colour-blindness, and high-contrast modes.
3. Apply a simple test: cover the colour. Can a new customer still tell what happened and what to do next from text and icon alone?
4. Grade the finding. Treat as critical any status that affects money movement, payee safety, or a required next action and has no non-colour equivalent. Treat as serious any status that is merely decorative but still causes confusion.
5. Record the expected and actual behaviour, the WCAG reference, the device and OS version, and a screenshot. Vague findings are easy to dismiss.
6. Agree a remediation owner and a regression check. If the fix is a new text label, add it to the design system and to the QA script so it does not drift.

Reporting findings without turning them into a colour debate

The most useful audit reports avoid aesthetic argument. They show the state, the evidence, and the consequence. 'In grayscale, the failed and pending states are visually identical; the only difference is hue' is a finding. 'The red is too aggressive' is an opinion.

Where a team cannot add text immediately, a temporary mitigation may be an icon with a clear accessible name and a short label. That is a compromise, not a solution. The audit should say so.

Colour can remain part of the status vocabulary. It should not be the grammar. In UK banking apps, where a single ambiguous status can lead to a duplicated payment or an unresolved concern, the monochrome test is a small routine with a disproportionate return.