This post is part of a series where we explain Web Content Accessibility Guidelines (WCAG), an internationally recognized standard for measuring website accessibility. For more posts in this series, visit our Web Accessibility WCAG 2 Knowledge Base.
When a webpage is designed visually, instructions such as “click the button on the right” or “select the circular icon” may seem clear. However, users who cannot see the page layout, distinguish shapes or colors, or perceive sound may not understand directions based only on sensory cues.
That’s where WCAG Success Criterion 1.3.3: Sensory Characteristics comes in. 1.3.3 Sensory Characteristics requires that instructions for understanding and operating content do not rely solely on characteristics such as shape, color, size, visual location, orientation, or sound.
Whether you’re adding instructions to a WordPress form, guiding users through an interactive feature, or describing controls in the WordPress admin, following WCAG 1.3.3 helps ensure that everyone can identify and use the correct elements.
In this article, we’ll explain what WCAG Success Criterion 1.3.3 requires, why it matters for WordPress websites, common implementation mistakes, and practical ways to ensure your content is understandable for everyone.
What is WCAG 1.3.3 Sensory Characteristics?
WCAG Success Criterion 1.3.3 Sensory Characteristics (Level A) states:
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.
Web Content Accessibility Guidelines 1.3.3
In plain terms: Users should never have to rely only on visual or auditory cues to complete a task. Instructions should include descriptive information that can be understood regardless of how someone perceives the content. This criterion applies to content such as:
- Forms
- Interactive widgets
- Image hotspots
- Maps
- Dashboards
- Charts and diagrams
- Multi-column layouts
- Step-by-step instructions
The objective is to guarantee that instructions are comprehensible without relying on sensory cues, making them accessible to all individuals, including screen reader users, those with low vision, people with color blindness, and individuals with hearing impairments.
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Why WCAG 1.3.3 Matters for WordPress Websites
Who the criterion applies to
Many websites provide instructions to users, and instructional content is one of the top places where this success criterion becomes relevant.
For example, if your website is for a WordPress plugin or theme, then you likely have documentation that explains how to use your product. But 1.3.3 Sensory Characteristics is relevant beyond software documentation and knowledge base websites. Other examples of websites that need to pay attention to this criterion include:
- Government websites with instructions for completing applications, finding information on a page, or navigating online services.
- Banking and financial websites, which often have step-by-step instructions for transfers, payments, account setup, or locating controls.
- Healthcare and patient portals with instructions for scheduling appointments, viewing results, completing forms, or finding information.
- University and college websites, which include registration, financial aid, application, and student portal instructions.
- E-commerce websites, which may have instructional pages for refund or return requests.
- Online learning platforms with course instructions that refer to buttons, icons, diagrams, or content positioned above/below the video.
- DIY and how-to websites if there are instructions that reference diagrams with depicting steps or parts of a product.
- Any website or blog post with charts, maps, and infographics accompanying text.
Where problems can come from
On websites like these, authors often write instructions like “Click the green button to get started” or “See the information in the chart to the right.” When writing a text description on a graph, they may say something like, “The squares denote X and the circles represent Y.”
These directions may seem perfectly clear to sighted users, but they can become confusing or meaningless for people using assistive technologies, zooming their browser, viewing the page on a mobile device, or experiencing different page layouts.
What Conformance to 1.3.3 Ensures
Meeting this success criterion helps ensure users can understand instructions regardless of whether they access content visually, auditorily, or through assistive technologies.
Conformance particularly benefits:
- Screen reader users
- People with low vision
- Users who magnify content
- People with color blindness
- Users with cognitive disabilities
- Deaf or hard-of-hearing users when audio cues are involved
Removing sensory characteristics from instructions or references makes it easier for all people to complete the tasks you want them to complete on your website, and ensures your content can be understood by everyone.
Common WCAG 1.3.3 Failures
Instructions fail WCAG 1.3.3 Sensory Characteristics when they rely entirely on a user’s ability to perceive location, color, shape, appearance, or sound. Here are some common examples and how to improve them.
Referring Only to Location
Avoid:
Click the button on the right.
Why it fails: The button’s location may change on smaller screens (like mobile phones), and users who cannot perceive the visual layout may not know which button the instruction references.
Use instead:
Select Continue to proceed to the next step.
Referring Only to Color
Avoid:
Complete the fields highlighted in red.
Why it fails: Users who are colorblind or who use high-contrast settings may not perceive the color distinction.
Use instead:
Complete all fields labeled Required.
You can still use color as a visual cue, but labels, text, or other indicators must also identify the required fields.
Referring Only to Shape or Appearance
Avoid:
Select the square button.
Why it fails: This instruction assumes users can see and distinguish the controls by their visual appearance.
Use instead:
Select the Settings button.
Identify controls by their accessible name or purpose rather than relying only on their shape.
Referring Only to Sound
Avoid:
Wait until you hear the beep before continuing.
Why it fails: Users who are Deaf or hard of hearing, have muted their device, or cannot play audio may miss the signal.
Use instead:
Continue when the Upload complete message appears.
When sound communicates important information, provide a visible or textual indicator conveying the same information.
How to Meet This Success Criterion in WordPress
When writing instructions in WordPress, use descriptive names or labels to identify controls and content. You can include sensory details as supplemental information, but users should not need those details to understand what to do.
Describe Controls by Name
Refer to buttons, links, and form controls using their visible label or accessible name.
Avoid:
Click the button below.
Use instead:
Select Submit.
Naming the button tells users exactly which control to select, regardless of its position on the page.
Avoid Location-Based Instructions
Responsive WordPress layouts frequently reposition content based on the user’s device, screen size, or zoom settings. Something may be on the left or right on a desktop computer, but will move above or below on a mobile phone.
Avoid relying only on phrases such as:
- On the right
- Above
- Below
- To the left
Use instead:
Select Download Report in the Reports section.
You can mention a control’s location, but you should also provide its name or other identifying information. If you know that the element is lower down in the HTML (DOM), then it may be appropriate to say “following” or below in that context, but it is important to reference accessible names or related headings, when possible.
Don’t Depend on Color Alone
If form fields require attention, combine color with text, icons, or another indicator.
Avoid:
Fix the fields in red.
Use instead:
Fix all Invalid fields below.
You may also mark required fields with an asterisk, provided its meaning is explained, and the required status is programmatically available to assistive technologies.
Provide Context for Icons
When instructions reference an icon, include the control’s name or purpose.
Avoid:
Click the gear icon.
Use instead:
Click the Settings button (gear icon).
Users can identify the control by its name even if they cannot see or recognize the icon.
Testing WCAG 1.3.3 Compliance in WordPress
Automated testing limitations
While many WCAG success criteria can be tested with automated testing tools like Accessibility Checker, some require manual testing. This criterion is an example of one that requires human review.
Current automated accessibility tools cannot reliably determine whether an instruction depends on a sensory characteristic. As a result, testing WCAG 1.3.3 requires a human to review the words used to explain how to complete a task or find content.
How to Manually Test for Sensory Characteristics
Start with WordPress pages and features most likely to contain instructions, including:
- Contact, registration, and checkout forms.
- Error and validation messages.
- Buttons, links, and icon-based controls.
- Pop-ups, sliders, and interactive blocks.
- Help text and tutorials.
- Audio and video content.
- Charts, diagrams, and infographics.
- Instructions added by themes or plugins.
Remember to check reusable content, such as block patterns, template parts, widgets, and plugin-generated forms. An inaccessible instruction in a reusable element may appear across multiple pages.
Step-by-step manual testing instructions
1. Find Instructions That Use Sensory Language
Review the page for words describing an element by its appearance, position, or sound. Browser search can help you locate terms such as:
- Above, below, left, or right
- Red, green, blue, light, or dark
- Round, square, large, or small
- Arrow, circle, or icon
- Beep, tone, or sound
- Portrait, landscape, horizontal, or vertical
These words do not automatically create a failure. They become a problem when the sensory characteristic is the only way to identify the referenced content or control.
2. Remove the Sensory Detail
For each instruction, mentally remove the reference to location, color, shape, size, orientation, or sound. Then ask: Can users still identify the correct element and understand what to do?
For example, consider the instruction:
Select the green button on the right.
If removing “green” and “on the right” leaves only “Select the button,” users do not have enough information. The instruction should identify the button by name:
Select the green Submit button on the right.
This version can still mention color and location, but users do not need those details to identify the control.
3. Compare Instructions With Visible Labels
Make sure the name used in the instructions matches the label users encounter on the page.
If the instructions say “Select Continue,” confirm that the button is actually labeled Continue. Avoid referring to a button as “Continue” when its visible label says Next Step.
For icon-only controls, confirm that the control has an accessible name and use that name in the instructions. For example:
Select Settings rather than “Select the gear icon.”
4. Change the Page Layout
View the page at 200% and 400% browser zoom, then compare the desktop and mobile layouts. Also, test both portrait and landscape orientations when appropriate.
Look for instructions that become inaccurate when WordPress blocks, form fields, buttons, or sidebars move to new positions. Phrases such as “use the form on the right” may no longer make sense when the form moves below the content.
5. Remove Color and Sound as Clues
Review the page without relying on color differences. You can use grayscale display settings, high-contrast mode, or simply confirm that every color-based instruction includes a text label or another clear identifier.
Mute your device when testing instructions involving audio. Important actions and status changes should remain understandable without hearing a beep, tone, or spoken direction.
6. Test the Complete Task
Follow the instructions from beginning to end. This is especially important for forms, checkout processes, account registration, and plugin-generated workflows.
At every step, confirm that users can:
- Identify the referenced content or control.
- Understand the required action.
- Recognize errors and required fields.
- Determine when an action has been completed.
- Continue without relying solely on visual position, appearance, or sound.
A screen reader can provide additional insight, but it is not required to identify every WCAG 1.3.3 failure. The most important test is whether each instruction remains understandable when its sensory cues are unavailable.
Don’t know how to use a screen reader? Learn how with our self-paced screen reader testing online courses.
Start Making Your WordPress Site More Inclusive
WCAG 1.3.3 Sensory Characteristics helps ensure instructions are understandable for everyone, regardless of how they perceive or interact with content.
Making instructions accessible does not require removing visual or auditory cues from your design. Instead, pair those cues with clear text identifying each control or action by name. A button can still be green or positioned on the right, for example, as long as the instructions also reference its visible label, such as Submit. Important sounds should have visible alternatives, and icon-only controls should have descriptive accessible names. These small changes help everyone understand what to do, regardless of how they perceive or navigate the page.
As you review your website, ask yourself one simple question: If someone couldn’t rely on color, position, size, shape, orientation, or sound, would these instructions still make sense? If the answer is yes, you’re well on your way to meeting WCAG Success Criterion 1.3.3 and creating a more accessible web experience.
