1.3.3 Sensory Characteristics
- Level A
- Perceivable
- Since WCAG 2.0
Summary
This criterion protects people who cannot perceive the characteristic an instruction leans on. "Click the round button" means nothing to a screen reader user who never sees roundness. "See the box on the right" fails someone using a screen magnifier, where left and right are whatever fits in the viewport, and someone listening to the page in reading order. "Wait for the beep" excludes deaf and hard of hearing users entirely. Instructions must work for a person who cannot see the shape, judge the size, locate the position, or hear the sound.
The auditor's mental model: grade the instructions, not the design. A screen full of coloured, shaped, positioned controls is not a 1.3.3 finding on its own. The criterion fires only where text tells the user how to understand or operate the content and that text relies solely on a sensory characteristic to identify what it is talking about. Sensory references are welcome as a supplement: "click Save, the green button" passes, because a user who cannot perceive green still has the name Save to work with. The single question per instruction is: strip out every reference to shape, colour, size, location, orientation, and sound, and can the user still find the thing?
Official wording
Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.
EN 301 549 mapping
- Web pages
- Clause 9.1.3.3
- Software and native apps
- Clause 11.1.3.3
Clauses 9.1.3.3 (web) and 11.1.3.3 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Read the page's instructional text, not its widgets. Sweep help text, form hints and error messages, onboarding copy, tooltips, confirmation dialogs, and any "how to use this page" prose. A quick way to surface candidates is searching the rendered text (or the DOM in browser devtools) for trigger words: right, left, above, below, corner, round, square, green, red, larger, smaller, sidebar, beep, tone. Every hit gets the strip test: remove the sensory reference and check whether the instruction still uniquely identifies its target, usually because it also gives the control's visible name or label.
Two nuances keep false positives down. First, "above" and "below" used to mean earlier or later in the reading order ("see the note below") are generally acceptable, because content order survives into the accessibility tree and linearised layouts; "the menu on the right" does not, because right may not exist on a narrow viewport or in reading order. Second, confirm the named control actually carries that name accessibly: "press Save" only rescues the instruction if the button is named Save for assistive technology as well as visually.
Audio cues deserve a separate pass: any instruction of the form "listen for the chime" or "you will hear a tone when the upload finishes" fails unless the same information is available another way, such as an on-screen status message.
iOS
The criterion applies unchanged to native software under the European standard, so grade iOS app copy exactly as you would web copy. The failure spots are the instructional surfaces apps bolt on around their screens: onboarding tooltips, walkthrough coach marks, empty states, and first-run overlays. "Tap the icon in the corner to get started" is the classic coach mark failure: it identifies the control only by location and by being an icon, which is shape and position with no name.
Walk each screen with VoiceOver running and ask whether every instruction you can read still makes sense with your eyes closed. If a coach mark says "tap the gear in the top right", check whether it also names the destination ("tap Settings, the gear in the top right" passes). Swipe instructions that reference a direction are fine when the direction is not the only cue and the instruction also mentions the control or the action by name: "swipe left on a message to reveal Delete" gives the user both the gesture and the named target, and directional gestures are how the platform itself describes them.
Also listen for sound-only feedback promised in copy: "wait for the beep before speaking" needs a visible equivalent such as an on-screen recording indicator.
Android
Same rule, same surfaces: onboarding overlays, feature-discovery coach marks, empty-state copy, snackbars and toasts that direct the user somewhere, and hint text in forms. Toasts are worth particular attention because they are transient and often written casually: "use the button at the bottom right to add an item" identifies the floating action button purely by position, where "tap Add (the button at the bottom right)" passes.
Test with TalkBack running and confirm each instruction identifies its target by a name TalkBack actually announces. Where copy names a control ("tap Save"), verify the control's accessible label matches, otherwise the name in the instruction is a dead reference. As on iOS, directional swipe instructions pass when the direction accompanies a named control or action rather than standing alone, and audio cues referenced in copy ("you will hear a tone when the scan completes") need a visual or haptic equivalent surfaced in the interface.
Screenshots of the offending copy are usually all the evidence a finding needs; this criterion rarely requires tooling beyond reading carefully.
Pass and fail examples
Passes:
- "Click Save, the green button, to continue": colour is a supplement, the name Save does the identifying.
- "Press Submit at the end of the form": identifies the control by name; "at the end of the form" is reading-order position, which survives linearisation.
- "See the note below" where the note follows in reading order: above and below as content order, not visual layout.
- "Swipe left on a conversation to reveal the Archive action": the gesture direction is paired with a named control.
- "When the upload finishes you will hear a chime and the status will change to Complete": the sound is one of two cues, not the only one.
Fails:
- "Click the round button to begin": shape is the only identification.
- "See the box on the right for delivery options": visual location only; there is no right-hand box in reading order or on a narrow viewport.
- "Press the green button to accept and the red button to decline": colour is the sole identifier for both actions.
- "Wait for the beep, then speak": sound only, with no visible equivalent mentioned or provided.
- A coach mark reading "tap the icon in the corner to open your profile": icon plus corner is shape plus location, with no name.
Not a fail under this criterion:
- A status dot that is red or green with no text label: that is colour used as the only indicator of information, which files under Use of Color, not here; 1.3.3 needs an instruction.
- A visually two-column layout whose relationships are not conveyed programmatically: structure and relationships belong under Info and Relationships.
- An icon-only button with no accessible name and no instruction referring to it: a name finding under SC 4.1.2 Name, Role, Value (or SC 1.1.1 Non-text Content for image elements), not a sensory-instruction finding.
- A form with no instructions at all where instructions are needed: the absence of instructions is SC 3.3.2 Labels or Instructions; 1.3.3 only grades instructions that exist.
Commonly confused with
- Use of Color, SC 1.4.1. The commonest misfiling. 1.3.3 is about instructions ("press the green button"); 1.4.1 is about information display (a chart, status, or required-field marker where colour is the only signal). If there is no instructional sentence, the finding is not 1.3.3. A single screen can produce both: colour-coded statuses fail 1.4.1, and the help text telling users to "look for the green ones" fails 1.3.3.
- Info and Relationships, SC 1.3.1. Location-based instructions fail here; location-based meaning that is visual only (a sidebar that is only recognisable as a sidebar by its position, headings conveyed by bold text alone) fails 1.3.1 because the structure is not programmatically determinable. Grade the copy under 1.3.3 and the markup under 1.3.1.
- SC 3.3.2 Labels or Instructions. 3.3.2 asks whether instructions exist where user input needs them; 1.3.3 asks whether the instructions that do exist rely solely on sensory characteristics. Missing instructions are 3.3.2; bad ones are 1.3.3.
- SC 1.1.1 Non-text Content. "Wait for the beep" is a 1.3.3 instruction problem. An audio-only alert with no text alternative in the interface itself is a non-text-content or media problem. The line: 1.3.3 grades what the copy tells users to rely on.
How AUDITSU tests this
AUDITSU's audit walkthrough covers this criterion with a per-screen question aimed squarely at copy: identify every instruction on the screen (help text, hints, error messages, coach marks, empty states) and apply the strip test, checking that each one still identifies its target once shape, colour, size, location, orientation, and sound references are removed. Because the check is about instructions rather than widgets, the walkthrough prompts you to read the screen's text deliberately, with the screen reader running where relevant so dead name references surface at the same time. Each screen records a pass, fail, or not applicable result with the offending copy captured as evidence, so findings land in your report tied to the exact sentence and screen.
The criterion applies unchanged to web content and native software under the European standard, so the same question appears in web, iOS, and Android walkthroughs.
For the full guided workflow, see the audit platform.