# Instructions that rely on colour, shape or position

Source: https://easeweb.dev/learn/sensory-instructions
Topics: Colour and contrast > Instructions do not rely on shape or position (WCAG 1.3.3)
The fix: Point to a control by its name, not by how it looks or where it sits. Either put the words on the button and quote them in the instruction, or keep the icon and add its accessible name to the instruction beside a description that stays true at every screen width. Drop position words that a responsive layout can make false.
Test with: screen reader, speech input, zoom
References: https://www.w3.org/WAI/WCAG22/Understanding/sensory-characteristics.html https://www.w3.org/WAI/WCAG22/Techniques/general/G96 https://www.w3.org/WAI/WCAG22/Techniques/failures/F14 https://www.w3.org/WAI/WCAG22/Techniques/failures/F26

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.

## What happens

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.

## Why it fails

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.

## Who is affected

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.

## What automation and AI miss

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.

## Before: an instruction that points by colour, shape and position

```html
<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>
```

```css
.step-actions {
  display: flex;
  justify-content: space-between;
  align-items: center;
}
.next {
  border-radius: 50%;
  background: #1e7a3a;
  color: #fff;
}
@media (max-width: 30em) {
  .step-actions {
    flex-direction: column;
    align-items: flex-start;
  }
}
```

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.

## After: words on the button, quoted in the instruction

```html
<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>
```

```css
.next {
  display: inline-flex;
  align-items: center;
  gap: 0.5em;
  border-radius: 999px;
  background: #1e7a3a;
  color: #fff;
}
```

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.

## After: the name added to a description that stays true

```html
<h2>Delivery</h2>
<p>Choose a delivery slot, then press Continue to payment, the green arrow button.</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>
```

The button is untouched; only the sentence changes. It now names the button with its exact accessible name, so a screen reader user hears a name they will meet again, and a voice control user learns what to say. "The green arrow button" stays for sighted readers, because colour and shape are true on every screen. "On the right" is gone, because on a phone it is not. Keep the `aria-label` and the sentence in exactly the same words, and update the description when the design changes: a new icon or a new brand colour makes it wrong for sighted readers, even though the name still passes.

## Which option to use

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.

## Implementation decisions

"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.

## Verify the fix

1. Read the whole step with a screen reader from the top, and confirm each instruction leads to the control it means without looking at the screen.
2. For each instruction, compare the words it uses with the control's accessible name in the browser's accessibility tree, and confirm they match exactly.
3. Narrow the window to phone width and zoom to 400%, and confirm every instruction still describes what is on screen, including any position or colour words.
4. With voice control, say the words each instruction gives, such as "click Continue to payment", and confirm the right control responds.

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](/learn/icon-buttons), and fields marked only by a colour are covered in [required fields marked only by colour](/learn/required-fields). Instructions in images, videos and PDFs need the same check. Test the complete journey with people who rely on it.

---

Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)