Sensory Characteristics in E-Commerce Instructions: What WCAG SC 1.3.3 Actually Requires

A size guide tells a shopper to “tap the icon on the right to switch to centimeters.” A return help page says “click the round button to start your request.” A checkout confirmation reads “press the green button to place your order.” None of these look like accessibility problems — they’re just how people write instructions. But every one of them fails WCAG the same way: the instruction identifies a control only by what it looks like or where it sits, with no name attached, so it stops working the moment a reader can’t perceive shape, color, or position at all.

Quick answer: WCAG SC 1.3.3 Sensory Characteristics (Level A) requires that “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.” In e-commerce, this shows up constantly in the instructional copy around the product — size guides, checkout steps, help-center articles, live-chat scripts — not just in the UI code itself, which makes it a content-team issue as much as a developer one.

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question — consult qualified counsel for legal risk questions.

Why this is a copy problem, not just a code problem

Most of the WCAG criteria this site covers are about markup: does a button have a role, a name, a keyboard handler. SC 1.3.3 is different — it’s about the sentences a person wrote to tell a shopper what to do, usually written by a content or support team, not the developer who built the button. A perfectly accessible, properly labeled button can still fail this criterion if the instruction telling someone to use it never mentions that label at all.

A few illustrative examples of the pattern (the shape of the mistake, not a transcript from any real site):

• A size-guide tooltip: “Tap the icon on the right to see measurements in centimeters.”
• A returns help-center article: “Click the round button to start your return request.”
• A checkout confirmation step: “Press the green button below to place your order.”
• A live-chat scripted greeting: “Click the little chat bubble in the corner if you need help.”

Each reads fine for a sighted reader looking at the exact layout the writer had in front of them, but none work for a screen-reader user, who never perceives “round” or “green” at all, or for a sighted user on a narrow screen or a zoomed-in view where “on the right” may no longer be true.

What the criterion actually says

The Understanding document’s Intent is direct about the failure mode: “some content relies on knowledge of the shape or position of objects that are not available from the structure of the content (for example, ‘round button’ or ‘button to the right’).” Its own worked examples make the line clear:

• Fails: a schedule where the only instruction given is “events marked with a blue diamond are played on field A and events marked with a green circle are played on field B” — identification by color and shape alone, nothing else.
• Passes: a survey instructing “to move to the next section of the survey, select the green arrow icon labeled ‘Next’ in the lower right corner” — the sensory description (green, arrow, lower right) is still there, but it’s paired with the control’s actual accessible name (“Next”), so the instruction still works with the color and position stripped out.

That second example matters as much as the first: SC 1.3.3 doesn’t ban describing what something looks like. It requires that the description not be the only way to identify it.

The strip test

There’s a simple, quotable way to check any instruction against this criterion: delete every word that describes shape, color, size, position, orientation, or sound, and see what’s left. If a real name or label survives, it passes. If nothing does, it fails.

“Press the green button below to place your order” strips down to “Press the button to place your order” — no name left, fails. WCAG Technique F14, the named failure technique for this criterion, uses exactly this shape of example: instructions like “press the button to the right” or “press the square button to exit,” where a reader who can’t perceive shape or position has nothing left to act on.

The fix: pair the description with the control’s real name

WCAG Technique G96 is the sufficient technique for this criterion, and its own description states the goal plainly: ensure items are “referenced in the content not only by shape, size, sound or location, but also in ways that do not depend on that sensory perception… a reference may also describe the function of the item or its label.” Its worked examples show the fix is additive, not a rewrite — keep the sensory description if it’s useful, just add the label:

• “To submit the form press the round button labeled go.”
• “Use the list of links to the right with the heading Class Listing to navigate to the desired on-line course.”
• “Complete the form and then press the lower-right (sign up) button.”

Applied to the e-commerce examples above:

Fails (sensory-only)	Passes (sensory + label)
“Tap the icon on the right to see measurements in centimeters.”	“Tap the cm/in toggle icon on the right to switch units.”
“Click the round button to start your return request.”	“Click the round Start a Return button to start your request.”
“Press the green button below to place your order.”	“Press the Place Order button (shown in green) below.”
“Click the little chat bubble in the corner if you need help.”	“Click the chat icon, labeled Chat with us, in the corner if you need help.”

Nothing about the visual design changes. The fix is entirely in the words — naming the control the instruction is pointing at, in addition to (not instead of) describing it.

Where this shows up beyond on-page copy

This criterion covers any instructional content tied to the product, not just on-page text: help-center articles, order-confirmation emails, packing-slip inserts that say “see the app,” and live-chat or phone-support scripts. A script telling an agent to say “have them click the round icon” fails the same way for a screen-reader user on the call as a badly worded tooltip does.

It’s worth keeping distinct from two nearby criteria. SC 1.4.1 Use of Color, covered in Quietramp’s color and size variant swatches article, is about a control’s state being shown by color alone (a selected swatch marked only by a colored border). SC 1.3.3 is about instructions that reference appearance or position without naming what they point at — a different failure, even where both involve color. A “click here” link is a separate criterion, SC 2.4.4 Link Purpose, not this one.

What a scanner catches here, and what needs a person

This is one of the clearest cases where automated tooling structurally cannot help. axe-core, WAVE, and Lighthouse all parse DOM structure and attributes — they can flag a button with no accessible name, but none of them read the prose in a help-center article, a tooltip, or a support macro and judge whether it identifies a control by shape or position alone. Catching this requires a person reading the actual instructional copy across the site — including the parts a scanner never even looks at, like email templates and support scripts — and checking whether it still makes sense with the sensory language removed.

FAQ

Does this mean we can never describe what a button looks like? No. WCAG’s own passing examples keep the color, shape, and position language — “green arrow icon,” “lower-right (sign up) button” — they just add the actual name alongside it. Describing appearance is fine; relying on it alone is the failure.

Is this the same as alt text for an icon? No. Alt text (SC 1.1.1) is about a non-text element itself having a text equivalent. SC 1.3.3 is about instructional sentences elsewhere on the page (or in an email, or a script) that reference a control by its appearance instead of its name.

Does a “click here” link fail this criterion? That’s a different one — SC 2.4.4 Link Purpose covers link text needing to make sense in context. It’s a related “does the instruction actually identify what to do” family of problems, but it’s evaluated separately from 1.3.3.

Get your site’s copy checked by a person, not just a parser

Quietramp’s $890 audits include a manual read-through of instructional copy — size guides, checkout steps, help-center content the audit can reach — for exactly this kind of sensory-only reference that no scanner can catch on its own. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.