Understanding WCAG SC 1.3.3: Sensory Characteristics (A)

I. Introduction to SC 1.3.3: Context and Mandate

1.1. The Critical Role of Sensory Characteristics in Digital Interaction

The Web Content Accessibility Guidelines (WCAG) 2.x framework is organized into four foundational principles: Perceivable, Operable, Understandable, and Robust. Success Criterion (SC) 1.3.3, known as Sensory Characteristics, is housed within Principle 1 (Perceivable) and Guideline 1.3 (Adaptable). The concept of adaptability is central to this guideline, aiming to ensure that content can be successfully presented to users in different modes without any resulting loss of information or structure. Many digital interaction instructions inherently rely on visual attributes such as color, shape, or location, which are unavailable or misinterpreted by users relying on assistive technologies (AT) or experiencing various forms of disability. SC 1.3.3 addresses this dependency by mandating that critical information is conveyed via adaptable means, such as programmatic text, rather than being confined to ephemeral sensory cues.

1.2. Success Criterion 1.3.3: Definitive Statement and Level A Conformance

As a foundational accessibility requirement, SC 1.3.3 requires Level A conformance, meaning its fulfillment is mandatory for achieving basic accessibility across digital content. The official statement for the criterion is explicit: "Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound".

This success criterion is fundamentally a requirement for instructional redundancy that bridges the gap between the visual or auditory presentation and the programmatic or textual representation. Compliance is not simply achieved by altering the visual interface, but by guaranteeing that the user instructions are comprehensible without reliance on human perception of those cues. This establishes a critical link between the content authorship of the instructions and the technical development of the element, which must expose an accessible name or text description for AT consumption.

1.3. The Intent of the Success Criterion: Ensuring Programmatic Access to Information

The primary intent of SC 1.3.3 is to ensure that all users can access and understand instructions necessary for operating the content, even when they cannot perceive visual attributes like shape or size, or utilize spatial location information. Some content design relies on spatial knowledge not conveyed by the content structure itself, such as referring to a "round button" or the "button to the right." Since many users with disabilities are unable to perceive shape or position, often due to how their assistive technologies process content, this criterion requires that additional information be provided to clarify instructions dependent on sensory data.

Crucially, the rule does not prohibit the use of sensory cues; rather, it forbids relying on them solely. Designers are encouraged to use shape and location as effective aids, particularly for users with cognitive limitations, but the information must also be conveyed through other, non-sensory methods. For example, a passing instruction might reference a textual name or label, rather than just "the button to the right". Furthermore, the scope of "instructions" is broad; it covers not only explicit tutorial blocks but also navigational guidance, form field requirements, and implicit communication through status indicators or error messages. Auditing for 1.3.3 requires examination of the entire user flow, not just explicit instructional text.

1.4. Definition of Sensory Characteristics and Exclusions

The core characteristics covered by SC 1.3.3 are shape, size, visual location, orientation, and sound. These attributes are generally difficult for screen readers or magnification software to reliably translate to a non-visual user experience.

An important note clarifies the overlap with other guidelines: requirements related to color are primarily addressed by Guideline 1.4, specifically SC 1.4.1 (Use of Color). However, if color is used as the sole means of conveying information in an instruction (e.g., "click the green button"), it can trigger a 1.3.3 failure if a textual alternative is missing.

Regarding physical interfaces, WCAG was designed to apply specifically to controls displayed on a web page. Instructions for operating physical hardware (like a web kiosk) that describe tactile cues (e.g., "the arrow shaped key") are explicitly not intended to be prevented by this success criterion.

Table I synthesizes the WCAG SC 1.3.3 requirements across the defined sensory scope.

Table I: WCAG SC 1.3.3 Sensory Scope and Conformance Requirement

II. Impact Assessment and User Benefits

2.1. Accessibility Imperatives: Beyond Visual and Auditory Cues

Compliance with SC 1.3.3 significantly enhances the overall Perceivability of web content. By ensuring that instructions for using web content are not based solely on visual or auditory characteristics, the content becomes accessible to a far broader audience, including those who rely on alternative methods of interaction. The principle applied here is that if a user cannot rely on sight or hearing, the content must convey the same information structurally or programmatically.

2.2. Benefits for Users with Visual Disabilities (Blindness, Low Vision)

