To follow the Web Content Accessibility Guidelines (WCAG), you’ll need to understand the terminology. Fortunately, most of the guidelines are written in plain language — but a few contain some technical jargon.
The term “accessibility supported" is referenced within the guidelines, so it’s an important phrase to understand. Here’s how WCAG defines accessibility supported:
“supported by users' assistive technologies as well as the accessibility features in browsers and other user agents.”
In simpler terms, technology (or a feature of technology) is accessibility supported when it works well with current assistive technology (AT) and when it has accessibility-supported user agents.
For the latter of those requirements, WCAG requires that at least one of the following four statements are true:
- The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS).
- The technology is supported in a widely-distributed plug-in that is also accessibility supported.
- The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported.
- The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that does not cost a person with a disability any more than a person without a disability and is as easy to find and obtain for a person with a disability as it is for a person without disabilities.
So, why does WCAG have such a broad definition for “accessibility support?”
The guidelines are intended to apply to all internet technologies, including technologies that haven’t been created yet. Accessibility is a set of principles, and different types of AT have extremely different features — a screen reader, for example, works differently from speech recognition software (and serves an entirely different audience).
To conform with WCAG, you must only rely on accessibility-supported ways of using technology. In other words, you must use tools like CSS and HTML that are widely supported and accessibility-friendly.
In order for HTML content to work with all AT, it must follow certain rules:
- Each feature must be communicated through the web browser’s accessibility API (application programming interface).
- Content must be exposed to AT through the accessibility tree, or removed from the accessibility tree if the content would not be useful for AT users. Read: Is It Okay to Hide Content from Screen Readers?.
- Content must be presented to human users in a way that makes sense. Accurate names, roles, states, and descriptions provide human users with the information they need to use the content.
These general rules are applicable regardless of the type of content, and they should be fairly future-proof. Future web technologies will still need to work with AT, and they’ll still need to communicate semantic information in a consistent way.
Related: Assistive Technology 101: What You Need to Know
Test your website or mobile app against WCAG
If you’re feeling overwhelmed, don’t worry too much about WCAG’s terminology. Remember, the purpose of the guidelines is to improve experiences for real-life users — not to confuse content creators.
Focus on testing your content against Level A/AA success criteria and resolving the barriers that affect your users. The Bureau of Internet Accessibility provides a free graded web accessibility report, which tests content against the latest version of WCAG.
Before fixing any accessibility issues, ask questions:
- Why does this barrier need to be fixed?
- How does this issue impact my users?
- What is the simplest way to address the issue?
- What are WCAG’s recommendations for fixing the issue?
To learn more, read: 4 Questions to Ask Before Fixing a Web Accessibility Issue.
And if you need assistance with remediations, we’re here to help: Send us a message to connect with an expert.
