WCAG 1.3.3 Sensory Characteristics: Common Accessibility Mistakes to Avoid

WCAG 1.3.3 Sensory Characteristics: common accessibility mistakes to avoid

WCAG 1.3.3 requires that instructions do not rely only on sensory characteristics such as colour, shape, sound, size or location. That phrase appears often when auditing interfaces. This article lists frequent errors, shows clear fixes and gives a short retrofitting checklist you can apply today.

What WCAG 1.3.3 means in plain terms

The rule is simple. If you tell a user to “click the red button” or “move the slider to the right”, that instruction must also include a non-sensory cue. Sensory cues alone exclude people who cannot see colour, cannot hear sounds, or who rely on screen readers. The aim is to provide at least one alternative cue that does not depend on senses alone.

Common mistakes and how to fix them

1. Reliance on colour only

Problem: Form errors or status messages marked only by colour. A field goes red when it is invalid and the hint says “fields marked in red are required.”

Fix: Add text labels or symbols. Use explicit words such as “Required” or “Error” near the field. Include aria-live regions for dynamic error messages so screen readers announce them.

2. Instructions that use position or layout only

Problem: A page says “use the button on the right” but the layout rearranges on small screens or when zoomed.

Fix: Use descriptive labels. Refer to the button by name, role or visible text such as “Save draft”. That keeps instructions accurate regardless of responsive layout.

3. Shape or size used as the only cue

Problem: A dashboard shows a small triangle next to items and the instructions say “select items marked with a triangle.” Users with low vision may miss small shapes.

Fix: Pair shape with a text label or hidden accessible name. Ensure the shape is accompanied by the word “Selected” in the accessible name or visible text.

4. Sound used alone

Problem: Notifications play a beep to indicate success or failure. Users who are deaf will miss the cue.

Fix: Provide visible messages and ARIA alerts. Use text that appears on screen and set aria-live so assistive technology announces the update.

5. Touch, vibration or motion used alone

Problem: A mobile app uses vibration to show an action completed and the on-screen feedback is minimal.

Fix: Add textual confirmation. Use labels like “Message sent” and keep them visible long enough to be noticed. Ensure controls have accessible names for assistive tech.

6. Orientation or direction as the only cue

Problem: A tutorial instructs users to “turn the device so the camera is on top.” Some users cannot reorient the device easily.

Fix: Offer alternate instructions that do not require device orientation. For example, provide controls to flip or rotate images instead of asking the user to reposition hardware.

7. Icons without text

Problem: Icons alone tell users what to do. For example a trash can icon signals delete but has no label.

Fix: Add visible text or an accessible name via aria-label or aria-labelledby. Visible text is best because it is clear for everyone.

Where these mistakes show up most

• Forms and validation messages
• Charts, maps and legends
• Interactive widgets such as sliders, carousels and custom selects
• Games and training modules with colour or sound cues
• Notifications and transient status messages

Practical step-by-step retrofit checklist (apply in this order)

1. Find user-facing instructions that name or point to UI items. Search copy, tooltips and help text.
2. For each instruction, ask: Could a user follow this if they could not see colour, hear sound or detect shape? If no, it needs change.
3. Add a non-sensory cue: visible text, explicit label, or an accessible name that describes the control or result.
4. Make dynamic changes screen reader friendly: use aria-live for alerts and update accessible names when state changes.
5. Verify that the instruction still makes sense at different zoom levels, with images turned off, and with high contrast mode.
6. Test with keyboard only and a screen reader. Note any instruction that becomes ambiguous.
7. Validate with at least one real user who has the relevant impairment where possible.

Testing checklist for WCAG 1.3.3

• Turn off CSS colours and see if you can still follow instructions.
• Use a screen reader to navigate to labeled controls. Are labels descriptive and unique?
• Resize, zoom and reflow pages. Do position-based instructions break?
• Mute audio and check whether audio cues have matching text cues.
• Operate the interface with keyboard only. Ensure focus order and labels remain clear.

Decision framework: which alternative cue to use

Use this simple rule. Prefer visible text first. If that is not possible, use an exposed accessible name or label. Only then use additional sensory cues such as colour or sound as a secondary indicator. The goal is to make the primary instruction independent of a single sense.

When visible text is not feasible

Examples include dense data visualisations. In that case provide a text summary or an accessible table that gives the same information. Use aria-describedby to connect the summary to the visual element.

Tricky cases and how to handle them

Charts and maps

Problem: A map legend says “green areas mean parks” and nothing else.

Fix: Add a text legend or a linked list with labels such as “Parks: green areas”. Offer a data table or a machine readable alternative for complex maps.

Custom controls and widgets

Problem: A custom slider uses position and handle shape to show value.

Fix: Expose the value in the accessible name and add keyboard controls. For example the control should say “Volume 40 percent” to assistive technology.

Games, interactive training and visual tasks

Problem: Gameplay requires spotting red shapes within a time limit.

Fix: Provide alternative modes that use text or patterns. Allow time extensions. Offer accessibility settings that let users swap sensory cues for text cues.

Quick examples you can apply now

• Change label copy from “Press the green button” to “Press the green button labelled Save”.
• Show error text next to a field: “Email is required” and do not rely on border colour alone.
• For success sounds, also present a visible banner reading “Upload complete” and mark it with aria-live=“polite”.

Final notes

Fixing sensory-only instructions often takes a few edits to copy and a few ARIA attributes. Focus on clarity. Make the main instruction usable by as many people as possible without extra effort. Then add sensory cues as enhancements, not as the only signal.

Run the testing checklist after changes and include real users in the loop. Small fixes yield big wins for accessibility and reduce help desk requests.