The 2025 TestParty Guide to WCAG 1.3.3 – Sensory Characteristics (Level A)

Why did the developer's instructions fail accessibility testing? Because they told users to "click the big green button on the right"—but the screen reader only heard crickets. 🦗

WCAG 1.3.3 Sensory Characteristics requires that instructions don't rely solely on sensory properties like shape, size, color, visual location, orientation, or sound. This Level A criterion ensures that everyone—including blind users, people with low vision, and those using assistive technology—can follow your instructions and understand your content.

Table of Contents

• What WCAG 1.3.3 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 1.3.3
• How TestParty Helps
• FAQs

What WCAG 1.3.3 Requires

WCAG 1.3.3 mandates that instructions for understanding or operating content must include more than just sensory characteristics. You can include sensory details, but they can't be the only way to identify something.

Key requirements:

• Instructions must be perceivable without vision (no "click the round button" without additional context)
• References to location must include non-visual identifiers (not just "the menu on the right")
• Shape-based instructions need text labels (not just "press the triangle to play")
• Size-based cues require additional context (not just "select the larger option")
• Sound-based instructions need visual or text alternatives

What's covered:

• Navigation instructions ("Click Submit" not just "Click the button on the bottom right")
• Form guidance ("Enter your email in the Email field" not just "Enter your email in the top box")
• Interactive controls (buttons, links, form fields)
• Content references ("See the Resources section below" not just "See the box on the right")
• Error messages and help text

Important note: This criterion focuses on instructions and references. Color-only information is covered separately under WCAG 1.4.1 Use of Color.

Why This Matters

Screen readers don't announce visual layout, shapes, or relative positions. When you tell a blind user to "click the square icon in the upper right," they have no way to follow that instruction.

People using screen magnification may only see a small portion of the screen at once, making spatial references like "the panel on the left" meaningless. Users with cognitive disabilities benefit from clear, explicit labels rather than having to interpret visual cues.

Legal and compliance context:

WCAG 1.3.3 is a Level A requirement, making it mandatory for ADA Title II and Title III compliance, Section 508 federal procurement, EN 301 549 (European ICT accessibility), and the European Accessibility Act. Lawsuits frequently cite failures where instructions rely on visual-only cues, particularly in ecommerce checkout flows and form submissions.

Business impact:

Inaccessible instructions create friction that costs conversions. When users can't figure out which button to press or which field to fill, they abandon the process. Clear, accessible instructions benefit everyone—not just assistive technology users.

Quick Implementation Guide

1. Always include text labels or names

Every interactive element should have an accessible name that matches or supplements any visual instruction.

<!-- Bad: Shape-only reference -->
<p>Click the circle to continue</p>
<button aria-label="Circle button">○</button>

<!-- Good: Text label included -->
<p>Click the Continue button (circular icon) to proceed</p>
<button>Continue</button>

2. Supplement location references with explicit identifiers

Combine spatial cues with labels, headings, or landmark roles.

• ❌ "Use the search box at the top of the page"
• ✅ "Use the Search box at the top of the page" (where "Search" is the actual label)
• ✅ "Enter your query in the site search field"

3. Provide text alternatives for icon-only buttons

Use aria-label, aria-labelledby, or visible text—not just shape or symbol.

<!-- Bad: Shape-only -->
<button>▶</button>

<!-- Good: Accessible name -->
<button aria-label="Play video">▶</button>

4. Reference form fields by their labels

Always use the actual field label in instructions, not position or appearance.

• ❌ "Enter your name in the first box"
• ✅ "Enter your name in the Full Name field"

5. Use ARIA landmarks and headings for navigation instructions

Structure your page so instructions can reference semantic elements.

• "Complete the Billing Information section below"
• "Navigate to the Help menu in the site navigation"

Relevant WCAG techniques: G96 (textual identification)

Common Mistakes to Avoid

Relying on position alone

"Click the button on the right" or "See the sidebar" fails when users can't perceive layout. Always name the element: "Click the Save button" or "See the Related Articles sidebar."

Shape-only icon references

"Press the triangle to play" or "Click the hamburger menu" assumes users can see shapes. Use "Press the Play button" or "Open the main menu" (with proper aria-label on the icon button).

Size-based instructions

"Select the larger option" or "Click the small print link" doesn't work for screen reader users. Use explicit labels: "Select the Premium plan" or "Click the Privacy Policy link."

Vague directional cues

"See above" or "Click below" can be ambiguous, especially on responsive layouts. Reference specific headings or labels: "See the Installation Steps section above."

How to Test for WCAG 1.3.3

Manual review checklist:

