WCAG 1.3.3 Sensory Characteristics — Testing Guide for Mobile & Web Apps

WCAG 1.3.3, "Sensory Characteristics," is a foundational accessibility requirement. It mandates that instructions, labels, and other information conveyed to users must not rely *solely* on sensory cha

Ensuring Sensory Characteristics Compliance: A Developer's Guide to WCAG 1.3.3

WCAG 1.3.3, "Sensory Characteristics," is a foundational accessibility requirement. It mandates that instructions, labels, and other information conveyed to users must not rely *solely* on sensory characteristics like shape, size, visual location, orientation, or sound. This ensures that users with sensory disabilities can understand and interact with your application.

What WCAG 1.3.3 Requires (In Plain English)

Your application cannot depend on a user being able to see a specific color, hear a particular sound, or perceive the physical location of an element to understand critical information or complete a task. If you use a sensory characteristic to convey information, you must provide an alternative method for users who cannot perceive that characteristic.

For example, if a form field is marked red to indicate an error, you must also provide a text-based explanation of the error associated with that field. If a button is described as "the button on the right," you need to provide a more descriptive label that doesn't rely on its position.

Why It Matters: Real User Impact

This criterion directly impacts users with a wide range of disabilities:

• Visual Impairments: Users who are blind or have low vision may not perceive colors or visual locations. They rely on screen readers and other assistive technologies that interpret text and structure.
• Hearing Impairments: Users who are deaf or hard of hearing cannot process audio cues.
• Cognitive Disabilities: Some individuals may have difficulty processing information presented solely through visual cues or spatial relationships.
• Color Blindness: Millions of people have some form of color vision deficiency, making color alone an unreliable indicator.

Non-compliance creates significant barriers. Users may be unable to complete essential tasks, leading to frustration, exclusion, and potential legal ramifications under regulations like the EU's European Accessibility Act (EAA) and the U.S. Americans with Disabilities Act (ADA).

Common Violations and Examples

Here are typical scenarios where WCAG 1.3.3 is violated:

#### Mobile App Violations

1. Color-Only Error Indicators:

• Violation: A form input field turns red when invalid, with no accompanying text.
• User Impact: A colorblind user or someone using a screen reader might not understand why the field is invalid.

1. Location-Based Instructions:

• Violation: "Tap the button on the top right to save."
• User Impact: A user unfamiliar with the app's layout, or one using a screen reader that doesn't focus on visual position, will struggle to locate the button.

1. Audio-Only Cues:

• Violation: A notification sound plays to indicate a successful transaction, with no visual confirmation.
• User Impact: A deaf or hard-of-hearing user will miss this crucial confirmation.

#### Web App Violations

1. Color-Coded Navigation:

• Violation: Menu items are distinguished only by different colors.
• User Impact: Users with color vision deficiencies cannot differentiate between menu options.

1. Shape-Based Controls (without labels):

• Violation: A series of icons (e.g., play, pause, stop) are used without descriptive text labels.
• User Impact: Users relying on screen readers will hear "button" repeatedly, without context to know which action each button performs.

1. Visual Hierarchy without Semantic Structure:

• Violation: Information is presented using varying font sizes and bolding for emphasis, but without proper heading structure (e.g.,

  ,

  ).

• User Impact: Screen reader users may not understand the logical flow and importance of different content sections.

How to Test for Compliance

Testing for WCAG 1.3.3 requires a combination of manual checks and automated tools.

#### Manual Testing Steps

1. Identify Information Conveyed by Sensory Characteristics: Review your app's UI. Note any instances where color, shape, size, location, or sound is the *only* way information is conveyed.
2. Simulate Sensory Impairments:

• Color Blindness: Use browser developer tools (e.g., Chrome's Rendering tab, Firefox's Accessibility Inspector) to simulate different types of color blindness.
• Low Vision: Zoom in on your application significantly (e.g., 200-400%) to see if text remains readable and controls are usable.
• Screen Reader Testing: Navigate your app using a screen reader (e.g., VoiceOver on iOS, TalkBack on Android, NVDA or JAWS on desktop). Pay attention to how instructions, labels, and error messages are announced.
• Audio Disablement: Turn off your device's sound and navigate. Ensure critical information is still conveyed.

1. Verify Alternative Information: For every sensory cue identified in step 1, confirm that an equivalent, non-sensory alternative is present.

