Start with the status decision
An order page often uses green, amber and red badges because staff can scan them quickly. The customer, however, needs an answer rather than a palette. Has payment been received? Is stock allocated? Has the parcel actually been handed to a carrier? Is there an action they must take? Write those meanings down before choosing a badge colour. A decorative colour can reinforce a message, but it should never be the only visible signal that distinguishes information or prompts a response. That is the specific concern of WCAG 2.2 success criterion 1.4.1; it is separate from the question of whether two colours have enough contrast.
Make a small status dictionary that is shared by the order page, confirmation email and support screen. Each entry should have a customer-facing label, a plain explanation, the event that permits the state, and the next action. For example, 'Awaiting payment' should not be swapped for 'Paid' merely because a checkout button was pressed. 'Preparing order' should not silently mean 'Dispatched'. If your internal system has finer operational codes, map them deliberately to the few customer states that are accurate. An unclear mapping is a data problem and a writing problem; a bright badge cannot fix it.
Do not treat every status as a traffic light. An amber 'pending' badge could mean the shop is waiting for a bank response, stock, a delivery choice or the customer. Those differences change what the customer should do. If action is required, name it on the same screen: 'Choose a delivery address' or 'Retry payment', with a control that actually performs that action. If the shop is doing the work, say so and explain what update the customer can expect. Avoid an invented deadline if there is no dependable service commitment. This makes the status useful even when all badges render in the same shade.
Pair visual cues with explicit text
Put the status word in the badge itself or immediately beside it, not only in a hover explanation. Hover content is easily missed on touch screens, and a colour swatch with a separate legend forces customers to remember a code. Prefer short labels such as 'Payment pending', 'Preparing' and 'Dispatched', followed by a sentence when the label alone could mislead. A shape or icon may add another visual cue, but check that the shape has a clear meaning and a text equivalent. W3C technique G14 gives text alongside colour as one sufficient example; it is an example, not a mandate to use a particular badge design.
A visual label is only part of the answer. If a screen reader encounters a coloured dot but never hears the status, the information is still absent. Use actual text in the document where possible. If an icon conveys a unique meaning, give it an appropriate accessible name, while avoiding a duplicate spoken phrase when the same label is already adjacent. Test the rendered page, not just the design file, because CSS, icon libraries and component states can change what is exposed. The customer must also be able to understand the action control itself without relying on its green or red styling.
Keep labels stable across views. A support agent who says 'processing' while the customer sees 'confirmed' may accidentally promise that a parcel is moving when it is not. Agree which system event changes the text, and test delays or reversals. If a payment fails after an initial pending state, replace the label with an explicit failure explanation and a safe next action. If dispatch is reversed because the carrier could not accept the parcel, show the new state and a dated update rather than leaving a green 'sent' badge on screen. This is an editorial control as well as an interface control.
Walk through a realistic order
Imagine a customer orders an item for collection. The checkout first says 'Order received; payment awaiting confirmation'. The shop then receives a successful payment event and changes the page to 'Paid; preparing for collection'. When staff actually mark the item ready, the customer sees 'Ready for collection' with the collection instructions. These are example states, not claims about a particular payment service or shop. The important test is whether each transition has evidence and whether the wording describes the event that happened. Colour may help staff scan, but the same journey must work when viewed in greyscale.
Now consider an exception: payment succeeds, but the item cannot be picked for collection. The customer should not see an unexplained red dot. They need a truthful state such as 'Collection delayed; we are checking availability' and an available way to contact the shop. If a refund or alternative item has not yet been agreed, do not describe either as complete. This example shows why a single colour can hide several distinct responsibilities. The same principle applies to a delivery delay or a request for additional address details: label the real condition, identify who acts next and avoid blaming the customer for a shop-side problem.
Review the whole communication chain in both languages. An English label might say 'Ready for pickup' while a Chinese label accidentally says 'Collected'; those are different events. Ask a bilingual reviewer of the copy to compare the actual state, not just grammatical elegance. Check the email subject, body, order detail page, account history and customer-service script. If a compact mobile card shortens the label, confirm that it preserves the same distinction. Status text should remain available when the page is printed or a screenshot is forwarded to a relative who cannot see the original interface.
Test without the colour code
Build a test set from real state transitions, including pending, success, required customer action and an operational exception. For each, remove colour in a screenshot or browser setting and ask someone unfamiliar with the internal codes to state what happened and what they would do next. Then inspect keyboard focus and the spoken output with a screen reader for the status and associated control. This is a practical editorial test, not a substitute for checking other accessibility requirements such as contrast or status announcements. Record the exact label and event that failed so the team can repair the mapping rather than merely recolour the badge.
The release decision is simple: a person who cannot tell the badge colours apart must still be able to identify the current state, its evidence-based meaning and any required action. If they cannot, rewrite the label or explanation, or change when the state appears. Retest in English and Traditional Chinese after a system change, because a new fulfilment code may quietly create a colour-only state. Keep the status dictionary with the product team so new checkout, collection and delivery flows start from the same meanings. This avoids treating accessibility as a one-off visual polish exercise.
Include the channels that are easiest to forget: a compact order-list row, a notification preview, a print layout and a staff-facing screen used to answer a customer call. A coloured dot may be accompanied by words on the full order page but lose them when the same component is reused in a smaller card. Ask the team to trace one sample order through all of these views and compare the actual state label. If the label changes because the layout is narrow, document the approved short form and ensure that it still identifies the event. The goal is a consistent decision for a customer wherever they encounter the status, not a visually identical badge everywhere.
Before you proceed
- Every status has visible words that name its meaning and next action.
- The same state means the same thing in English and Traditional Chinese.
- Greyscale, keyboard and screen-reader checks cover exceptional states too.
