WCAG 1.3.3: Sensory Characteristics

What This Rule Means

WCAG Success Criterion 1.3.3 — Sensory Characteristics (Level A) states that instructions provided for understanding and operating content must not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. In other words, if your interface tells a user to interact with something by referencing only how it looks, where it appears on the screen, or what it sounds like, that instruction will be meaningless to users who cannot perceive those particular sensory properties.

The key word here is solely. The criterion does not prohibit using sensory references — it prohibits making them the only means of identification. An instruction like "click the round green button on the left" fails when a user cannot distinguish green, cannot see the button's shape, or cannot determine left from right due to a reflow layout. However, "click the Submit button (the round green button on the left)" passes because the text label "Submit" provides a non-sensory identifier that works independently of color, shape, and position.

Instructions affected by this criterion include any text, audio, or visual content that directs users to take an action or locate information. Common failing patterns include:

• "Click the button on the right to continue" — relies solely on visual location.
• "Select the square icon to open settings" — relies solely on shape.
• "The required fields are shown in red" — relies solely on color.
• "When you hear the chime, proceed to the next step" — relies solely on sound.
• "Tap the large tile to expand the section" — relies solely on size.

A passing instruction always includes at least one non-sensory identifier — typically a text label, a programmatic name, or a heading — so that users relying on assistive technology or operating in conditions where sensory cues are unavailable can still follow the directions. Note that this criterion specifically covers instructions; it does not require that every UI element be redesigned, but it does require that any textual or spoken guidance about those elements be perceivable without sensory discrimination.

There are no official exceptions defined within 1.3.3 itself, though the Understanding document clarifies that content which uses sensory characteristics in addition to non-sensory identifiers is fully compliant. The criterion also complements but is distinct from 1.4.1 (Use of Color), which specifically addresses color alone; 1.3.3 has broader scope covering all sensory modalities.

Why It Matters

Sensory-only instructions create hard barriers for a wide range of users. Consider each affected group:

Blind and low-vision users rely on screen readers or magnification software. When an instruction says "click the icon in the top-right corner," a screen reader user navigating by tab order or heading structure has no concept of "top-right corner" in the visual layout. Similarly, a user with severe low vision who has zoomed in to 400% may only see a small portion of the screen at a time, making positional references like "left panel" or "bottom section" completely unreliable. According to the World Health Organization, approximately 2.2 billion people globally have some form of vision impairment, making this one of the largest affected populations.

Color-blind users — affecting roughly 1 in 12 men and 1 in 200 women — cannot distinguish certain color pairs. An instruction reading "fields highlighted in red are mandatory" is invisible as a distinguishing cue to someone with red-green color blindness. While 1.4.1 addresses this for the UI element itself, 1.3.3 ensures the instructional text also provides an alternative.

Deaf and hard-of-hearing users are impacted by audio-only cues. If an e-learning platform instructs users to "proceed when you hear the bell," users who cannot hear the bell are excluded. This pattern appears in interactive presentations, video-based tutorials, and timed assessments.

Users with cognitive and learning disabilities may struggle with directional language, especially when their assistive technology renders content in a linearized form that strips out visual positioning. A person using a switch device or eye-tracking system also navigates in sequences that may bear no relationship to the two-dimensional spatial layout a sighted designer imagined.

Consider a concrete real-world scenario: a Turkish government e-services portal instructs citizens to "fill in the fields outlined in blue and then press the triangular button to submit your application." A blind user navigating by form fields hears field labels via their screen reader but has no way to know which fields are outlined in blue, nor can they identify a button by its triangular shape. The application process is effectively blocked. Adding the actual field labels (e.g., "Name, ID Number, and Date of Birth are required") and the button's text label ("Submit Application") instantly resolves the barrier.

Beyond accessibility, removing sensory-only instructions improves usability for everyone. Responsive designs reflow content so positional references become inaccurate on mobile. Dark mode or high-contrast themes change color rendering. Voice assistants reading page instructions aloud strip all visual context. Building instructions around stable, programmatic labels rather than transient sensory properties makes content more robust across all devices and contexts — a direct SEO and maintenance benefit as well.