People who are blind or have low vision are the primary beneficiaries of this criterion, as they cannot rely on visual details, such as shape, size, or location, to follow instructions.

Assistive technology (AT) users, particularly those relying on screen readers, navigate the digital environment based on programmatic structure—headings, landmarks, lists, or form fields—rather than visual layout. Positional references, such as "see sidebar to the left of the illustration," are useless when the AT processes content linearly. For an instruction like "Click the Next button" to pass 1.3.3, the referenced element must expose its accessible name ("Next") programmatically (an intersection with SC 1.3.1 and 4.1.2). A failure in programmatic naming guarantees a corresponding failure in instructional clarity if the instruction relies on that missing programmatic data point.

The requirement for descriptive text also addresses the fragility of visual design. Users with low vision frequently rely on capabilities such as resizing text up to 200% or switching to high-contrast modes. Content resizing and reflow can radically shift the visual location of elements, rendering instructions like "the link in the upper-right corner" unreliable, which is a common failure (F14). Compliance with 1.3.3 protects against this layout fluidity by anchoring instructions to descriptive names that persist regardless of visual presentation.

2.3. Benefits for Users with Cognitive and Learning Disabilities

Clear, non-sensory instructions are highly beneficial for users with cognitive impairments or learning disabilities, as they reduce ambiguity and cognitive load. Vague instructions that reference an "arrow icon" or "the large button" increase the burden on the user to interpret context, shape, and size.

The provision of textual descriptions alongside sensory characteristics is considered an effective method for many users, including those with cognitive limitations, by offering multiple routes to comprehension. By ensuring that elements are labeled explicitly, rather than vaguely referenced by position, the likelihood of error and confusion is minimized.

2.4. Enhancing Operability for Keyboard and Assistive Technology Users

Users who rely on keyboard navigation, voice control, or other alternative input methods require elements to be explicitly and programmatically identifiable to interact with them effectively. If an instruction dictates "Click the big button," a non-visual or keyboard-only user has no predictable method to target that element unless the "big button" also has a programmatically available accessible name, such as "Submit" or "Continue." Describing elements beyond their sensory traits ensures operability for all input mechanisms.

III. Scoping SC 1.3.3: Boundary Conditions and Related Criteria

3.1. Delineating the Scope: Instructions for Understanding and Operating Content

SC 1.3.3 is explicitly focused on instructions provided to the user. Elements that are purely decorative, or where sensory characteristics are integral and not instructional (such as the shape and color of a company logo), are generally outside the scope of this criterion, provided they do not convey operational information.

Contextual references are permitted when they are unambiguous. For instance, in certain languages, it is commonly understood that "above" refers to content preceding that point in the reading order, and "below" refers to content following it. In such cases, phrases like "choose one of the links below" or "all of the above" conform, assuming the content being referenced is in the correct place in the document order and the reference is clear.

3.2. Technical Nuance: SC 1.3.3 vs. SC 1.4.1 (Use of Color)

WCAG explicitly mandates that color requirements should generally refer to Guideline 1.4. However, the distinction between SC 1.3.3 and SC 1.4.1 is crucial for comprehensive accessibility implementation.

3.2.1. SC 1.4.1 Focus: Visual Alternatives for Color (Level A)

SC 1.4.1 requires that color must not be the sole visual means of conveying information, indicating an action, or distinguishing an element. Compliance here is often met by providing another visual cue, such as shape, size, underlining, or text. For example, required fields marked in red (color) must also be marked with an asterisk (*) (shape/text). This addresses users with color blindness.

3.2.2. SC 1.3.3 Focus: Programmatic Alternatives for All Sensory Cues (Level A)

SC 1.3.3 is broader, covering shape, size, location, and sound, and focuses specifically on the content of the instructions. While 1.4.1 is satisfied if a red required field visually includes an asterisk, 1.3.3 checks the instructional clarity. If the instruction states, "fill in the required fields highlighted in red," the instruction fails 1.3.3 because it relies solely on color and location to describe the requirement, irrespective of whether the asterisk is visually present or not.

