Beast-Blog.com
The Four Principles of Web Accessibility

I have been fortunate to have had an opportunity to create a web site that is going to be showcased by the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0 Editors as an early and exemplary implementation of the now nearly complete working draft of the WCAG 2.0 (more on this and the WCAG 2.0 later — expect relevant articles). In this article I will introduce and expound slightly upon the Understanding [of] the Four Principles of Accessibility.

These principles are the foundation of web accessibility and the beginning of the WCAG 2.0. Without any one of these principles access will be denied to someone. It is from these four principles that the twelve guidelines and their success criteria are derived and defined. Here is my interpreted overview.

1. Perceivable

In a nutshell this principle’s guidelines pertain to a web page’s information and interface components and states that these must be perceivable. This means, in other words, that these parts must be clearly available (at least on demand). Being that the term perceivable is used in both the principle name and its definition, it can be a bit unclear. The best way to understand it is to understand the success criteria covered. In short…

All non-text content on a web page — to include images, inputs, other media such as audio and video — must be available to the user in a way that is visible to them, using the term “visible” to mean they see it in their way. In order for a web page’s information to be perceivable, it cannot be invisible to all their senses. In other words if they cannot hear audio, it must be readable (text alternative, 1.1), or if they can not see, it must be heard or accessible by some non-visual synchronized media, 1.2 (unless the media is the alternative). This principle’s guidelines also means that pages have to be adaptable, 1.3 while maintaining structural integrity. An example is viewing a page with styles off and linearized. It must make sense and not lose any of its semantic meaning. Satisfying this principle also means such components must be distinguishable, 1.4 and information conveyances such as color alone will not be acceptable unless backed up by a perceivable means.

2. Operable

This principle is rather clear without much of an extended definition. Links and navigation, user controls, and page features must function in such a way that is possible for all users — they must be operable. The first guideline within this principle is that everything must be keyboard accessible, 2.1, to include activation and deactivation so that keyboard users don’t become trapped. In other words they must be able to keep going, and without causing unexpected events onblur. This doesn’t mean to forgo mouse support and special functionality for mouse and pointer users. Support is encouraged, it just can’t be depended upon. This principle also means that operations that are not real-time or essential (auction or exam, for example) cannot be timed, 2.2, unless the operation’s limit is twenty hours or more, or it can be turned off, extended, or adjusted by the user. This principle also addresses pauses, interruptions, and sessions/authentication.

This principle also pertains to preventing seizures, 2.3 by reducing animations and flashes. How this fits into operable is a bit unclear to me I must confess, unless if one considers a seizure-inducing web page feature as making the page inoperable. I guess that would be true. The next guideline, though, navigable, 2.4 makes perfect sense. It also covers a lot of ground, from bypass blocks, page titles, ordering and focus, link purpose, access, labels, location, and headings. In my opinion, this guideline will have a larger impact to true accessibility than the other principles due to ubiquity. Mostly everything here is an extension of the WCAG 1.0.

3. Understandable

This principle, like the last, is pretty clear in its meaning. To be properly accessible the page and what it contains must be understandable. This covers such guidelines as readability. In other words, to be understandable the document must be readable, 3.1. This is determined by such things as its content language declaration (has to be readable in that language). But it goes further to cover the understanding of unusual words, abbreviations, pronunciations, and more. And the content must be understandable to people with typical reading skills — from grades 7 though 9, essentially, as defined by the International Standard Classification of Education (ISCED), assuming I understood it. In light of this, it is expected that even fully accessible sites may not be able to be understandable to users with certain levels of a cognitive disability.

Also covered within this principle is predictability, 3.2, meaning what happens on the page is expected. This will include such concerns as to whether or not to open a link new window or tab and other shifts to focus. This also addresses site consistency and component identification. In addition to this, this principle also covers input assistance, 3.3, meaning that any user errors need to be given clearly to the user with at least minimal instruction on how to correct the error. An example might be a contact form with required fields: A user gets an error telling them that they missed a field, what field it is, and if the label element might not be clear enough, instructions on how to fix it. This last guideline also addresses the need for context sensitive help.

4. Robust

Of the four principles outlined, that a page must be robust is probably the most technical, yet, once investigated, you’ll realize it’s logical and actually straightforward. This principle contains only one guideline with two success criteria. The guideline mandates the page must be compatible, 4.1. This is what most of us have been doing right along. We test to ensure that our code is valid and properly nested and parsed (though do bear in mind that under this guideline, even your basic HTML 4.01 will need closing tags because the markup must be forward compatible). This guideline also instructs (script writers mostly) to use proper name, value, and role attributes, and, if changeable, must be put in the hands of the user to ensure the change will remain accessible and comply with the other principles, and be compatible with the visitor’s user agent — his or her browser or assistive technology, now and in the near future.

Filed under Access Counts —

Bookmarking Links » del.icio.us | Digg | blogmarks | StumbleUpon | Technorati |

These posts may be related:

The Best of the Beast in 2008 »

Practical, Entry-Level Web Accessibility »

My WCAG 2.0 AAA Implementation »