Checkpoint 1.3.3 Sensory Characteristics

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A)


Instructions that use shape or location to provide context can help many users understand content. However, such sensory characteristics should not be the only means of conveying information when giving instructions, because users who lack the ability to fully use one or more of their senses may not understand the meaning. Providing complementary information beyond sensory details will allow all users to better understand the instructions and context being conveyed.

When elements are described using visual cues such as shape, size, or physical location (e.g., "select the button on the right"), it can make it easier for a sighted user and some people who have cognitive disabilities to locate the elements.  But someone with a visual disability may not be able to perceive those visual cues. The element must also be described in another non-visual way, such as by its label (e.g., "select the Delete button on the right").

It is important to understand that this checkpoint is entirely focused on referencing sensory characteristics in instructions. The reason this checkpoint comes under the Adaptable principle in WCAG is that instructions need to be applicable even if the content is "adapted" (e.g., a screen display without images, or the display is reflowed on a mobile device changing the content positioning).

The simplest way to prevent failures of Sensory Characteristics is to always have a visible text label and reference that label in the instructions.

Note that color, also a sensory characteristic, has a separate checkpoint, Use of Color, that governs its specific use as the only means of distinguishing content. That applies to any reliance on the use of color, and not just references to color in instructions.

Refer to Understanding SC 1.3.3 for more information (external link to WCAG).

Development Techniques

This paragraph appears generically in all checkpoints. Review the General techniques as well as other tabs applicable to your technology.  Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.

General techniques

Any item in this section represents a technique deemed sufficient. Ensure you review WCAG Common Failures to avoid development mistakes.

Note: Examples of sensory language that triggers alerts in the Dynamic Assessment Plug-in (DAP) can be found under rule G502 (internal IBM link).

Web (HTML, ARIA, CSS) techniques

There are no specific Web (HTML, ARIA, CSS) techniques for this checkpoint. Refer to the General techniques section.

Mobile Native (iOS) techniques

There are no specific Mobile Native iOS techniques for this checkpoint. Refer to the General techniques section.

Eclipse techniques

There are no specific Eclipse techniques for this checkpoint. Refer to the General techniques section.

Windows-based (MSAA+IA2) techniques

There are no specific Windows-based (MSAA+IA2) techniques for this checkpoint. Refer to the General techniques section.

Many links in this checklist reside outside at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008:

Copyright © 1994-2019 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.

Copyright © 2001, 2019 IBM Corporation