WCAG 1.3.3: When 'Click the Round Button' Leaves Users Behind

Instructions that rely on shape, color, or position exclude users who can't see the screen. WCAG 1.3.3 requires something simpler: just name the thing.

Most accessibility failures are invisible to the people who create them. A designer writes "click the blue button on the right" and moves on. The instruction is perfectly clear — if you can see the screen. For a screen reader user navigating by keyboard, "the blue button on the right" is meaningless. There is no right. There is no blue. There is only a sequence of focusable elements, and none of them have been given a label that matches the instruction.

WCAG 1.3.3 Sensory Characteristics (opens in new window) — a Level A requirement, meaning it sits at the baseline of conformance — addresses exactly this pattern. It requires that instructions for using content not rely solely on sensory characteristics: shape, size, visual location, orientation, or sound. The word "solely" matters here. You can still say "the round button" — you just can't stop there.

The Requirement

The official W3C Understanding document (opens in new window) frames the intent clearly: all users must be able to access instructions for using content, even when they cannot perceive shape, size, spatial location, or orientation. Some content relies on knowledge of these properties that isn't available from the structure of the content itself.

The criterion applies to instructions — the guidance that tells users how to interact with controls, navigate content, or complete tasks. It does not prohibit sensory language; it prohibits exclusive reliance on it.

One nuance worth understanding: spatial language like "above" and "below" can satisfy this criterion when it accurately reflects reading order and the reference is unambiguous. "Choose one of the links below" is acceptable if those links genuinely follow in the document structure. The problem isn't spatial language — it's spatial language that substitutes for a meaningful name.

Instruction Pattern	Passes 1.3.3?	Why
"Click the round button"	❌ No	Shape only — no name or function
"Click the Submit button"	✅ Yes	Named by function, no sensory dependency
"Click the round Submit button"	✅ Yes	Shape + name — sensory cue supplements, not replaces
"Select the option on the right"	❌ No	Position only — no name or label
"Select the 'Weekly' option"	✅ Yes	Named — position irrelevant
"Choose one of the links below" (in reading order)	✅ Yes	Position reflects document structure accurately
"Press the green button to continue"	❌ No	Color only — fails 1.3.3 and likely 1.4.1

Why This Matters

The exclusion here is concrete. Screen reader users navigate by element type, label, and heading — not by visual position or appearance. When instructions say "click the button on the right," a screen reader user has no mechanism to identify which button that is. They may encounter three buttons in sequence. None of them are "on the right" in any meaningful sense.

Users with low vision face a related problem. Someone using high magnification may see only a portion of the screen at a time. "The button in the upper right corner" may be off-screen entirely. The instruction assumes a field of view the user doesn't have.

Cognitive accessibility is also at stake. Spatial and shape-based instructions add an extra translation step — the user must map the instruction to what they see, then act. Naming controls directly removes that step. The W3C's Understanding document acknowledges this explicitly: sensory cues are effective for many users, including those with cognitive limitations. The goal isn't to eliminate them. It's to ensure they never stand alone.

The documented failure modes are F14 (opens in new window) — identifying content by its visual or auditory characteristics — and F26 (opens in new window) — using a graphical symbol alone to convey information. Both appear regularly in real-world audits, and both are difficult for automated tools to catch reliably. This is precisely the kind of criterion our research on automated vs. manual testing identifies as falling into the 63% of issues that automated scanners miss entirely — the tool sees the button, but it can't read the instruction that references it.

How to Meet It

The sufficient technique is G96 (opens in new window): provide textual identification of items that otherwise rely only on sensory information. In practice, this means:

Name controls by their label or function. If a button says "Submit," the instruction says "Submit." If a field is labeled "Email address," the instruction says "Enter your email address in the Email address field." The label in the instruction matches the label on the control.

Supplement sensory cues, don't replace them. "Click the large, round Submit button in the bottom right" passes — the name is there. The shape and position are bonus context for sighted users. This is the design pattern the W3C explicitly endorses.

Audit your help text, tooltips, and onboarding flows. These are where sensory-only instructions concentrate. Error messages, form hints, and tutorial overlays are prime candidates for F14 failures.

Check icon-only interfaces carefully. An interface that uses icons without text labels, then references those icons in instructions ("click the gear icon"), may satisfy 1.3.3 if the icon has an accessible name that matches — but only if that name is consistently exposed to assistive technology.

Applying This in Practice

Automated testing will not reliably catch 1.3.3 failures. The violation lives in the relationship between an instruction (often in paragraph text) and a control (somewhere else in the DOM). No scanner reads that relationship. Manual review is required.

In design review, flag any instruction that contains words like: right, left, above, below, round, square, green, red, large, small, icon. These aren't automatic failures — but they're signals to verify that a non-sensory identifier also exists.

In QA, test with a screen reader and read the instructions aloud without looking at the screen. If you can't identify the referenced control from the instruction alone, the criterion fails.

Content teams need this guidance as much as developers do. Instructions live in copy, not code. The fix is often editorial — rewriting "click the arrow" to "click Next" — and takes minutes. The challenge is systematic review across a large content library, where sensory-only instructions have accumulated over years without anyone flagging them.

For organizations managing compliance across multiple standards, 1.3.3 is worth noting as one of the criteria where WCAG 2.1, WCAG 2.2, and Section 508 align without divergence. Meeting it once satisfies all three frameworks — a rare clean win in a landscape that more often demands redundant effort.

CORS Perspective

Through a balanced CORS lens, 1.3.3 is a low-cost, high-dignity fix that sits at the intersection of all four pillars. Community impact is direct: blind users, low-vision users, and users with cognitive disabilities all benefit from named controls. Operationally, the fix is editorial — no engineering sprint required, just content review and a writing guideline added to the style guide. The risk profile is clear: Level A violations are baseline conformance failures, and settlements increasingly scrutinize whether organizations have addressed foundational criteria before claiming compliance. Strategically, fixing sensory-only instructions is the kind of change that builds internal accessibility literacy — writers learn to name things, designers learn to label controls, and the habit compounds across the product. The criterion asks for almost nothing and returns equal access to a significant share of users. That ratio is why it belongs at Level A.