Can customers follow instructions without seeing where a control sits?

Identify the action, not the location

A sentence such as 'press the green button on the right' sounds clear to a writer who sees the desktop layout. It may fail when a mobile page stacks the buttons, a customer enlarges the screen, a screen reader presents a different reading order, or the colour is hard to perceive. W3C's WCAG 2.2 criterion 1.3.3 says instructions for understanding and operating content must not rely solely on sensory characteristics such as shape, colour, size, visual location, orientation or sound. The word 'solely' matters: a position hint can remain useful if the instruction also names the control or its purpose.

Begin with a verb and an exact label that exists on the interface. 'Choose Collection method, then select Store pickup' survives a rearranged screen better than 'tap the lower tile'. If a button reads 'Continue to payment', call it that in the instruction. Do not write 'Submit' in the help text when the interface says 'Continue'; the mismatch makes customers wonder whether they have reached the right step. For icon-only controls, first ask whether the icon can gain a visible text label. An invisible accessible name helps a screen reader user, but visible words also help people who cannot interpret the icon.

Inventory the instructions most likely to affect a customer's decision: checkout, booking, account recovery, forms and help messages. Record the exact sentence, the control it refers to and the screen sizes where it appears. Search for clues such as 'above', 'below', 'left', 'round', 'red', 'large', 'beep' and their Chinese equivalents, but do not automatically delete every occurrence. 'See the section below' can be meaningful when the referenced section follows in reading order. The problem is an instruction that cannot identify its target without the sensory clue. Assess the actual relationship, then rewrite only what needs a clearer anchor.

Rewrite without losing useful visual cues

Suppose a booking form says, 'Select the blue box on the left for a morning appointment.' If the actual option has a visible label 'Morning', write 'Choose Morning under Appointment time'; you can add 'shown in blue' only as a secondary cue if that remains accurate. If the option is merely a blue rectangle with no name, the interface needs repair as well as the instruction. A sentence cannot reliably point to a nameless control across keyboard, touch and assistive technology. This decision is also commercial: the customer should know which appointment they are reserving before committing.

Sound cues deserve the same check. 'After the beep, enter your code' is insufficient if the sound is muted or unavailable. Pair it with an observable state such as 'When the verification code field appears, enter the code'. If a kiosk uses a physical key whose tactile shape is the only identifier, web guidance alone does not describe the whole physical experience; still give the on-screen instruction a name, printed marking or equivalent reference that the customer can find. Do not claim that any specific kiosk is compliant just because its web page uses better words.

W3C's forms guidance says instructions should tell users about required and optional input, formats and other relevant information, and warns that instructions must be available in a way assistive technology can read. Put a short instruction near the task and connect field-specific help to its field in the implemented form. A long page of generic directions above the checkout may be technically visible yet hard to use when the customer reaches the control. Keep the language concrete: 'Enter the mobile number that can receive delivery updates' answers a different question from 'enter the number on the right'.

A useful repair exercise is to hide the visual styling and read an instruction aloud without showing the page. If a colleague cannot name the target from the sentence, add the field or button label. Then compare that label with what the rendered control exposes to a screen reader. This two-pass check catches a common split: the help says 'Select delivery speed' but the control is named only 'Option 2'. The customer may understand the prose yet still be unable to act. Fix the control and wording together, and keep both English and Chinese labels semantically aligned even if their word order differs.

For multi-step journeys, identify the state as well as the control. 'Select Confirm' can be unsafe if the same word appears for confirming a delivery address and then confirming payment. Say 'On the delivery review step, select Confirm address' and ensure that the page actually uses that button name. If the page cannot support a more precise label, change the button. Explain when an action commits the customer and when it merely moves to another review screen. This distinction is particularly valuable when assistance is given over the phone, because the agent cannot rely on pointing to the customer's screen. A clear instruction becomes a shared map of the journey.

Test a booking journey

Consider a customer choosing a consultation slot. The page first asks for service type, then a date, then a time. A weak instruction says 'click the calendar icon at the far right and pick one of the grey boxes'. A stronger version says 'In Appointment date, open the date picker and choose an available date; then choose an available time under Appointment time'. This example describes a hypothetical flow, not a particular vendor. The stronger text names the sequence and both controls; it remains meaningful if the calendar icon changes or the boxes move. The site must still make disabled dates identifiable and the date picker operable.

Check the same journey at narrow width, large text and in both languages. Chinese labels may become longer and wrap differently, so a sentence based on 'the button beside the date' can become wrong even when the English desktop view still looks fine. Ask a tester who has not seen the original design to follow only the written directions with a keyboard. Observe whether they can find the named control, understand the result and recover from a wrong choice. Then listen to the control names and help in reading order with a screen reader. A passing screenshot is not evidence that the rendered form communicates the instruction.

Keep instructions aligned with the interface

When a product team renames a button, it should update in-page help, email directions, customer-service scripts and both language editions together. A content checklist can pair each instruction with the current control label and owner. On release, verify the instruction before and after any conditional step: a delivery choice might reveal new fields, or a payment method might change the final action label. Do not let a translation team guess which new label corresponds to an old spatial description. Give translators a screenshot or working journey and the intended action, then verify the final rendered copy.

The acceptance question is whether a customer who cannot use the described colour, shape, sound or screen position can still identify the intended control and finish the task. If the answer is no, improve the control name or the instruction and repeat the journey test. Keep genuinely useful location hints only after the named action is clear. This produces copy that remains reliable through responsive layout changes and bilingual edits, and it gives customer support a phrase they can repeat without asking a caller to locate 'the round thing on the left'.