The fundamental difference lies in their focus: 1.4.1 addresses the visual presentation of the information (color redundancy), while 1.3.3 addresses the instructions used to describe or reference that element (programmatic/textual redundancy). SC 1.3.3 effectively acts as a compliance multiplier: a failure to comply with 1.4.1 may be remediated visually, but if that flawed visual cue is then referenced in the site instructions, it creates a 1.3.3 failure, demanding the textual (G96) remediation. The textual label serves as the necessary universal programmatic anchor.

3.3. Situations where Sensory Information is Permissible

Sensory characteristics are not discouraged outright, as they provide valuable cues, particularly for users with cognitive limitations. The criterion is met when the sensory description is supplemented by sufficient textual or programmatic identification. A successful example of compliance is an instruction stating, "To move to the next section of the survey, select the green arrow icon labeled 'Next' in the lower right corner below the last survey question." This instruction uses position and color to assist identification but does not rely solely on them, as it provides the explicit text label, 'Next'.

IV. Analyzing Normative Failures and Common Pitfalls

Auditors and developers must be aware of the specific failure modes defined by the W3C that violate SC 1.3.3. The two most critical are F14 (location/shape) and F26 (graphical symbols).

4.1. Failure F14: Relying Solely on Shape or Location

Failure F14 occurs when content is identified exclusively by its visual shape or spatial location. This reliance is problematic because users with visual disabilities cannot locate content described positionally. Furthermore, the location of content is inherently unstable; it can vary significantly if the page layout changes due to variations in font size, window size, or screen size (e.g., mobile reflow breaks positional consistency).

4.1.1. Examples of Location Reliance (Failure Scenarios)

Positional references that fail SC 1.3.3 include:

• Instructions stating, "To go to next page, press the button to the right".
• Contextual guidance in an article stating, "Please see sidebar to the left of the illustration for links to additional information".

In the latter scenario, an assistive technology user would have extreme difficulty finding the illustration and the referenced sidebar because their navigation is structural, not spatial.

4.1.2. Remediation Strategy for Positional References (G96 application)

Remediation requires providing a programmatic anchor. This can be achieved by including the list of links directly within the main text, providing an in-page link that directs the user to the sidebar, or, most effectively, by providing a heading for the sidebar that can be used for structural navigation and then referring to that heading in the instructions (Technique G96).

4.2. Failure F26: Using a Graphical Symbol Alone to Convey Information

Failure F26 is triggered when a graphical symbol, glyph, or icon is used as the sole method to convey information or instructions. This applies to visual elements that represent concepts but are not standard text characters, such as an image of a red circle with a line through it, or an icon representing a check mark or arrow.

4.2.1. Analysis of Ambiguous Glyphs and Icons

The meaning of graphical symbols, even commonly understood ones (like a shopping cart or a hamburger icon), can be obscured for non-sighted users if they lack a textual or programmatic alternative. If an element like an image button omits the alt attribute, it fails SC 1.1.1, which guarantees a subsequent 1.3.3 failure if the instructional text references the visual cue ("click the trash can icon") without the programmatic description.

4.2.2. Failure Example: Icon-Only Status Indicators

A clear example of F26 involves status indicators. If an e-commerce site uses two glyphs—a circle to mean "in stock" and a square to mean "on back order"—and the instructions refer only to the shape, an AT user cannot determine the item's status. Remediation requires providing text alternatives, such as explicitly labeling the statuses "In Stock" and "Backordered," either visually or programmatically.

Table II summarizes these essential failure modes.

Table II: WCAG 1.3.3 Failure Modes (F14 and F26)

V. Techniques for Compliance: Providing Textual Identification (G96)

The primary and sufficient mechanism for achieving compliance with SC 1.3.3 is defined by the W3C as Technique G96.

5.1. Technique G96: The Foundational Requirement for Textual Identification

The objective of Technique G96, "Providing textual identification of items that otherwise rely only on sensory information to be understood," is to ensure that elements referenced in the content are identified in ways that are independent of sensory perception. This typically means describing the item by its function or its textual label. G96 is the core strategy for addressing all sensory dependencies, including shape, size, location, and sound.

5.2. Practical Compliance Scenarios and Instructional Design

Good content strategy is inextricably linked to technical accessibility compliance under 1.3.3. The wording of the user instructions is a determinant of conformance.

5.2.1. Form Instructions: Replacing Sensory Cues with Explicit Text Labels

Instructions referencing visual state must be supplemented with a non-sensory cue.

