2. Introduction to WCAG
WCAG Principles
The four guiding principles of WCAG say that web content must be Perceivable, Operable, Understandable, and Robust (POUR) in order to be accessible to people with disabilities.
- Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
- This means that users must be able to perceive the information being presented (it can’t be invisible to all of their senses)
- Operable – User interface components and navigation must be operable.
- This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)
- Understandable – Information and the operation of user interface must be understandable.
- This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)
- Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
- This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)
Source: Introduction to Understanding WCAG 2.0
Perceivable
For content to be perceivable it must be possible to perceive it through multiple senses. While there are a variety of ways to provide alternatives perceivable through alternate senses (e.g., audio descriptions for visual content for those who are blind, or sign language interpretation of audio content for those who are Deaf), text alternatives are generally the best choice.
Text can be converted into a variety of forms. It can be read aloud by screen reading software or converted to braille for those who are blind. It can be translated into other languages for those reading in a second language or it can be magnified without losing its sharp appearance for those with low vision. Its colour can be changed easily to make it more readable for those who are colour blind, or need high contrast.
Operable
In the context of web accessibility, operability generally means that something is functional using a keyboard. If functional items are not keyboard operable, they will be inaccessible to many users.
Developers often create features that operate with a mouse, sometimes overlooking keyboard functionality. Most people accessing the Internet do use a mouse, but many do not. A person who is blind is unlikely to use a mouse, but will instead rely almost exclusively on keyboard access. Power users, often developers or programmers, also tend to be keyboard users, so usability is lost for this group as well when keyboard access is not programmed in.
Operable can also mean functional using one’s voice. Some people with severe motor impairments use voice recognition software along with switches (see figure below) to operate their computers and navigate the Web. This means there must be text associated with functional elements like graphical buttons, so one can speak the text to bring focus to an element, and those elements must be keyboard operable so a switch can be used to activate the element. Pressing a switch is much like pressing the Enter key or Spacebar on a keyboard, or clicking a mouse.
Figure: A button switch used to replicate a mouse click
Source: Wikipedia
Understandable
Understandable refers to comprehending both the content and features of a website. Content that uses more complex or advanced language than is necessary may be difficult to understand for some people with disabilities, as well as those reading in a second language, or perhaps older users with diminishing cognitive abilities. Particularly for public access sites, the reading level of the language used should be minimized, using simpler language wherever possible.
A second aspect of understanding relates to the consistency and ease of use of the navigation elements on a site, reducing the number of navigation elements, and presenting these elements consistently throughout a website. This can improve usability for many users, including those who are blind, those with cognitive or learning disabilities, and older users.
A person who is blind and using a screen reader to navigate a site will often dedicate some effort to mapping to memory the navigation structure of a site, much like one might visualize traveling from point A to point B through a building or through city streets. If the navigation structure changes, it can often lead to confusion, and to having to map the navigation structure over again. If the navigation stays consistent, it only needs to be learned once, after which cognitive effort can focus on understanding the important content of a webpage or website.
Robust
Robust, as described by W3C, means that content works well across a wide range of Web and assistive technologies. This generally means using technology to standard. Web browsers and assistive technologies base their development around standards such as HTML, and are able to interpret content that is created in a standard way. When content varies from the standard, assistive technologies often have trouble interpreting it. Not all content must comply with the standards, but when custom content is created that does not comply, a secondary standardized version should be provided so the content “degrades gracefully.” Web content that degrades gracefully is intended to function best in the most current browsers and assistive technologies, and then as older, less feature-rich technologies view it, it should degrade in a way that is still functional, but with fewer features.
Technical: With the advent of WAI ARIA, it is now possible to veer from the standard, perhaps using HTML in new ways that were not initially intended. ARIA attributes can be used to describe the role, states, and properties of custom elements. For example, an HTML <div> element was never intended to be clickable, but with some JavaScript it is possible to add click functionality, though from an assistive technology’s perspective the <div> is just a container with no functionality.
A <div> has been used in a non-standard way in this case. ARIA can now be added to that customized <div> to give it a role="button" for instance, and made focusable adding a tabindex attribute, and made clickable by adding aria-pressed attribute to describe its state as pressed or not pressed, and so on.
There are other occasions where non-standard technologies such as embedded Flash objects or Java applets might be used. Though it is possible to make these objects somewhat accessible, they are often challenging to access and operate effectively with assistive technologies. In such cases alternatives are generally needed. Some Flash development tools, for instance, provide an option to generate an HTML version, though these tend to be static representations of what was interactive in the Flash. Where possible, HTML5, with CSS, scripting, and ARIA should be used to develop interactive content for the Web.
HTML5 and ARIA will be discussed in greater detail in unit 8.