Related Axe-core Rules

WCAG 1.3.3 requires manual testing because automated tools cannot reliably interpret the meaning or intent of natural-language instructions. A static analysis engine can detect that a button exists or that a color is used, but it cannot read a paragraph of instructional text, understand that it refers to a button, and then determine whether that reference is exclusively sensory. This is a semantic and contextual judgment that requires human review.

• Manual review required — no dedicated axe-core rule exists for 1.3.3. Axe-core rules such as color-contrast and label may surface related issues (for example, a button with no accessible name), but they address different criteria. For 1.3.3, a human tester must read every instructional sentence on the page, identify any sensory references (shape, color, size, location, orientation, sound), and verify that at least one non-sensory identifier accompanies each reference. Automated tools will not flag a sentence like "click the green button below" as a violation because parsing natural language intent is beyond current rule-based automation.
• Why automation fails here: Consider that "click the large button" contains the word "button," which an automated tool might interpret as referencing an accessible role. But the instruction still relies solely on size ("large") to distinguish this button from others. Automated tools cannot determine whether "large" is the sole distinguishing characteristic or whether there is only one button on the page (making "large" redundant but not harmful). Human judgment is essential to evaluate these nuances in context.
• Complementary axe rules to run alongside manual review: Running color-contrast, label, button-name, and aria-label checks will help ensure that the UI elements being referenced in instructions actually have programmatic names — a prerequisite for writing non-sensory instructions. If a button has no accessible name, no instruction can meaningfully reference it without resorting to sensory cues.

How to Test

1. Run an automated scan first (axe DevTools or Lighthouse): Open the page in Chrome, activate the axe DevTools extension, and run a full-page scan. While no rule maps directly to 1.3.3, review any flagged issues under "color," "label," and "name" categories. These results provide a baseline — if UI elements lack accessible names, instructional text referencing them is almost certainly relying on sensory cues. Export the results and note all interactive elements without programmatic labels.
2. Identify all instructional text manually: Read every sentence on the page that directs a user to take an action or locate information. This includes help text, form hints, tooltips, tutorial overlays, error messages, and onboarding flows. Create a list of each instruction and highlight any sensory references: color words (red, blue, green), shape words (round, square, triangular), size words (large, small, big), positional words (left, right, top, bottom, above, below, corner), orientation words (horizontal, vertical), and sound references (chime, beep, alert sound).
3. Evaluate each sensory reference for additional non-sensory identifiers: For each sensory reference found, determine whether a non-sensory identifier is also present. A non-sensory identifier includes a text label matching the element's visible label or accessible name, a heading, a numbered step, a unique programmatic role, or an ARIA label. If the only way to identify the referenced element is through sensory perception, the instruction fails 1.3.3.
4. Test with a screen reader (NVDA + Firefox): Navigate the page using only the keyboard and NVDA. Tab through all interactive elements and listen to how NVDA announces each one. Then, read the instructional text on the page and ask: could a user hearing only these announcements follow the instructions? If an instruction says "click the icon on the right" but NVDA announces the element as "Settings, button," then the instruction's positional reference is superfluous but the label makes the instruction navigable. If NVDA announces the element as "button" with no name, the instruction relying on visual position fully fails.
5. Test with VoiceOver + Safari (macOS/iOS): Enable VoiceOver and navigate the page. Use the rotor to browse by buttons, links, and form controls. Verify that every element referenced in an instruction is reachable and identifiable by its announced name alone, without relying on its position in the visual layout.
6. Test with JAWS + Chrome: Open the page in Chrome with JAWS active. Use the Forms Mode to navigate inputs and listen to field announcements. Cross-reference with any form-level instructions that use color or position to indicate required fields.
7. Test in high-contrast and dark modes: Switch the operating system to high-contrast mode and reload the page. Color-coded instructions that refer to specific colors may become ambiguous or invisible when color rendering changes. This helps surface hidden reliance on color as a sole sensory cue.
8. Test on a zoomed or reflowed mobile view: Resize the browser window to 320px wide or use a mobile device. Instructions using positional language like "left sidebar" or "top navigation" should still be meaningful when the layout has reflowed to a single column.

