9.5. Accessibility Standards
Many organizations such as federal governments and the W3C (World Wide Web Consortium) have published standards to describe accessibility elements that web applications should adhere to, to be considered accessible by all users.
For the most part, standards are a good thing; they help to raise awareness that not all web applications are accessible to all users right out-of-the-box.
The trouble with standards is that developers focus a great deal of time to understand each set of rules, and often developers learn what they interpret to be the rules without learning how to incorporate the rules into accessible web applications.
I have met many creative developers that feel that abiding to standards will make their appellations bland and dull, looking much like unformatted text documents. As you have hopefully learned by now, this is far from the truth.
The standards that are in place are hard to read and in many situations developers interpret some of the rules incorrectly. The next section is intended to help clarify some of the more difficult rules to understand. Each standard has a link to the complete set of standards if you are looking for the definitive guide.
Knowing the rules is only useful if you know what they actually mean.
9.5.1. WCAG 1.0
In May 1999, the WC3 (World Wide Web Consortium) published the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) with the goal of explaining how to make web content accessible to people with disabilities. WCAG 1.0 is still referred to most often when discussing principles of web accessibility. WCAG essentially is a 14-point accessibility checklist to grade how accessible a web application is. In the WCAG standard, each accessibility point is assigned a priority level which determines how critical the checkpoint is to accessibility. See how confusing this can become?
Level 1: Must be satisfied
Level 2: Should be satisfied
Level 3: May be addressed
Conformance to WCAG is measured with three levels.
A: All priority 1 checkpoints have been satisfied.
Double-A: All priority 1 and 2 accessibility points have been satisfied.
Triple A: All priority 1, 2, and 3 accessibility points have been satisfied.
9.5.1.1. Standards to Note
The full WCAG 1.0 standard can be found at http://www.w3.org/TR/WAI-WEBCONTENT/.
The following are a few accessibility checkpoints that may need more clarification:
3.1 [Priority 2] When an appropriate markup language exists, use markup rather than images to convey information. If possible, use text rather than an image. Try to avoid putting essential text within an image, and avoid using only images for navigation.
3.4 [Priority 3] Use relative rather than absolute units in markup language attribute values and style sheet property values. If possible, design using flexible widths. Units such as PX, PT, and CM don't allow for change. Relative units such as EMs or percentages do not change if the font is scaled by the user.
9.3 [Priority 2] For scripts, specify logical event handlers rather than device-dependent event handlers.
This checkpoint requires that no assumptions are made about the input devices. Choose to use event handlers such as onfocus and onselect, and try to stay away from event handlers such as onclick and onkeypress.
10.5 [Priority 3] Until user agents (including assistive technologies) render adjacent links distinctly, include nonlink, printable characters (surrounded by spaces) between adjacent links. This accessibility point is making the point that neighboring links should be discernible by the user.
9.5.2. WCAG 2.0
The web is ever growing; as the underlying technology changes, so do the standards. Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is the latest installment of accessibility standards published by the WC3 (World Wide Web Consortium) in December 2008. WCAG 2.0 is much more complex than WCAG 1.0.
WCAG 2.0 is one of the most controversial standards out there. Accessibility experts and web developers believe that the complexity of WCAG 2.0 is contraindicated to create accessible web applications. Many accessibility elements are difficult to achieve let alone test.
Conformance in WCAG 2.0 is similar to WCAG 1.0.
Level A. For Level A conformance (the minimum level of conformance), the web page satisfies all the Level A Success Criteria, or a conforming alternative version is provided.
Level AA. For Level AA conformance, the web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternative version is provided.
Level AAA. For Level AAA conformance, the web page satisfies all the Level A, Level AA, and Level AAA Success Criteria, or a Level AAA conforming alternative version is provided.
9.5.2.1. Standards to Note
The full WCAG 2.0 standard can be found at http://www.w3.org/TR/WCAG20/.
1.2.6 Sign Language (Prerecorded). Sign language interpretation is provided for all prerecorded audio content in synchronized media. This checkpoint requires that sign language "bubbles" display during audio/video playback. Although this checkpoint is only required for AAA compliance, it is still a very difficult checkpoint to satisfy if you have audio/video on your website.
1.3.1 Info and Relationships. Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
9.5.3. Section 508 Standards
In 1998, the Rehabilitation Act of 1973 was updated to include a new law to ensure that all Americans have access to information technology. The law applies specifically to all U. S. government agencies as well as anyone who works with a U.S. government agency. This law is Section 508 of the Rehabilitation Act of 1973, more commonly known as Section 508.
Section 508 covers all information technology, but for our purposes we will only be looking at §1194.22 Web-based Intranet and Internet Information and Applications.
The most confusing factor in Section 508, is the term undue burden. Undue burden is the "loop hole" in the law that provides exceptions when the implementation of accessibility would be financially or technologically impossible to achieve. For web accessibility, only rare cases can present themselves as undue burden. It's recommended that you do not assume undue burden yourself, and you consult an expert before making the decision to declare undue burden.
Even though some of the standards are difficult to understand, the U. S. government does a good job of providing well-defined summaries of each accessibility element, along with training on how to become compliant.
9.5.3.1. Standards to Note
The full Section 508 standards can be found at http://www.section508.gov/index.cfm?FuseAction=Content&ID=12.
(§1194.22 l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
This is simply saying that a web application should function correctly with JavaScript turned off. If the web application provides information that can only be accessed with JavaScript turned on, then this accessibility checkpoint will fail.
(§1194.22 P) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
This checkpoint ensures that users will have adequate time to perform a given task on your web application. If you have timeouts on your web application, such as an allotted time when collecting a form, or logging a user out after a predetermined time period, providing a way for the user to request more time will satisfy this checkpoint.
9.5.4. Other Countries' Accessibility Standards
Many governments have legislation in place to protect against disability discrimination and it's important to be aware of these laws. Similar to Section 508 of the Rehabilitation Act of 1973 of the United States many of these countries' laws have sections that relate directly to web development. WCAG 1.0 and WCAG 2.0 are the basis for most of these standards, but if you are creating a public government site that may be accessed in other countries, it would be wise to learn more about their particular accessibility standards.
9.5.4.1. Australia
In Australia the Federal Disability Discrimination Act of 1992 (DDA) provides protection for everyone in Australia against discrimination based on disability. The DDA is all encompassing and relates to web applications developed for both the public and private sector.
This act contains several statements that could apply to web accessibility. Under Section 24 it is unlawful for a person who provides goods, facilities, or services to discriminate on the grounds of disability by doing any of the following:
Refusing to provide a person with goods or services or make their facilities available to certain people;
In the terms or conditions on which the first-mentioned person provides the other person with those goods or services or makes those facilities available to another person;
In the manner in which the first mentioned person provides the other person with those goods or services or makes those facilities available to the other person.
Pertaining specifically to web standards for government applications, the Australian government has published the Guide to Minimum Web Site Standards (http://www.agimo.gov.au/archive/mws.html), which states web applications should adhere to WCAG 1.0 Priority 1.
9.5.4.2. Canada
The general purpose disability discrimination laws are contained in the Canadian Human Rights Act of 1977 (http://laws.justice.gc.ca/en/ShowTdm/cs/H-6///en).
In direct relation to web development, the Canadian Treasury Board released the Common Look and Feel Standards (http://www.tbs-sct.gc.ca/clf-nsi/index_e.asp) which provides standards for accessibility, branding, and proper use of the Canadian government logo. The accessibility portion of these standards requires that government sites adhere to WCAG 1.0 Priority 2 compliance.
If your web application is for the providence of Ontario, then there is even more legislation you should be aware of. The Ontarians with Disabilities Act of 2001 contains more laws pertaining to disability and government sites at http://www.search.e-laws.gov.on.ca/en/isysquery/ed0dd1dd-5e27-465a-a0b2-15a50c6dfece/1/frame/?search=browseStatutes&context=
9.5.4.3. The European Union
Inside the European Union the EU Charter of Fundamental Rights, found at http://ue.eu.int/uedocs/cms_data/docs/2004/4/29/Charter%20of%20fundemental%20rights%20of%20the%20European%20Union.pdf outlines the laws against disability discrimination; specifically articles 21 and 26.
Pertaining directly to web applications, many of the countries inside the European Union have adopted standards that are based off WCAG 1.0.
9.5.4.4. Japan
As of 2008 there were no standards that legally require web applications to be accessible, but there are two documents that Japanese governments use as recommendations.
In 2000 the Ministry of International Trade and Industry (MITI) released the Accessibility Guideline for computer use by people with disabilities: (http://www.kokoroweb.org/guide/guideE.html).
In June 2004 the Japanese Industrial Standard for Web Accessibility (JIS) (http://www.webstore.jsa.or.jp/webstore/Top/html/en/august2004.htm) was released and is largely based on WCAG 1.0 with a few accessibility elements from WCAG 2.0.
9.5.4.5. United Kingdom
As in both Australia and the United States, discrimination against disabilities in regards to web applications is legally prohibited for both public and private sector web applications.
The Disability Discrimination Act (DDA) of 1995 (http://www.opsi.gov.uk/acts/acts1995/Ukpga_19950050_en_1.htm) was created to help end discrimination of the disabled and outlines areas of laws of discrimination in the United Kingdom.