Does your website need to meet WCAG 2.1 Success Criterion 1.3.6, “Identify Purpose,” to be accessible?
In short, no — but meeting this requirement can make your site more accessible. Below, we’ll briefly explain how the Web Content Accessibility Guidelines (WCAG) are structured, then provide tips for improving conformance with the “Identify Purpose" standard.
For more specific guidance, send us a message to connect with a subject matter expert.
WCAG Level AAA criteria are helpful, but not necessarily essential
WCAG is organized into three conformance levels: Level A (the least strict requirements), Level AA, and Level AAA (the most strict requirements). Read more about the differences between WCAG conformance levels.
Websites that meet the Level AA standards are considered reasonably accessible for most users with disabilities. Additionally, Level AA conformance is considered sufficient for meeting most digital accessibility laws (including Title III of the Americans with Disabilities Act).
WCAG Success Criterion 1.3.6, “Identify Purpose,” is a Level AAA criterion. You don’t need to pass this guideline to meet your digital compliance goals — but if you can easily follow the requirement, you should still do so. Remember, digital accessibility improves the online experiences of real-life users, and if you’ve got an opportunity to make an improvement, it’s a good idea to take that step.
With that in mind, let’s take a closer look at “Identify Purpose.”
How WCAG’s “Identify Purpose" Improves Accessibility
Here’s the full text of WCAG 2.1 SC 1.3.6:
“In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined.”
This criterion is similar to WCAG 2.1 SC 1.3.5, “Identify Input Purpose,” which is a Level AA requirement. However, SC 1.3.6 goes further — it’s not restricted to input fields.
This benefits accessibility by making icons, buttons, links, regions, and other elements more perceivable for a wider range of users. People with disabilities may personalize the presentation of web pages by changing their web browser preferences.
Let’s consider an example: Imagine that you’re buying a product from a Japanese website, and you don’t speak Japanese. The website uses an icon to indicate that the product is available, but it’s not a symbol that you recognize. If the page contains appropriate semantic markup, you may be able to adjust your web browser settings to replace the symbol with one that you do recognize.
Without the correct semantic markup, your web browser can’t substitute a different set of icons. You’ve just encountered an accessibility barrier — and it’s fairly easy to fix.
Meeting WCAG’s Requirements for “Identify Purpose"
When building your website, make sure that icons, page regions, and user interface components are programmatically determinable. That means that you’re not relying on visual presentation alone — you’re sending information about each component to the user agent (usually, a web browser), which will allow the end-user to modify their settings as needed to make the content more perceivable and understandable.
Some basic concepts to keep in mind:
- Wherever possible, use native semantic HTML to declare the purpose of links, icons, and other components.
- Non-decorative icons may also need image alternative text (also called alt text) that describes their purpose. This doesn’t make the icon programmatically determinable, but it fulfills WCAG 1.1.1, “Non-text Content,” a Level A criterion.
- WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) landmarks may be used to define the regions of each page.
Identifying regions with WAI-ARIA allows users to remove or highlight regions within their web browsers (or other user agents). This may be beneficial for people with conditions that affect their focus, memory, or attention.
However, by using ARIA, you’re making a commitment to test your markup carefully — improper ARIA markup can introduce serious accessibility barriers. For that reason, we strongly recommend working with an experienced accessibility partner when implementing ARIA.