WCAG 1.3.3 — Sensory Characteristics

What this requires

Instructions for understanding or operating content must not rely solely on sensory characteristics like shape, colour, size, visual location, orientation, or sound. "Press the red button" is fine if the button also has the label "Submit"; it is a failure if the only thing distinguishing the button is its colour. The criterion is about having a non-sensory channel available — not about removing the sensory channel.

How AI coding tools fail this

When asked to write microcopy ("tell users how to dismiss the modal", "add a tip near the form"), AI tools default to spatial and visual shorthand: "click the X in the top right", "the green checkmark means…", "press the icon below". The sentences are natural English; they're also unintelligible to users who can't see colour, position, or icons.

The second pattern: chart and dashboard tooltips that say "the line trending up shows revenue" without ever naming which colour or which series corresponds to revenue. A screen-reader user gets a tooltip that explains nothing.

The third: error messages that depend on adjacency. "Fix the field highlighted in red below" assumes the user can perceive both colour and spatial relationship. A screen-reader user announced "Please fix errors" hears an instruction with no actionable referent.

Failing examples

Instructions that lean entirely on visual position and colour:

<p>Tap the green button on the right to continue.</p>

Chart caption that depends on colour alone:

<>
  <Chart data={series} />
  <p>The red line is revenue; the blue line is cost.</p>
</>

Passing examples

Refer to the control by its accessible name as well as its appearance:

<p>Select <strong>Continue</strong> (the green button on the right) to proceed.</p>

Chart caption that names the data alongside the visual cue, and a table with the same information:

<>
  <Chart data={series} aria-describedby="chart-summary" />
  <p id="chart-summary">
    Revenue (shown in red, top line) reached $2.1M; cost (shown in blue,
    bottom line) reached $0.9M.
  </p>
  <details>
    <summary>Show data table</summary>
    <table>
      <caption>Revenue and cost by month</caption>
      {/* ... */}
    </table>
  </details>
</>

Edge cases

Belt-and-braces is the goal. Keep the visual instruction; add a non-visual one. The criterion bans sensory-only, not sensory.
Status-by-colour patterns ("rows in red are overdue") need a text or icon equivalent in the row itself. See 1.4.1.
Audio cues also count. A form that beeps on success but says nothing visually fails for deaf users.
Maps and diagrams carry information through location. They need a textual equivalent (a list, a description, a <table>), not just alt text.
Onboarding tours built with tooltips pointing at "this button" need to name the button explicitly.

How Jeikin handles this

This criterion is manual — the scanner can't tell whether a sentence refers to a control by colour, shape, or name. Jeikin treats it as a copy-review item: the dashboard surfaces instructional text and asks the reviewer to confirm each instruction can be followed without sight, hearing, or spatial perception. The evidence is the reviewer's pass.

References

W3C — Understanding 1.3.3 Sensory Characteristics (opens in new tab)