WCAG 1.3.3 Sensory Characteristics (Level A) says instructions for understanding or operating your content must not rely solely on sensory traits — shape, color, size, visual location, orientation, or sound. If a user can’t see or hear the cue you’re describing, you must give a second, non-sensory way to find or identify the thing.

What WCAG 1.3.3 requires, in plain terms

The official W3C wording is precise: “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” (W3C Understanding 1.3.3). The whole criterion turns on the word solely. You are not banned from using sensory descriptions. “Click the big green round button in the bottom-right” is fine — as long as you also say “…the Submit button.” The sensory hint helps sighted users; the text label rescues everyone else.

This is one of the structure-and-relationships criteria under the Perceivable principle of the POUR framework. It is Level A, the floor of conformance, which means it applies to essentially every site claiming any level of WCAG support.

Who this affects, and why

The barrier is concrete:

  • Blind screen reader users hear a linear stream of text. Software like JAWS, NVDA, or VoiceOver (see our screen readers guide) cannot announce “the green diamond” or “the panel in the upper-right corner.” Visual location and color simply don’t exist in the audio output.
  • Low-vision users who zoom to 200–400% see only a slice of the screen at a time. An instruction like “use the menu on the far right” assumes they can perceive the whole layout at once — they often can’t.
  • Color-blind users lose any instruction keyed to color: “fields marked in red are required.”
  • Deaf and hard-of-hearing users miss instructions that depend on a sound: “you’ll hear a beep when the upload finishes.”

Concrete failures (and the fix)

Failure F14 — identifying content only by shape or location

W3C’s named failure F14 covers instructions that point to content using only its shape or position. Its canonical example: a survey that says “Press the square button to exit, the triangle button to save, and the round button to submit.” A screen reader user has no idea which button is the “round” one.

The fix is W3C technique G96: add a textual identifier so the control can be found without perceiving shape, size, or position. Keep the helpful spatial hint and name the control:

<!-- Fails 1.3.3 (F14): location is the only cue -->
<p>Complete the form, then press the button in the lower right.</p>
<button>→</button>

<!-- Passes 1.3.3 (G96): location PLUS a real text label -->
<p>Complete the form, then press the lower-right Sign up button.</p>
<button>Sign up</button>

Failure F26 — a graphical symbol alone

W3C failure F26 covers conveying information with a graphical symbol and nothing else — the classic bare icon button. A magnifying-glass <button> with no text or accessible name is announced as “button,” full stop.

<!-- Fails 1.3.3 (F26) and 1.1.1: icon carries all the meaning -->
<button><svg>...</svg></button>

<!-- Passes: accessible name supplies the non-sensory identifier -->
<button aria-label="Search">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

This is where 1.3.3 overlaps with 1.1.1 Non-text Content and good ARIA labelling: the aria-label is the textual identifier that satisfies both.

Color- and sound-only instructions

  • “Required fields are shown in red.” — Add a visible “(required)” word or asterisk with a legend, not color alone. (Color-as-only-cue is also 1.4.1’s domain, but a red-only instruction fails 1.3.3 too.)
  • W3C’s own example: a schedule that says “events marked with a blue diamond are on field A, green circle on field B.” Add the field name as text in each row.
  • “A chime confirms your order.” — Pair the sound with an on-screen confirmation message.

How to test for 1.3.3

This criterion is largely manual — automated scanners can’t read intent in prose, so they rarely catch it. Work through your content:

  1. Search your copy for sensory words. Grep your templates and CMS content for left, right, above, below, top, bottom, corner, round, square, circle, blue, green, red, beep, chime, “icon below.”
  2. For each hit, ask: is there a non-sensory cue too? If “the button on the right” also names the button (“the Continue button on the right”), you pass. If not, it fails.
  3. Turn off the screen / use a screen reader. Run VoiceOver or NVDA and try to follow your own instructions with the monitor off. If you get stuck, so will your users.
  4. Check icon-only controls for an accessible name (aria-label, visually-hidden text, or a <title>).
  5. Review form help text, tooltips, error messages, onboarding tours, and “see below” cross-references — these are where 1.3.3 failures cluster.

Because the check is judgment-based, it’s a textbook case for manual remediation over an overlay widget. No script can rewrite “click the green icon” into a meaningful instruction.

A 1.3.3 failure is unusually dangerous in a demand letter because it needs no tooling to prove: the offending sentence — “press the round button to submit,” “the icon below” — is sitting in your visible copy, and a tester can screenshot it and paste it straight into a complaint. Where a contrast or focus-order claim leans on a scan report, a sensory-only instruction is self-documenting evidence. And the volume is real: UsableNet recorded 4,187 ADA-related digital accessibility lawsuits in 2024, with over 1,000 of those (about 25%) naming businesses that already had an accessibility overlay or widget installed (UsableNet 2024 Year-End Report) — a reminder that the widget bolted to your footer does nothing for instructions buried in your prose. The targets are not just big brands: 67% of 2024 website-accessibility suits hit companies with under $25M in annual revenue (Accessibility.Works 2024 lawsuit trends summary).

The DOJ’s own April 2024 Title II rule and its web accessibility guidance treat WCAG 2.1 AA as the operative measure of an accessible site, and because AA conformance folds in every Level A checkpoint, an instruction that relies solely on shape, color, or location fails the floor the courts are measuring against in ADA Title III matters. What makes 1.3.3 stand out from most criteria, though, is the asymmetry: it is one of the very cheapest to remediate — a plaintiff can document it in a screenshot, but you can usually close it with a one-line copy edit and an aria-label, not a redesign or a rebuild.

This page explains how WCAG 1.3.3 maps to common legal exposure; it is general information, not legal advice. A consultant can confirm whether a specific sensory-only instruction on your site is a genuine conformance gap, but only a qualified accessibility attorney can advise on your litigation risk.

Fix it the durable way

1.3.3 lives in your words, not just your widgets — which is exactly why an overlay can’t touch it (more on why overlays don’t work). At Curbcut we remediate by hand: our team rewrites sensory-only instructions, adds accessible names to icon controls, and verifies each fix with a real screen reader. It’s the same hands-on approach we bring to full accessibility remediation, and we can document conformance in a VPAT when you need proof. Want to know where your site stands? Run a free scan and we’ll show you the sensory-only instructions — and everything else — worth fixing.