• Failure Example: "Fill in the fields highlighted in red".
• G96 Compliance: "Fill in the required fields, marked with an asterisk (*)".

This remediation simultaneously addresses the instruction and the visual presentation (if the asterisk is visually present, it helps meet 1.4.1). Developers must ensure that the visual instruction matches the programmatic state; for example, if an instruction refers to a "required field," that field must also expose the required attribute or aria-required="true" to assistive technologies.

5.2.2. Navigation Instructions: Referencing Headings and Labels instead of Location

Ambiguous positional language must be replaced by descriptive identifiers.

• Failure Example: "Click the button on the right".
• G96 Compliance: "Click the 'Next' button," which references the accessible name/label.

An advanced example provided by the G96 technique involves navigational blocks: "Use the list of links to the right with the heading, 'Class Listing' to navigate to the desired on-line course." This instruction leverages location (to the right) but anchors the reference using a unique textual element (the heading 'Class Listing'), guaranteeing identification for screen reader users. By penalizing reliance on size or location, SC 1.3.3 encourages designers to move away from abstract, context-dependent user interfaces toward standardized, function-based labeling, supporting universal design principles by improving discoverability and predictability.

5.2.3. Audio Content: Providing Text or Visual Alternatives for Sound Cues

When sound is used as a sole characteristic for an instructional prompt or status indicator (e.g., "A chime means success"), it constitutes a 1.3.3 failure. Compliance requires that a simultaneous text or visual alternative, such as an on-screen message ("Success!"), is provided, ensuring users who are deaf or deaf-blind are not reliant on the auditory cue alone.

VI. Technical Implementation: Code-Level Solutions and Patterns

Robust compliance with G96 requires developers to integrate accessibility metadata for controls that are visually dependent on sensory characteristics.

6.1. Semantic HTML and Descriptive Labeling

The most straightforward method for 1.3.3 compliance is leveraging native HTML semantics:

1. Using <label> elements: Linking a visible <label> to its form input via for and id provides the explicit textual identification that assistive technologies require.
2. Visible Button Text: Using descriptive text within <button> elements (e.g., <button type="submit">Sign up</button>) ensures the function is conveyed explicitly, directly satisfying G96 when referenced in instructions.

6.2. Advanced Solutions for Iconography (Icon-Only Components)

Icon-only buttons rely entirely on shape/visual appearance, making them high-risk candidates for F26 failure if they lack programmatic text.

6.2.1. Employing aria-label for Accessible Naming

For functional icons that lack visible text, the aria-label attribute provides the required programmatic name without altering the visual design. For example, a search icon on a button would need aria-label="Search". The instruction "Press the 'Search' button" is then satisfied by the aria-label.

A critical architectural consideration is the choice between aria-label and other techniques. If a button already has visible text, using aria-label that conflicts with or replaces the visible text violates SC 2.5.3 (Label in Name). Furthermore, while efficient, reliance on aria-label for naming components that are visually distinct relies on developers consistently maintaining two separate pieces of information (the icon and the invisible label).

6.2.2. Best Practice: Visually Hidden Text (sr-only) Technique

A highly resilient alternative is the visually hidden text technique, commonly implemented using a class like sr-only (screen reader only). A <span> containing the descriptive text is placed within the element and hidden visually using specific CSS properties (absolute positioning, clipping, or fixed dimensions of 1x1 pixel). This ensures the label is structurally tied to the element in the Document Object Model (DOM), minimizing the risk of the label becoming decoupled from the visual component during maintenance or localization, arguably offering greater compliance resilience.

6.3. Code Walkthroughs: Implementing Accessible Icon Buttons

Compliance requires ensuring the accessible name is available, especially when sensory cues are used.

• Failure Example (F14/F26): Image Button without Alt Text or Label

<button>
  <img src="submit-icon.png">
</button>

• Success Example 2: Icon Button with ARIA Label (G96 Compliance)

<button type="button" aria-label="Open Navigation Menu">
  <svg class="hamburger-icon" aria-hidden="true" focusable="false">...</svg>
</button>

• Success Example 3: Button with Visually Hidden Text (G96 Compliance)

<button type="button">
  <span class="icon-search" aria-hidden="true"></span>
  <span class="sr-only">Search</span>