• Color: Is there text, an icon with a label, or a pattern alongside the color?
• Location: Is the element described semantically (e.g., "Save button," "Next step") or is its function clear from context?
• Sound: Is there a visual confirmation or a text alert?

#### Automated Tools for Checking

While manual testing is crucial for understanding user experience, automated tools can catch many common violations:

• Browser Developer Tools:
• Chrome DevTools (Lighthouse, Rendering Tab): Can simulate color blindness and inspect element accessibility properties.
• Firefox Accessibility Inspector: Offers color blindness simulation and checks for ARIA attributes.
• Linters and Code Scanners:
• ESLint plugins (e.g., eslint-plugin-jsx-a11y for React) can flag issues like missing alt text or improper ARIA usage.
• HTML validators can report semantic structure issues.
• Dedicated Accessibility Testing Tools:
• axe-core (often integrated into browser extensions like axe DevTools) is highly effective.
• WAVE (Web Accessibility Evaluation Tool) provides visual feedback on accessibility issues.

#### Mobile-Specific Considerations (Android/iOS)

• Android:
• TalkBack: Essential for simulating screen reader behavior. Test with TalkBack enabled and disabled.
• Developer Options: "Simulate color space" allows testing for color vision deficiencies.
• Content Descriptions: Ensure all interactive elements and important images have descriptive contentDescription attributes in XML layouts.
• iOS:
• VoiceOver: The primary screen reader for iOS. Test extensively with VoiceOver enabled.
• Accessibility Inspector (Xcode): Provides detailed information about UI elements, including their accessibility labels and traits.
• Dynamic Type: Ensure text resizes correctly without loss of information or functionality.

How to Fix Violations

The core principle is to provide redundant information.

#### Code Examples

Mobile (Android - Kotlin/XML):

Violation:

<!-- Error field without clear text indicator -->
<EditText
    android:id="@+id/emailInput"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/error_border_red" /> <!-- Red border only -->

Fix:

<!-- Error field with clear text indicator -->
<EditText
    android:id="@+id/emailInput"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/error_border_red"
    android:labelFor="@id/emailInput" />

<TextView
    android:id="@+id/emailError"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:text="Invalid email format. Please enter a valid email address."
    android:textColor="@android:color/red"
    android:visibility="gone"
    android:importantForAccessibility="yes" /> <!-- Crucial for screen readers -->

In your Activity/Fragment, you would programmatically show emailError when validation fails.

Web (HTML/JavaScript):

Violation:

<!-- Button identified only by color and position -->
<button class="action-button primary-color">Next</button>

Fix:

<!-- Button with descriptive label and ARIA -->
<button class="action-button" aria-label="Proceed to next step">
    Next
</button>
<!-- Or, if it's an icon button -->
<button class="icon-button" aria-label="Save changes">
    <i class="fas fa-save"></i>
</button>

For color-coded errors in forms:

Violation:

<input type="text" class="error-field" id="username">
<span class="error-message">Username is required.</span>

Fix:

<input type="text" class="error-field" id="username" aria-describedby="username-error">
<span id="username-error" class="error-message" role="alert">Username is required.</span>

The aria-describedby attribute links the input to its error message, and role="alert" informs screen readers that this is an important, time-sensitive message.

How SUSA Checks This Criterion

SUSA autonomously explores your application and is designed to identify violations of WCAG 1.3.3 through its persona-based testing and advanced analysis:

• Persona-Based Exploration: SUSA employs personas like "Curious," "Novice," and "Accessibility" users. The "Accessibility" persona specifically probes for sensory dependencies. For instance, it will attempt to navigate and understand content with color vision simulations active and with audio cues disabled.
• Dynamic Testing: During its exploration, SUSA identifies interactive elements and the information they convey. It checks if these conveyances rely solely on visual properties (like color or position) or auditory cues.
• Flow Tracking & Analysis: SUSA tracks user flows (e.g., registration, checkout). If a step in a flow is dependent on a sensory characteristic, SUSA flags it as a potential friction point or failure.
• Specific Checks:
• Color Reliance: SUSA analyzes elements that use color for status indication, error reporting, or differentiation. It verifies the presence of associated text labels or other non-color-based indicators.
• Auditory Cues: It detects if critical feedback or notifications are delivered solely through sound.
• Positional Dependence: SUSA