F14: When 'Click the Button on the Right' Fails WCAG 1.3.3

Shape-only. Location-only. Two words that describe a pattern so embedded in everyday UI writing that most teams never flag it as a problem. WCAG Failure F14 (opens in new window) documents exactly this: instructions that rely exclusively on visual shape or spatial position to identify content, with no text alternative that conveys the same meaning. It's a failure of Success Criterion 1.3.3 Sensory Characteristics (opens in new window), and it applies to every technology — web, mobile, kiosk, document.

The W3C's catalog entry is short. The real-world consequences are not.

THE FAILURE

SC 1.3.3 requires that instructions for understanding and operating content do not rely solely on sensory characteristics — shape, size, visual location, orientation, or sound. F14 isolates the shape and location subset of that requirement.

The W3C's own examples are instructive precisely because they're so ordinary:

• "To go to the next page, press the button to the right."
• "Please see the sidebar to the left of the illustration for links to additional information."
• "Press the square button to exit without saving. Press the triangle button to save in progress. Press the round button to submit."

Each of these is a real pattern. Each fails the criterion on its own. The survey button example — square, triangle, round — is particularly telling. It's the kind of visual differentiation a designer might be proud of: distinctive, clean, icon-driven. For a screen reader user, it's three unlabeled controls with no functional distinction.

<!-- Failure pattern: shape-only identification -->
<p>Press the <button class="btn-round">●</button> to submit your results.</p>
<!-- Failure pattern: location-only identification -->
<p>See the sidebar to the left for additional links.</p>

Neither instruction survives without the visual context. Remove the screen, magnify to 400%, switch to a screen reader — the instruction collapses.

WHY THIS MATTERS

For a compliance officer reviewing this failure, the first instinct might be to categorize it as minor — a content issue, not a structural one. That framing underestimates the impact.

Consider what happens to a screen reader user encountering the survey example. Three buttons. The AT reads each one. If the buttons are labeled only by shape class or icon glyph with no accessible name, the user hears: "button, button, button." If the surrounding instruction text is the only differentiator — square, triangle, round — that instruction is meaningless without sight. The user cannot complete the form. Not with difficulty. Not slowly. Cannot.

For low-vision users navigating with high magnification, spatial references like "sidebar to the left" become unreliable. At 400% zoom, the sidebar may not be visible in the same viewport as the instruction. The reference points to something the user cannot currently see and may not be able to locate without significant scrolling — and no guarantee they'll recognize it as the referenced element when they find it.

Cognitive accessibility is also implicated. Users who struggle to hold spatial relationships in working memory — including many users with acquired brain injuries or certain learning disabilities — benefit from explicit, text-based identification regardless of visual ability. "The sidebar" is a concept that requires constructing a mental map of the page. "The Related Links section" is a label.

This failure is also essentially undetectable by automated tools. Research on testing methodology confirms that automated scanners max out at roughly 37% detection of real accessibility barriers — and F14 is squarely in the 63% that requires human judgment. A scanner cannot read "press the button to the right" and determine that no non-visual alternative exists. That requires a human reviewer who understands what the instruction is pointing to and whether it could be understood without sight.

THE FIX

The corrective pattern is straightforward: add non-visual identifiers alongside any shape or location reference. The W3C's guidance for SC 1.3.3 suggests several approaches.

<!-- Fixed: adds accessible name to button, removes shape dependency -->
<button type="submit" aria-label="Submit survey results">●</button>
<button type="button" aria-label="Save progress and return later">▲</button>
<button type="button" aria-label="Exit without saving">■</button>
<!-- Fixed: instruction uses label, not location -->
<p>
  For additional information, see the 
  <a href="#related-links">Related Links section</a> 
  below the illustration.
</p>

For the sidebar example, the W3C identifies three valid remediation paths: include the links inline in the text, provide an in-page anchor link from the instruction to the sidebar, or give the sidebar a heading and reference that heading by name. All three work. All three eliminate the location dependency.

The principle across all fixes: the instruction must be operable without the visual context. If you removed every CSS rule and every spatial relationship, would the instruction still point to something identifiable? If not, it fails.

APPLYING THIS

For development teams, the catch point for F14 is content review, not code review. The failure lives in instructional text and UI copy — which means the people most likely to introduce it are content writers and UX designers, not engineers. A developer writing <button class="btn-round"> may add an aria-label correctly; the failure emerges when the surrounding paragraph says "press the round button" and nothing else.

Practical integration points:

In design review: Flag any instruction that uses directional language (left, right, above, below) or shape language (square, circle, triangle, round) as requiring a content audit question: What is the non-visual identifier for this element?

In content style guides: Add a rule: instructions must identify interactive elements by their accessible name or heading, not by their position or visual appearance. "Click Submit" not "click the button on the right."

In QA: Test instructions by reading them aloud without looking at the screen. If the instruction doesn't resolve to a specific, findable element, it fails.

In automated testing: Don't expect your scanner to catch this. As research on hybrid testing methodologies documents, this category of failure requires human judgment about semantic meaning — something no current automated tool reliably provides. Build manual content review into your testing cycle.

The fix cost here is low. Rewriting "press the button to the right" as "press the Next Page button" takes seconds. The organizational challenge is building the awareness that the problem exists — because the failure pattern looks perfectly clear to anyone who can see the screen.

CORS PERSPECTIVE

From a risk and legal priority standpoint, F14 sits in an uncomfortable position: it's a clear WCAG Level A failure with measurable impact on real users, but it's nearly invisible to automated compliance scanning — which means organizations relying on automated audits to assess their WCAG compliance posture may be systematically underreporting this violation. In enforcement contexts, that gap matters. DOJ investigations and structured negotiations under Title II (opens in new window) increasingly scrutinize the quality of accessibility testing methodology, not just its outputs. An organization that can demonstrate only automated scan results, with no evidence of manual content review, has a weaker compliance posture than the scan scores suggest.