Passed in December 2008, the new “Web Content Accessibility Guidelines 2.0” is the official recommendation from the World Wide Web Consortium for web accessibility for the disabled.
The new guidelines focus on four fundamental principles.
- Is it perceivable?
- Is it operable?
- Is it understandable?
- Is it robust?
This is the third article in my series on the new WCAG 2.0. The previous installments are:
In this article, I’ll addresses “understandability.”
The understandability of text is crucial to web accessibility. At broad levels, this means specifying text languages, explaining the meanings of jargon or idioms, and expanding abbreviations to clarify the text. It’s not just text that can present a barrier to accessibility, however. A lack of organizational predictability or proper error management can greatly decrease the accessibility of any website.
Identify the Language
Guideline 3.1 Readable: Make text content readable and understandable.
When you see a block of text, you can usually recognize immediately whether that text is in a language you can read. Knowing that language, you read through the text quickly and efficiently. Understanding a recognized language is no problem – for a person.
However, language can present a significant barrier for the disabled – not because they might not understand the language – but because the assistive technology they’re using won’t be able to pronounce it correctly unless the language of the text is specifically marked in a computer-readable fashion.
By default, assistive technology will attempt to read text in the language of the user’s computer. This is fabulous as long as the user stays within websites written in their system language.
It’s surprising just how difficult it is to understand even your native language if it’s pronounced according to the rules of a different language. Adding a simple piece of meta information to your HTML documents or templates indicating the language of the document can make a huge difference towards supporting the needs of disabled site visitors.
Specifying Language in XHTML & HTML Content
Specifying the language of the document is not always sufficient, although it will usually provide access for the majority of customers. The language of individual parts of the page (quotations in other languages, and non-vernacular uses of foreign languages) should also be individually identified and translated.
Outside of actual language differences, terminology such as idioms, jargon or abbreviations must be expanded. Although it’s common to provide additional details about these types of text in a “
title” attribute attached to the text, this should not be considered the ideal way to communicate the meaning of these materials, as screen readers do not announce the presence of title attributes – let alone read them out – in their default configurations.
Does the site do what you expect?
Guideline 3.2 Predictable: Make web pages appear and operate in predictable ways.
Web pages tend to operate in a pretty standard and predictable fashion. You click on a link; you go to a new page. You activate a button; you submit a form. The specifics of how these work may be a bit variable, but the basic expectations are constant. Meeting the WCAG expectation that a website should be predictable simply means that you don’t implement any programming which will subvert the normal behavior of a website.
Now, “normal” is actually a rather inappropriate term in this context. What is “normal” for the behaviors in website interactivity is a moving target. What was normal 10 years ago is not what is normal today, and what is normal today is not what will be normal in another 10 years. However, there are basic expectations that should be met.
One key to predictability is very simple: consistency. Use the same navigation mechanism throughout the site: common menus, common menu styling (for visual users). Use the same types of labels for repeated elements. If changes are made, they should only be made at the request of the user.
There are a lot of variables in designing and development a website which can create confusion for all users, not just the disabled. The issues that will cause problems for the disabled will almost always have the potential to cause problems for all users.
What happens if I make a mistake?
Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.
Every complex website or application includes systems where users submit input. Ecommerce certainly depends on user submissions: Shopping transactions don’t get very far without shipping addresses and payment information.
Ask: Why is this an accessibility issue?
One of the features of the new Guidelines is a focus on making experiences more than just possible for the disabled. Simple access is not sufficient; the experience should help support the customer during their visit.
So, to your benefit, following the WCAG guidelines for input assistance will give you a very handy checklist to look at where your shopping process could be causing problems. It’s all about error handling: What does the system do if a user makes a mistake?
The worst error message you might get is the one you don’t actually see. As such, simply providing error messages is a good start. If the visitor simply knows that something has gone wrong, they aren’t going to be sitting at home waiting for the package which will never arrive.
But a better solution is to ensure that labels and instructions are clear and thorough (to prevent errors) and that if an error occurs, the message presented provides sufficient information to allow the user to correct their error.
In short, understandability (for you) simply means taking a close look at your website and determining whether it actually makes sense. Solving the problems (particularly when it comes to forms) can be a challenge, but locating them requires little more than common sense.
See the next installment, “Part IV: Robustness.”