Skip to Content

Making Your Site Accessible, Easy as 1-2-WCAG

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 crop of tools to analyze and score the accessibility of your website can be a dicey proposition.

Let me explain.

There’s No Magic Tool to Gauge Accessibility

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 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.

However, steering is all the guidelines are good for, since they’re just that—guidelines, not hard and fast rules.

Developers who follow the guidelines have lots of differing opinions about what WCAG specifies—what it allows, what it discourages, what it requires.

On top of that, developers must take into account the plethora of website platforms and 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.

So there isn’t at this time a tool you can acquire to analyze and score the accessibility of your website.

Eventually such a tool will exist. But until everyone everywhere gets on the same page with their interpretations of WCAG and starts using identical hardware and software, no magic tool will be forthcoming to 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 woefully 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.

Distilled to its essence, WCAG asks you to configure your website so that, to users, it is:

  • Perceivable
  • Operable
  • Understandable
  • Robust

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 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, giving users enough time to read and use content, 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 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—and 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.”

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 once the accessing begins. It is the combination of accessibility and user experience which 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.

5. Developers.

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 to the puzzle of optimal accessibility. This fact of life is reflected by WCAG.

It’s also why WCAG presents the meeting of guidelines—rather than applying specific technical methods for altering the framework of a website—as the best means for achieving accessibility. This distinction is very important.

Please bear in mind that, ultimately, your website will be perceivable, operable, understandable, and robust if you 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.

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 and 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 therefore the best resource 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 [email protected]

Leave a reply:

Your email address will not be published. Required fields are marked *

Back to top