Sensory Characteristics
Instructions for understanding or operating a page cannot lean only on how something looks, where it sits, which way it is turned, or what it sounds like. The rule names six characteristics, meaning shape, color, size, visual location, orientation and sound. "Select the round green button on the right" fails, because shape, color and position are exactly the three things somebody might not be able to perceive. Name the control instead. What the rule does not ban is ordinary English about reading order. "Choose one of the links below" conforms, as long as the links really are next in the reading order and the reference is unambiguous. Ambiguity is the test, not the word.
Why it matters
Instructions turn up at the exact moment somebody needs to succeed, so a sensory-only instruction fails precisely the person who asked for help. There is a second reason that has nothing to do with disability. Position moves. "The button on the right" is wrong the moment your layout stacks on a phone, or somebody's font size pushes the row onto two lines, or your own redesign shifts the toolbar. A name does not move. Writing instructions by name fixes the rule and fixes the copy at the same time, which makes this the cheapest finding in any report we send.
Who this rule protects
Blind users have nothing to search for when a control is identified only by where it sits. Colorblind users cannot find "the green one". Screen magnifier users see a small slice of the layout at a time, so "top right" means the top right of what they can currently see rather than of the page.
How to check it yourself
- Read every instruction on the page with no screen in view and ask whether you could still follow it.
- Where an instruction points at something by shape, color, size, position, orientation or sound, check whether it also names the thing. Naming it is the fix, and the sensory cue can stay.
- Check whether the sensory word already appears in the target's own visible label. "Select the green button" passes if the button says Green, and the same is true if the word is in its accessible name.
- Judge positional words on ambiguity rather than on the word itself. "The links below" is fine when the links come next. "The button below" is not, when three buttons render in a row at mobile width.
- Look for instructions that rely on a sound, such as "when you hear the beep", and confirm something visible marks the same moment.
- Look for orientation instructions, such as "turn your phone sideways to see the chart". Those fail here. If the content is unusable until you rotate, they fail 1.3.4 as well.
- Look for a graphical symbol standing alone as the message, such as a red circle with a line through it, with no text anywhere saying what it means.
Failures we see most often
- "Press the button below to continue" appears on a page where three buttons render in a row once the layout hits mobile width.
- "Required fields are shown in red" stands as the only indication that a field is required anywhere on the form.
- A key to a schedule reads "events marked with a blue diamond are on field A", which asks a reader to perceive both a color and a shape.
- A form says "when you hear the tone, enter your code", with nothing on screen marking the moment.
- A status is shown by a symbol alone, such as a green tick or a red circle with a line through it, and no text ever says what it means.
- "Rotate your device to see the full table" leans on orientation, and if the table is unusable in portrait it fails 1.3.4 too.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Low visionpeople who can see the screen but not easily
How this one is tested
We list 1 ACT rule against 1.3.3. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.
- Content has alternative for visual referenceA tool finds candidates, you decide
How to fix it
- Name the control. "Select Continue" and "Choose Add to cart" work for everyone and survive every layout you will ever ship.
- Keep the sensory cue and add the name. "Select Filter, the funnel icon in the top right" is explicitly encouraged, because shape and position help a lot of readers when they are not carrying the whole message on their own.
- Put the word in the label. If the instruction says "the green button", the cheapest conforming fix is often to make the button say Green.
- Pair every sound cue with something visible, and every symbol with text.
- Instructions for physical hardware are a different case. On a kiosk you may describe the arrow-shaped key or the round key on the right side, because a tactile cue is one a blind user can find by touch.
Step-by-step fix guides (3)
Passes vs. fails
Passes
"Select Filter, the funnel icon in the top right, to narrow results" names the control first and treats position as a bonus.
Fails
"Click the icon on the right to filter results" gives a magnifier user or a blind user nothing to search for.
In audits and lawsuits
This is a copywriting failure rather than a code failure, which is why scanners do not catch it and why it survives one redesign after another untouched. A test rule does exist, and it runs by hand, because judging whether a reference is ambiguous needs a reader. Our reviewers read every instruction on an audited page and ask whether it still works with the screen switched off. One thing is worth knowing before a report lands. A single sentence like "required fields are shown in red" can produce three findings at once. One against this rule for the instruction, one against 1.4.1 for the color, and one against 1.3.1, because a screen reader still cannot tell which fields are required.