</button>

The principle of "don't rely solely" also applies to the technology used for layout. Since CSS layouts can be fragile and content can reflow (rendering instructions based on location unreliable), SC 1.3.3 implicitly discourages reliance on positional hints, regardless of technology used (e.g., CSS Grid or Flexbox). Developers must prioritize descriptive, function-based text over positional cues, as AT users rely on the document order rather than visual placement.

VII. Auditing, Testing, and Verification Protocols

SC 1.3.3, being rooted in the contextual clarity of instructions, requires significant manual review, as automated tools cannot interpret the descriptive language used by human authors.

7.1. The Critical Role of Manual Testing in 1.3.3 Compliance

Automated tools like WAVE or Lighthouse are highly effective at identifying underlying technical issues, such as missing alt text or unassociated form labels. However, these tools cannot assess whether a tutorial's narrative relies solely on sensory cues (e.g., an instruction written as, "Click the red button at the bottom of the form"). Therefore, a comprehensive accessibility evaluation must include a mandatory manual review to verify instructional clarity.

This reliance on manual review indicates that 1.3.3 is a test of human judgment regarding content design, not simply code correctness. The audit depends on assessing whether the instruction remains clear if the sensory information is mentally removed.

7.2. Step-by-Step Manual Audit Process

A rigorous audit protocol involves:

1. Reviewing all Instructions: The auditor must read every instruction provided for understanding or operating the content on the page.
2. Identifying Sensory References: Any reference to color, shape, size, orientation, or visual location must be flagged.
3. Verifying Text Alternatives: For every flagged sensory reference, the instruction must be verified to ensure it includes a corresponding text alternative. A successful score is assigned if the instruction provides both a sensory element and a text alternative (e.g., "Click the round 'Submit' button"). Failure occurs if the instruction contains a sensory cue but provides no corresponding text alternative (e.g., "Click the button to the right").
4. Simulating Screen Reader Experience: The auditor must use a screen reader (such as NVDA or ChromeVox) to navigate the referenced element. This verifies that the AT announces the correct accessible name that corresponds to the instruction's textual label.
5. Verification of Audio/Video Instructions: Any instruction conveyed solely by auditory means must be checked for a synchronized, equivalent visual or text alternative.

7.3. Utilizing Automated and Semi-Automated Tools

While automated tools cannot assess the content writing of the instructions, they are essential for identifying the structural deficiencies that underlie F14 and F26 failures. Automated checks flag missing labels or poor link text, prompting the human auditor to trace how these deficiencies translate into instructional reliance on sensory cues. The automated output facilitates the human evaluation process.

VIII. Conclusion and Path Forward

SC 1.3.3, Sensory Characteristics, is a foundational Level A requirement under the Perceivable principle of WCAG 2.x. It enforces a principle of instructional independence, requiring authors and developers to decouple operational guidance from transient sensory dependencies like shape, size, location, or sound. By demanding textual or programmatic redundancy (Technique G96), this criterion ensures that instructions remain accessible and functional regardless of how the content is visually rendered or whether the user relies on assistive technology.

Compliance with SC 1.3.3 necessitates close collaboration between content strategy and technical development. Remediation for this criterion often involves fixing the source of information (the element's programmatic name) and then validating that the instructional text accurately refers to this new, descriptive name. This cross-functional requirement makes 1.3.3 conformance a strong indicator of an organization's overall integration of accessibility into its design workflow.

Strategic Recommendations

1. For Content Managers and UX Designers: Instructional text must prioritize the element's explicit, unique textual name (label, heading, or visible text) over sensory cues. Instructions such as "Click the blue icon" should be replaced with "Click the 'Help' icon" or "Click the button labeled 'Submit.'"
2. For Developers: Prioritize semantic HTML and visible text labels. When forced to use icon-only designs or graphical symbols (e.g., for status indicators), ensure rigorous implementation of programmatic alternatives (aria-label, aria-describedby, or sr-only text) to provide the necessary textual identification required by G96, thereby preempting F14 and F26 failures.
3. For Auditors and Quality Assurance: Adopt a mandatory manual testing protocol. This requires pairing instructional text review with screen reader verification to confirm that every element referenced by a sensory characteristic possesses a robust, programmatically exposed name that is consistent with the instruction.