Search topics
Instructions that rely on colour, shape or position
A checkout tells people to press the green arrow on the right, but the button has no visible words, a screen reader never says its colour, shape or place, and on a phone it is no longer on the right.
<p>…press the green arrow on the right.</p> The problem
People who can't see the screen, or who see a different layout, can't tell which control an instruction means.
A grocery shop's checkout has a delivery step. Under the heading, one sentence tells people what to do: "Choose a delivery slot, then press the green arrow on the right." Below it are three delivery slots as radio buttons, and at the bottom of the step a "Back to basket" link on the left and a round green button with a white arrow on the right. The button has no words on it. In code it is named "Continue to payment".
On a wide screen, a sighted reader finds the arrow at once. A screen reader user hears the sentence, then the slots, then "Back to basket, link" and "Continue to payment, button". Nothing they hear is green, an arrow, or on the right. On a phone, the step's buttons stack into a column, the arrow under the link on the left, and the sentence is wrong for everyone.
WCAG 1.3.3 says instructions must not rely solely on sensory characteristics: shape, colour, size, visual location, orientation or sound. This instruction identifies the button by its colour, its shape and its place on the screen, and by nothing else. That is failure F14, identifying content only by its shape or location. The criterion doesn't ban those words. It asks for something beside them that doesn't depend on seeing or hearing, and the usual something is the control's name. Technique G96 gives the pattern: "press the round go button" works because "go" is there too.
The same failure takes other forms on shop and account pages, each relying on a different sense:
- Colour: "Slots in green are still available" or "Fields in red are required", with nothing else marking them.
- Shape: "Items marked with a leaf ship in reusable packaging", where the leaf is an icon with no text (F26, a graphical symbol alone).
- Size: "Use the larger box for your full address."
- Position: "Use the menu in the top corner" or "Details are in the sidebar", which the layout moves on a phone.
- Sound: "When you hear the chime, your slot is held", with no message on screen.
The failure is often invisible to the people who write the instruction, because on their screen it is true. It breaks for anyone who doesn't get the same picture: a different sense, a different screen width, a different zoom level, or a translation into a language that runs from right to left.
5 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision A screen reader reads the sentence, then lists a link called Back to basket and a button called Continue to payment. Neither is said to be green, an arrow or on the right, so the instruction points at nothing.
- Limited manipulation Voice control users act by saying a control's name. "Click green arrow" matches nothing, and the button shows no words to say instead.
- Limited vision With a magnifier, only part of the step is in view at a time, so "on the right" may be off-screen, and on a phone or at high zoom the arrow is not on the right at all.
- Without perception of colour People who can't tell green from other colours get no help from "green", and are left with the shape and a position that may be wrong.
- Limited language, cognitive and learning abilities People who mix up left and right, or who don't read an arrow as "continue", have to guess, and the guess may be the link back to the basket.
No rule can decide whether a sentence relies only on sensory words. "Press the green Continue to payment button" is fine, and "press the green arrow" is not, but both contain a colour and a verb. The audit finds sentences that pair a sensory word with an instruction, in English and Japanese, and passes each one to a person or the AI review as a lead. It can't check that a position word is still true at every breakpoint, that an icon is explained somewhere, or that a sound has a visible message. AI-generated copy tends to describe what the designer sees ("tap the blue button below"), because the mock-up is all it was given.
Try it
Read the instruction, then find the button it means. Turn on Phone width and read it again.
The panel under the page shows what a screen reader reads, in order. Which of those is the green arrow on the right?
Broken Can you fix this?
Step 2 of 3
Delivery
Choose a delivery slot, then press the green arrow on the right.
Reading the step from the top, a screen reader says:
- Delivery, heading level 2
- Choose a delivery slot, then press the green arrow on the right.
- Delivery slot, group, Tuesday, 10:00 to 12:00, radio button, checked
- Back to basket, link
- Continue to payment, button
The fix
Name the control in the instruction, by the words it shows or its accessible name, and keep any visual description true at every width.
- 1Every instruction names the control it means, by its visible text or its accessible name.
- 2Colour, shape, size, position and sound may help, but only beside that name.
- 3Drop position words that change with the layout, except above and below in reading order.
<h2>Delivery</h2><p>Choose a delivery slot, then press the green arrow on the right.</p><fieldset> <legend>Delivery slot</legend> …</fieldset><div class="step-actions"> <a href="/basket">Back to basket</a> <button type="submit" class="next" aria-label="Continue to payment"> <svg aria-hidden="true" focusable="false">…</svg> </button></div>Words on the button, quoted in the instruction
<h2>Delivery</h2><p>Choose a delivery slot, then press Continue to payment.</p><fieldset> <legend>Delivery slot</legend> …</fieldset><div class="step-actions"> <a href="/basket">Back to basket</a> <button type="submit" class="next"> Continue to payment <svg aria-hidden="true" focusable="false">…</svg> </button></div>Why this fix: Point to a control by the words it shows
The button is correctly named for assistive technology, but the instruction never uses that name. It describes the button's colour, its shape and where it sits, which a screen reader doesn't announce and which the narrow layout changes.
The button now shows its name, and the name comes from that text, so what people see, what a screen reader says and what voice control listens for are the same three words. The instruction quotes them, so it holds at every width and in every layout, and a sighted reader can still match it by sight. The arrow stays as decoration beside the words.
Both pass 1.3.3. Words on the button give everyone the same name with nothing to keep in step, and they help people who don't read an arrow as "continue" at all; the cost is a wider button and a design change, which may belong to a shared component or another team. Adding the name to the instruction is a one-line copy change that leaves the design alone, but the button still shows no words, and the sentence has to be checked whenever the button's look changes. When you can change the button, give it words. When you can't yet, fix the sentence now and change the button with the next release of the component.
"Above" and "below" are allowed when they follow the reading order. The Understanding page for 1.3.3 accepts "choose one of the links below" when the links really come next in the page and the reference is unambiguous. "On the right", "in the sidebar" and "in the top corner" have no such reading, and a responsive layout can move what they describe.
Legends count as instructions. A key that says "a leaf means reusable packaging" needs the leaf to carry the same words where it is used: visible text beside it, or at least an accessible name such as <img src="leaf.svg" alt="Reusable packaging">. The same holds for colour keys in charts, maps and availability calendars.
A sound needs a visible twin. If a chime or a vibration tells people that something happened, show the same message on screen and write it into a status region, so people who can't hear it, or have the sound off, get it too.
Keep instruction copy where it can be checked. Copy written in a CMS or a translation file drifts from the components it describes. Quote button text from the same source the button uses, or search the copy for colour and position words when a design changes.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
4 checks, no mouse.
Test with: Screen reader, Speech input, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the copy, the layout or the button design changes.
Limits
This is a starting pattern, not a guarantee for every application. It covers instructions that point to controls and items. A button with no accessible name at all is a different failure, covered in icon-only buttons with no accessible name, and fields marked only by a colour are covered in required fields marked only by colour. Instructions in images, videos and PDFs need the same check. Test the complete journey with people who rely on it.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.