You’re sold on the idea of making your website accessible. You understand that web accessibility boosts traffic and conversions. And you understand U.S. law requires accessibility.
So you’re ready—and in fact eager—to make your website accessible to all visitors. But how?
First, acquire a tool to analyze and score the accessibility of your website.
Except you can’t.
Well, technically you can. And I don’t mean for you to interpret what I’m about to say as me trying to dissuade you from picking up one of these tools. It’s just that using any of the current tools to analyze and score the accessibility of your website can be a dicey proposition.
Let me explain by starting at the beginning.
If you’ve spent time seriously investigating the issue of website accessibility, then you very likely already know about WCAG.
In case the name rings no bells for you, WCAG stands for Web Content Accessibility Guidelines. WCAG was developed by a cooperative of international organizations. Including W3C (the folks who invented the internet) and others. Together they are dedicated to figuring out and explaining what it takes to make content accessible to disabled users.
WCAG proves itself very helpful in steering the development of products designed to evaluate your website for accessibility.
Web Content Accessibility Guidelines
Steering is all the guidelines are good for since they’re just that—guidelines. They are not hard and fast rules.
Developers who follow the guidelines have lots of differing opinions about what WCAG specifies. Like what it allows, what it discourages, and what it requires.
On top of that, developers must take into account the plethora of website platforms. Not to mention all the user hardware-software choices out there.
Consequently, no clear-cut path to the development of a universally agreed upon website accessibility evaluation tool yet exists.
There’s No Magic Tool to Gauge Accessibility
So there isn’t at this time a tool you can acquire. Not to analyze and score the accessibility of your website.
Eventually, such a tool will exist. But not until everyone everywhere gets on the same page with their interpretations of WCAG. And not until everyone starts using identical hardware and software. Until all of this, no magic tool will be available. One that can tell you: OK, this about your website’s accessibility is good, this is bad, and do this, this, and this to improve it.
Some tools claim they can do all that. Don’t believe them. They unrealistically (and unfairly) inflate user expectations and leave you completely misinformed.
Even so, you can achieve a heightened state of website accessibility without the benefit of a magic tool. Simply adopt WCAG to the best of your understanding and ability.
The Breakdown of WCAG
Distilled to its essence, WCAG asks you to configure your website so that, to users, it is:
Let’s examine those more closely, one at a time.
First, the perceivable nature of your website.
If your site offers non-text content, you need to provide text alternatives for images and captions and other alternatives for multimedia.
Look to create content that can be presented in different ways. Most importantly, without loss of meaning. Among the ways available are assistive technologies.
Explore methods of making it easier for users to see and hear your content.
Next, operable. This means making all functionality available from a keyboard. Operable also means giving users enough time to read and use the content. It includes avoiding the use of content that can cause people with neurologic disorders to suffer seizures. And providing thoughtful features and extras that help users navigate and find content.
Then on to the issue of understandability.
Here, you need to make text readable and understandable. Make content appear and operate in predictable ways. And help users avoid mistakes and be able to correct them.
Finally, there’s the matter of offering a robust website. You can do this by maximizing its compatibility with current and future user tools.
It’s About Success, Not Techniques
It’s important to understand that the real measure of a website’s accessibility comes from your success in living up to the WCAG Guidelines. Not the techniques you used to meet them.
Think about it. All these guidelines do is generalize the conditions necessary for there to be a satisfactory level of accessibility. However, in truth, no health condition is the same for any two people. Moreover, associated with each website is a unique set of accessibility goals-related needs. Consequently, the achievement of these goals may require a skirting of the “rules.”
As such, any scan tool you might use to evaluate accessibility will generate lists of “actions” to take. But those actions may or may not be entirely correct. Therefore, the wisest course is to supplement listed actions with your own knowledge of the principles of accessibility.
The WCAG supports this advice directly:
“While many authors find W3C-documented techniques useful, there may be other ways to meet WCAG success criteria.
“You can use other techniques. Web content could even fail a particular technique test, yet still meet WCAG in a different way.
“Also, content that uses some of the Techniques does not necessarily meet all WCAG success criteria.”
8 Components That Affect User Experience
Up to this point, I have discussed only the considerations that make it possible for people with disabilities to access your website. I have yet to describe any of the eight components that affect user experience. It is the combination of accessibility and user experience. These provide you the means to measure success in honoring and obeying WCAG.
The eight components of user experience are these:
1. The website itself (consisting of its text, images, sound, and other natural information plus its structure and presentation as defined by its markup code).
2. User agents (i.e., web browser and media player).
3. Assistive technologies (these include conventional keyboard and mouse substitutes such as screen readers and input devices).
4. User knowledge of and expertise with the web.
6. Authoring tools.
7. Evaluation tools.
8. Evaluation methodology (essentially, the availability of a defined web accessibility standard or policy that your organization uses to gauge accessibility).
Permit me to toss into this mix these two definitional observations. Web developers typically use authoring tools and evaluation tools to create web content. People (a.k.a. “users”) use web browsers, media players, assistive technologies, or other “user agents” to obtain and interact with the content.
I mention this because you need to appreciate that there is no one-size-fits-all solution. Not even one for the puzzle of optimal accessibility. This fact of life is reflected by WCAG.
Meet The Guidelines
WCAG presents the meeting of guidelines, as the best means for achieving accessibility. Rather than applying specific technical methods for altering the framework of a website. This distinction is very important.
Please bear in mind that, ultimately, your website will be perceivable, operable, understandable, and robust. That is if all the pieces placed between you and the user interact successfully. And to a large degree whether that can occur depends on how well you meet the WCAG.
You Still Want The Tool
If your heart is set on using a scan tool to assess your website’s accessibility. And to then use the results of that evaluation as the basis for a plan of action, I won’t stop you. Just do so knowing that the results may or may not be reliable. Additionally, be aware that they are unlikely to be replicated by any other scan tool.
If you’re prepared to responsibly use scanning tools for testing your site, you can find a list of tools in the WordPress Handbook.
Still, to my way of thinking, WCAG is the best resource. It’s the best one you can lay hands on as you start trying to identify what your site needs to be considered truly accessible.
Would you like to learn more about those guidelines and kick around some ideas for complying with them? Then please drop me a line at firstname.lastname@example.org.