How to Fix

Color-Only Form Field Instructions — Incorrect

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Color-Only Form Field Instructions — Correct

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Positional Button Reference — Incorrect

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Positional Button Reference — Correct

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Shape-Only Icon Navigation — Incorrect

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Shape-Only Icon Navigation — Correct

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Audio-Only Progress Cue — Incorrect

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Audio-Only Progress Cue — Correct

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Common Mistakes

• Writing "the red button" or "the green field" as the sole identifier in form instructions or help text, without also providing the button's visible label or the field's name — this fails both 1.3.3 and 1.4.1.
• Using positional phrases like "the menu on the left" or "the panel at the top" in help documentation or onboarding flows without naming the menu or panel, making instructions useless after responsive reflow collapses the layout to a single column.
• Describing icons only by shape ("click the triangular play button") instead of using the icon's accessible name or label, which a screen reader user could actually locate through keyboard navigation.
• Indicating required form fields exclusively through border color or background color in inline instructions ("orange fields must be filled") without a symbol, label suffix, or aria-required='true' attribute to convey the same information programmatically.
• Placing audio-only feedback for interactive processes (file uploads, form submissions, timer expirations) without a corresponding visible text status update using role='status' or aria-live='polite'.
• Using size as the only distinguishing cue — instructions like "click the large card to expand" fail when the user zooms in, when cards render identically sized at smaller viewports, or when a screen reader user has no concept of relative card sizes in the DOM.
• Relying on orientation cues such as "swipe horizontally to navigate" without providing an alternative interaction method and a non-orientation-based label for the carousel or slider being described.
• Forgetting that error messages are also instructions — an error that says "the highlighted fields below contain mistakes" relies on visual highlighting and positional proximity, and will be useless to a screen reader user unless each erroneous field is also named explicitly in the error message.
• Assuming that adding an icon's alt text fixes the instruction — if the instructional prose still only says "click the circular icon," the icon having alt text on the image element does not make the prose instruction conformant; the prose itself must include a non-sensory identifier.
• Neglecting dynamically injected instructions in single-page applications — tooltips, modals, and wizard steps that are injected via JavaScript often contain sensory-only guidance that escapes QA review because they are not visible in a static page audit.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility requirements for a broad range of public and private entities operating in Turkey. The circular mandates conformance with WCAG 2.1 Level AA as the baseline standard, and WCAG 1.3.3 — as a Level A criterion — is therefore fully mandatory for all covered entities.

The entities covered by the circular include public institutions and agencies, e-commerce platforms, banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE). Public institutions must achieve full compliance within one year of the circular's publication date, while private sector entities are given a two-year window.

WCAG 1.3.3 is particularly relevant for Turkish digital services given the widespread use of color-coded form guidance and icon-only navigation patterns in Turkish e-government portals, banking applications, and e-commerce checkout flows. For example, a public institution's online application form that instructs citizens to "fill in the fields marked in red" and submit by "pressing the button in the lower right corner" would be in direct violation of 1.3.3 and would constitute a failure to comply with the Presidential Circular. Similarly, a bank's mobile web interface that guides users through multi-step transactions using only positional and color cues would need to be revised before the two-year private sector deadline.

Non-compliance carries reputational and legal risk as Turkey's regulatory environment around digital accessibility matures. Covered entities should treat 1.3.3 compliance not as a minor editorial fix but as a systemic review of all instructional content — including help text, error messages, onboarding flows, and support documentation — to ensure that sensory references are always accompanied by stable, programmatic, text-based identifiers. Accsible's overlay SDK can assist with surfacing and remediating many related issues, though the manual content review required by 1.3.3 must ultimately be performed by a qualified human auditor working alongside automated tooling.