3.3 Web Accessibility
3.3.1 Standards and Guidelines
The Web accessibility discipline focuses on providing an accessible path to Web content production and consumption in par with the user experience typically
found for non-impaired users. The WAI model (Henry, 2005) for this vision is
3.3 Web Accessibility
centred on framing accessibility technologies between three main components, as
presented in Figure 3.8: the Developer, the User, and Web Content (e.g., Web
pages, media, etc.)
Content Developer User produces consumes authoring tools evaluation tools assistive technologies user agents
}
{
Figure 3.8: Components of the WAI Model
Each interaction within the WAI model has a corresponding set of well-defined guidelines that, if properly applied, improve the experience of users with disabil- ities on the Web. The depicted interactions are detailed as follows:
• Developers produce content that must be accessible. For this, they must
conform with the Web Content Accessibility Guidelines (WCAG) (Caldwell
et al., 2008), a process that is typically aided by evaluation tools. Further- more, this can also be supported by authoring tools that produce accessible content, as defined by the Authoring Tools Accessibility Guidelines (ATAG) (Treviranus et al., 2009);
• Users consume content within Web pages through user agents, such as Web browsers and media players, with the aid of assistive technologies, e.g., screen readers or braille displays. Consequently, these entry points for the Web must also be accessible, i.e., conforming with the User Agent Accessibility Guidelines (UAAG) (Ford et al., 2009).
In essence, all of these guidelines from the WAI – WCAG, ATAG, and UAAG – concern a different aspect regarding the adequacy of a Web page to users’
3. STATE OF THE ART
impairments. Either directly or indirectly, all interactions within the WAI model are dependent on the accessibility quality of a Web page. Next, each one of these guidelines are discussed more thoroughly.
3.3.1.1 WCAG
WCAG, the Web Content Accessibility Guidelines, serves as the basis to verify the accessibility compliance that a Web page must have, i.e., a quality mark, in order to provide an adequate experience for users with disabilities. WCAG is mainly targeted at designers and developers responsible for Web front-ends – the visible side of the Web –, by listing a set of guidelines for accessible ramps in Web content. An example is WCAG 1.0 Guideline 1, which states:
Provide equivalent alternatives to auditory and visual content.
Each guideline is further decomposed into checkpoints that assess a different aspect of the guideline. Based on the example above, an excerpt of Checkpoint 1.1 states:
Provide a text equivalent for every non-text element (e.g., via alt, longdesc, or in element content).
In order to translate each checkpoint into concrete support for Web content, WCAG defines a set of techniques that can be applied to different Web technolo-
gies, such as HTML or CSS (Chisholm et al., 2000). An example technique for
Checkpoint 1.1 is presented below, in the form of an HTML excerpt. < A h r e f = " r o u t e s . h t m l " >
< IMG src = " r o u t e s . jpg " alt = " C u r r e n t ␣ r o u t e s ␣ at ␣ B o u l d e r s ␣ C l i m b i n g ␣ Gym " > < / A >
Listing 3.1: An HTML Technique for WCAG 1.0 Checkpoint 1.1
Here, the technique presents the alt attribute of the HTML IMG element, which affords an alternative textual description of what is conveyed in the linked image. By following WCAG techniques, designers and developers have a concrete, expert-created guide to provide barrier-free Web pages to users with disabilities.
3.3 Web Accessibility
Each checkpoint in WCAG is also mapped into one of three priorities, de- pending on the severity introduced by the respective non-compliance, as follows (quoting from WCAG 1.0):
• Priority 1. A Web content developer must satisfy this checkpoint. Oth- erwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
• Priority 2. A Web content developer should satisfy this checkpoint. Oth- erwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
• Priority 3. A Web content developer may address this checkpoint. Oth- erwise, one or more groups will find it somewhat difficult to access infor- mation in the document. Satisfying this checkpoint will improve access to Web documents.
More recently, WCAG 2.0 (Caldwell et al., 2008) has been superseding the
1.0 version, where it reviews the evolution of Web technologies in the light of their accessibility issues and technological support. WCAG 2.0 also introduces the notion of principles, which aggregate guidelines into four POUR categories: Perceivable, Operable, Understandable, and Robust.
3.3.1.2 ATAG
ATAG, the Authoring Tools Accessibility Guidelines, are focused on the creation of accessible Web content, as well as on the availability of content production platforms that can be used by people with disabilities. It is targeted to the
backends of Content Management Systems such as Wordpress1 and Mediawiki2,
1Wordpress: http://wordpress.org/
3. STATE OF THE ART
as well as to Web development applications such as Adobe Dreamweaver1 and
Microsoft Expression Web2.
Just like in WCAG, ATAG defines a set of Guidelines, which are decomposed into Checkpoints and Techniques. For instance, to afford the compliance with WCAG Checkpoint 1.1 (presented above), ATAG defines its checkpoint 3.1 as:
Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). Based on this, ATAG also defines several techniques that authoring tools must provide to Web content producers, depending on the accessibility barrier tackled by the corresponding WCAG Checkpoints. For the example presented above, one of techniques states:
Short Text Labels (for alternate text, titles, etc.): These types
of alternative equivalents require only short text strings from the au- thor, so the prompts for them may be best located as text boxes within property dialogs, etc. An important consideration is that the function of the object (decorative, button, spacer, etc.) will be important to the instructions given to the author on what to write. The object function may be prompted for or discovered by automated heuristics.
Also, due to the relationship with WCAG, ATAG also define three priority levels for checkpoints. These levels are directly related to satisfying content pro- duction according to the corresponding WCAG priority. For instance, an author- ing tool can only be compliant with ATAG priority 2 if the content it produces is compliant with WCAG priority 2.
3.3.1.3 UAAG
UAAG, the User Agent Accessibility Guidelines, provides a description of tech- niques for a barrier-free interaction with Web content for users with disabilities.
1Adobe Dreamweaver: http://www.adobe.com/products/dreamweaver/
2Microsoft Expression Web: http://www.microsoft.com/expression/products/Web_
Overview.aspx
3.3 Web Accessibility
While WCAG and ATAG are targeted at Web content production, UUAG is targeted at developers of Web browsers, assistive technologies, and other User Agents commonly used by people with disabilities. While it is of the uttermost importance for Web content to be accessible, if users have barriers to this content that are imposed by User Agents, the inherent accessibility purpose is defeated. As an example, UUAG Guideline 1 states:
Support input and output device-independence.
By following this guideline, through its corresponding checkpoints (Full key- board access, Activate event handlers, and Provide text messages), developers can ensure that accessible Web content can be used appropriately by users with disabilities without breaking their preferred interaction model.
3.3.1.4 Other Accessibility Standards
While the Web Accessibility Initiative, via the World Wide Web Consortium, is the most well known entry point upon which Web accessibility is framed, designers and developers might follow other standards, processes, or accessibility guidelines that are taken into account by accessibility stakeholders throughout the world, including:
• Section 508. This amend to the Rehabilitation Act of 1973 puts a strong emphasis on making Federal information and services accessible to all USA citizens. A particular technical standard in Section 508 concerns “Web- based Intranet and Internet Information and Applications”, where a set of guidelines have been devised how to meet the requirements for accessible Web sites and applications (similarly to WCAG). More recent versions of Section 508 are currently being reviewed according to WCAG 2.0 (e.g., application scenarios for WCAG 2.0 techniques);
• BITV. Also known as Barrierefreie Informationstechnik-Verordnung, BITV is the official standard for barrier-free information access in Germany. It states a set of Standards and Requirements for accessibility compliance that are based on WCAG 1.0, but applied to a broader scope (i.e., includes non- Web content);
3. STATE OF THE ART
• Resolução do Conselho de Ministros nº 155/2007. The Portuguese govern- mental directive for Web Accessibility, which states that all governmental and public bodies Web sites must comply with WCAG 1.0, levels A or AA (depending on the existence of transactional processes).
Apart from Section 508, which has a broader scope than the Web, most na- tional laws on information accessibility rely on WCAG (mostly its 1.0 incarnation) and associated guidelines as the technical basis for accessibility adequacy of public services’ Web sites1.