• Read all instructions, help text, and error messages on the page
• Identify any references to shape, size, location, orientation, or sound
• Verify each reference includes a text label, accessible name, or semantic identifier
• Test with a screen reader—can you follow instructions without seeing the page?

Automated tools:

Automated scanners can flag some issues—like icon buttons missing accessible names—but can't fully evaluate whether instructions rely on sensory characteristics. That requires human judgment.

What automation catches:

• Buttons with only icon content and no aria-label
• Images used as instructions without alt text
• Missing form labels that make positional instructions necessary

What requires manual testing:

• Whether instructional text references visual-only properties
• If supplementary identifiers are sufficient
• Context-dependent language like "click here" or "see below"

How TestParty Helps

TestParty's AI-powered accessibility platform detects, flags, and helps remediate WCAG 1.3.3 violations across your codebase—catching sensory-only instructions before they reach production.

What TestParty detects:

TestParty's DOM and source code analysis identifies common 1.3.3 violations automatically:

• Icon-only buttons and links missing accessible names (aria-label, aria-labelledby, or visible text)
• Form controls without associated <label> elements, making positional instructions likely
• Images used as instructional content without alt text
• Interactive elements with generic or missing accessible names (e.g., "button" instead of "Submit")
• ARIA landmarks and heading structures that could support better instruction references

TestParty also uses natural language processing to flag potentially problematic instructional text patterns—like phrases containing "click the icon," "on the right," or "the large button"—for human review.

How TestParty suggests fixes:

For icon buttons and unlabeled controls, TestParty auto-generates code fixes with appropriate aria-label attributes based on context, surrounding text, and common patterns. For example:

• A ▶ button near a video gets aria-label="Play video"
• A ☰ button in the header gets aria-label="Open main menu"
• A form field preceded by "Email address:" gets a programmatically associated <label>

These AI-generated suggestions are reviewed by your team or TestParty accessibility specialists before merging, ensuring accuracy and context-appropriateness.

For instructional text that relies on sensory characteristics, TestParty surfaces the issue with inline guidance and examples of compliant alternatives—helping content authors and developers understand why "click the button on the right" fails and how to fix it ("click the Submit button").

Developer workflow integration:

TestParty integrates directly into your CI/CD pipeline and pull request workflow:

• Pre-merge checks: Block PRs that introduce unlabeled icon buttons or remove accessible names from interactive elements
• IDE annotations: Flag missing aria-label attributes and suggest fixes in real-time as developers write code
• Template-level fixes: For CMS platforms like WordPress and Shopify, TestParty works at the theme and component level—fixing button patterns once and cascading improvements across thousands of pages

This shift-left approach prevents 1.3.3 violations from ever reaching production, rather than discovering them in post-launch audits.

Ongoing monitoring:

TestParty continuously scans your site for regressions:

• Tracks the number of unlabeled interactive elements over time
• Alerts when new content introduces sensory-only instructions
• Generates audit-ready reports showing 1.3.3 compliance status across pages, templates, and components
• Monitors third-party widgets and embedded content that may introduce violations

Dashboards give product and engineering teams visibility into compliance trends, making it easy to prioritize remediation and demonstrate progress to legal, procurement, or accessibility stakeholders.

TestParty's combination of automated detection, AI-assisted remediation, and human oversight ensures your instructions are perceivable and operable for all users—without slowing down your development velocity.

FAQs About WCAG 1.3.3

What is WCAG 1.3.3 in plain language?

WCAG 1.3.3 Sensory Characteristics means you can't give instructions that only work if someone can see shapes, colors, sizes, or positions. For example, "click the round button" fails because a screen reader user can't perceive "round." Instead, say "click the Continue button."

Is WCAG 1.3.3 required for ADA compliance?

Yes. WCAG 1.3.3 is a Level A criterion, which means it's part of the baseline accessibility standard referenced by the ADA, Section 508, and most international regulations. Courts and enforcement agencies expect compliance with all Level A and AA criteria.

Can I use visual cues like "on the right" if I also include a label?

Yes, as long as the label or identifier is sufficient on its own. "Click the Save button on the right" is fine because "Save button" works independently. Just "click the button on the right" fails because there's no non-visual way to identify which button.

Does this apply to mobile apps?

Absolutely. WCAG 1.3.3 applies to mobile apps, especially under WCAG 2.2 and standards like EN 301 549. Instructions like "swipe the card on the left" or "tap the star icon" must include accessible names and labels that assistive technology can announce.

What's the difference between WCAG 1.3.3 and 1.4.1 Use of Color?

WCAG 1.3.3 covers shape, size, location, orientation, and sound—but explicitly excludes color, which is addressed by 1.4.1. Both criteria share the same principle: don't rely on a single sensory characteristic to convey information. You need redundant cues.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.