Chapter 5

Understanding and Meeting Web Accessibility Standards

Introduction

In this chapter we'll look at specific features within Microsoft and HiSoftware products that help people meet international Web accessibility standards or that help people with disabilities benefit from accessible Web content. We'll also show examples of how to test Web content to determine if it is accessible.

This chapter is organized into 12 sections, one for each of the Guidelines in the W3C's Web Content Accessibility Guidelines 2.0. While this structure reflects that of wcag 2.0, this chapter does not explain the W3C's work. For more information, please refer to the wcag 2.0 Overview (http://www.w3.org/WAI/intro/wcag20.php).

Microsoft actively participates in European and global efforts to develop and harmonize ICT accessibility standards, including wcag 2.0. Microsoft believes that standards harmonization will result in more accessible products that are delivered through a more economically efficient market. Similar to most IT companies, “Microsoft builds products and services for a global marketplace and strives to meet the needs of people with disabilities in all of its markets.” (From http://www.access-board.gov/sec508/refresh/report/microsoft.htm)

Principle 1: Making Information Perceivable

This principle lays the foundation for the other three: end users must be able to perceive information before they are expected to interact with it. Text alternatives provide an easy and flexible way to meet this principle since text is easily made available via Braille or speech.

Guideline 1.1 Text Alternatives

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language

Non-text content is anything that isn't text. This includes images, sounds, and videos. It even includes art created using text. For example, “colon hyphen right parentheses” creates a smiley face “:-)” which is not text, it's an emoticon. In this case, the “picture” is not perceivable to someone who cannot see and the meaning needs to be provided via a text alternative. Text alternatives are handy because they can be translated to Braille or to speech via assistive technologies. Therefore, the visual information can now be perceived with your ears (audio) or fingers (Braille).

Providing Text Alternatives

Features in Microsoft products help people who create Web sites provide text alternatives. For example, in Figure 1, when inserting an image into a Web document with Expression Web, the author is prompted to add a text alternative.

This is an example of Accessible by Default—an approach that Microsoft is integrating into its products. What this means for the end user is that Web sites “just work” because their browsers and assistive technologies have what they need to create a meaningful and usable experience. For the person creating Web content, this means accessibility is integrated into their Web development processes and tools.  When accessibility is integrated into development tools, authors can more easily make accessible choices and, in some cases, the tool automatically produces accessible Web content without the author doing anything special. We will see more examples of the Accessible by Default approach throughout this chapter.

Guideline 1.2 Time-based Media

Provide alternatives for time-based media

In addition to a short text alternative, time-based media such as videos and audio recordings need transcripts or synchronized alternatives.

A transcript is a text document that conveys all of the dialog and significant sounds from a video. Synchronized alternatives include captions and audio descriptions. Captions appear on the screen at the same time as words that are spoken and significant sounds are made.

Captions are used by people who have difficulty hearing speech and sounds. A variety of tools are available to caption videos, including HiSoftware's Hi-Caption Studio. Microsoft’s Expression Encoder can add captions to a media file and export the end-result to Silverlight.

Audio descriptions are provided by a narrator who desribes visual events that cannot be understood through sound alone. Audio descriptions are useful to people who have a hard time seeing the visual content of the time-based media. For example, in the following dialog, it isn't clear why Jennifer suddenly changes her mind:

James: "How is your day so far?"

Jennifer:"My day is going quite well. . . .Oh! Now it seems to be a little worse."

When we add an audio description, it becomes clearer what has happened with Jennifer:

James: "How is your day sofar?"

Jennifer: "My day is going quite well. . . ."

Audio Description: A passing waiter spills a pitcher of ice water down Jennifer's back.

Jennifer: "Oh! Now it seems to be a little worse."

There are two ways to provide captions: open and closed. Open captions are displayed all the time, for everyone viewing the video. Closed captions are only displayed when the user sets his or her preferences to display them.

Audio descriptions are most commonly provided as “open” meaning that the narration is included in the soundtrack to the video and everyone hears it. Historically, there wasn't enough bandwidth to download multiple audio tracks along with a video track. But this is changing and now we're starting to see the option to turn audio descriptions on and off as well.

Guideline 1.3 Adaptable

Create content that can be presented in different ways (for example simpler layout) without losing information or structure

Good visual design guides the reader's eye through a document or application. When creating Web content, you can use the underlying structure to create an auditory design or tactile design that mimics the same flow of information presented visually.

A Web author creates structural landmarks by using specific HTML elements. Landmarks include headings, lists, tables, and paragraphs. Figure 3 shows how to use Live Writer to mark a string of text as a heading

A person looking at the page will be drawn to the large font size and other visually characteristics that distinguish headings from other text. Scanning the headings can help someone understand the overall structure and content of a page. A person listening to a page (or using their fingers to read the page via Braille) can instruct his or her assistive technology to navigate the landmarks to gain an understanding of the overall structure and content of the page. This is in contrast to reading a page line-by-line.

One way to determine if content has appropriate landmarks is to look at the page without the style sheet. Figure 4 shows two views of microsoft.com. On the left is how the page looks when the sty e sheet is used. The image on the right shows how the page looks when the style sheet is not used. While we use HTML to describe the structure of Web pages, we use Cascading Style Sheets (CSS) to describe the style—the colors, fonts, and placement of objects in a Web page.

When you investigate a Web page without style sheets, what are you looking for to determine if structural landmarks are present? Well, does the page still make sense? Are the paragraphs of text still in chunks? Are links running into each other or are they organized in bulleted lists?   Does the order make sense or do you jump all over the page?

This guideline describes the semantics that need to be infused into your HTML to ensure that structure and pathways through the structure are perceivable. We'll learn later, in Guideline 2.4, about additional landmarks that should be provided and how to ensure that users can navigate through the structure in an easy and meaningful way.

Guideline 1.4 Distinguishable

Make it easier for users to see and hear content including separating foreground from background

When color is used to convey information, some people may miss out on that information. For example, a form gathers a person's billing information and indicates, “All fields marked in red are required.” Not everyone sees red as red. For some, red appears more like yellow. People who are blind will not see any color. What should you do? Provide a redundant cue, like an asterisk. However, you will need to tell people what the asterisk means.

A new technology that is quickly gathering support in browsers and assistive technologies is the W3C Web Accessibility Initiative's Accessible Rich Internet Applications Specification (WAI-ARI). Microsoft has contributed to the development of this specification and Windows Internet Explorer 8 is one of the first browsers to implement the specification. WAI-ARIA provides a new vocabulary to describe the objects in Web applications and make them more accessible. In the case of the required field, there is a WAI-ARIA role “required.” When this is used, people no longer need to be told what asterisk means or to guess, their tools will know that it is required and can tell them.

When authors use color combinations that are difficult to read, Internet Explorer allows people to override authors' colors and use combinations that they find easier to read.   Figure 5 shows the Internet Explorer dialog box that allows users to choose colors for text, backgrounds, and links.

Figure 5: Setting colors in Internet Explorer. “Colors” is an option on the “Internet Options” panel

Similarly, Windows has a setting, high contrast mode, which will display every window and button in a Windows' application in a limited palette of colors.

Not only can text be displayed as Braille or spoken aloud by a screen reader, but onscreen it can be resized. Internet Explorer has two options for making text easier to read:

zoom and text size. Zoom is useful for enlarging buttons and banners that are images of text—someone has used a graphics program like Adobe's Photoshop or Microsoft’s Expression Design to use a specific font or create an unusual effect that is not possible withstyle sheets. On the other hand, if the text is text, then an end user can make it larger by setting the text size to “Larger” or “Largest.”

Principle 2: Making User Interfaces Easy to Operate

After someone can perceive all of the objects and information in a Web page, they can begin to interact with it. Whereas the first principle is ensuring that

people have access to the information using the sense they prefer (vision, hearing, feeling), the guidelines in this principle are organized around allowing people to use the input device of their choice, such as a mouse, a keyboard, or a microphone (for voice input).

Guideline 2.1 Keyboard Accessible

Make all functionality available from a keyboard

Many Web applications are designed to be operated by a mouse, but there are many people who are not able to use the mouse. For many Web applications that are designed only for mouse input, this means menus do not pop-up to show submenus or that filled in forms cannot be submitted.

Adding keyboard support to an application can be more complicated than adding mouse support. A mouse is a single switch that is usually only modified with a few keys. A mouse can click on, drag with or hover over an object. A keyboard, on the other hand, has 101 keys that can be combined in a variety of ways and these combinations act differently between browsers and across operating systems. An additional layer of complexity is due to the fact that many assistive technologies are operated via key combinations.    This is another great place to apply Accessible by Default. Ensuring that the building blocks of Web application have keyboard-support built in is the best way to ensure Web applications are keyboard accessible. To this end, Silverlight 2.0 controls have built-in keyboard support.

Guideline 2.2 Enough Time

Provide users enough time to read and use content; Because you don't know how long someone will need to read, understand or interact with content, ensure that if your application has a time limit the user has control over how often the content updates or how long they have to complete a task. There are a few exceptions to this guideline. For example, if the task is a real-time event, such as an auction, and it isn't possible to provide an alternative, then you do not need to provide user control over the event. In some cases, this control is provided by the browser. For example, Internet Explorer allows the user to pause most animations. Most media players, including the Accessible Media Player and Windows Media Player have pause buttons.

• If you are developing an application that is frequently updated with new content, you might consider one of the following options: Allow the user to turn off the time limit by setting a user preference;
• Provide the user a way to set the time limit themselves, through a user preference or some other mechanism;
• Warn the user with a pop-up that time is about to expire and let them extend it by pressing “ok” to extend the time limit.

Guideline 2.3 Seizures

Do not design content in a way that is known to cause seizures

wcag 1.0wcag 2.0 Success Criteria are divided into three Levels. In most cases, organizations will build policy around the fist two levels: Level A and Level AA. Level AAA is the most difficult to achieve, but in some cases, easier to understand. This is the case with this guideline. We suggest teaching developers to avoid creating content that flashes more than three times per second. If that is too restrictive for someone or they push back for some other reason, refer them to the definition of general flash and red flash thresholds: (http://www.w3.org/TR/WCAG20/#general-thresholddef).

You can also refer them to the Photosensitive Epilepsy Analysis Tool (peat) available at: http://trace.wisc.edu/peat/

Guideline 2.4 Navigable

Provide ways to help users navigate, find content and determine where they are

In Guideline 1.3 we discuss the importance of providing structural landmarks that can help people navigate through Web content to emulate the eye scanning through a document. Why is order important? Consider a recipe for cooking pasta: first you boil some water, add dry pasta, and then let it boil for about 10 minutes. That is a meaningful sequence. If it were mixed up somehow, such that you read, “add dry pasta, boil for about 10 minutes, boil some water” you could end up with burnt pasta.

One way to test that your document or application has a meaningful sequence is to use a free tool called inspect32. If you choose “show highlight rectangle” and disable “watch cursor” from the toolbar, as you tab through the links on a page, inspect32 will highlight the links as you tab through them. We'll talk about inspect32 again in Guideline 4.1 and we'll learn more about the rest of the information that inspect32 makes available.

This guideline also suggests providing additional pathways and “secret doors” that will help people more easily find their way to specific pieces of content on a page. People accessing the Web via a screen reader will often get a sense of the structure and contents of a Web page by reading through a list of links on the page. Ensuring that link text makes sense when read out of context is an important strategy to help people gain a quick overview.

This means that a page full of links that say “Click here” or “More” won't be as useful as using a more descriptive link. This usually happens on portal sites where there are many options to choose from: each description of an item is followed by a “More” link. When someone creates a list on one of these pages, all they hear or see is “More. More. More.” In Figure 6, the Microsoft Enable site starts each description with a descriptive link then provides additional information about each story.

The link list for this part of the Microsoft site is:

• Inclusive Innovation Showroom Opens to Demonstrate Accessibility
• Sales manager and busy mom utilizes magnification and screen reader
• Active retiree makes her computer easier to see and use
• Banker enjoys urban exploration with a Pocket PC and screen reader
• Medical researcher, card shark, and speech recognition fan

Principle 3: Making Information Understandable

Now that your content is perceivable to a variety of people and they can operate the controls, can they understand the results of those operations?

Guideline 3.1 Readable

Make text content readable and understandable

At Level A, this means indicating the language of a document. In HTML, an author can indicate language by using a 2 to 3 character code such as “en” for English or “fr” for French. Figure 7 shows an example of IntelliSense—a technique that prompts the user with a list of what they might like to do next. In this case, an author is presented with a list of language codes.

Higher levels of this guideline provide information about making text easier to understand. This includes using the correct spelling for words, following grammatical rules, and checking the reading level of your text. Many tools, such as Microsoft Word, incorporate spellchecking into the interface—typically red squiggles underline misspelled words or an end user can go through a list of misspelled words one at a time.

Reading level tests (readability tests) look at the average number of syllables per word and the average number of words per sentence. It is not a perfect measure of readability, but they can provide a good general indication of the reading level of your content.

Guideline 3.2 Predictable

Make Web pages appear and operate in predictable ways

This basically means: don't surprise the user. If you want the user to move the focus from one object to another, do it in a way that they understand what is happeningand only move focus when someone is expecting it.

When an application is unpredictable or the user loses track of where they are or what they've been doing, at best case they get frustrated and worse case they are disoriented and unable to continue what they were doing. Here are some general design tips for ensuring users find your application predictable and enjoyable to use:

• Don't have the interface change too much as the user moves focus either with the mouse or especially by the keyboard. Some of this is ok, like submenus displaying on mouse hover, but opening a new window or changing focus to something else are too disorienting to users.
• Similarly, as a user begins to interact with an object, don't cause too many things to happen unless the user is well aware of what is about the change. For example, if someone begins to select a country from a drop down menu, let them selectthe country and move to the next control before changing the interface based on their selection.
• If you have a navigation panel or some other set of objects that appear throughout a Web site, keeping them in the same order and with a similar appearance will give users a “handrail” that they can refer to throughout the site. Some sites allow users to customize the order in which objects appear on a page—that's fine, but ensure that the order that the user chooses is honored on pages throughout the site.

Guideline 3.3 Input Assistance

Help users avoid and correct mistakes

As we mentioned before, Accessible by Default techniques such as IntelliSense can help content creators make Web applications accessible. These techniques also help make the Web more usable for everyone. For example, Figure 8 shows that someone has tried to search for “Web content accessbility guidelnes” using Microsoft Live Search. “Accessibility” and “Guidelines” have been misspelled, and Live Search shows the results for the correctly spelled words as well as an option for the user to see results for the misspelled words.

Other examples include the accelerators and other predictive features in Internet Explorer 8, such as visual search and the smart address bar.

Principle 4: Making Information Work Reliably with User Tools

Of all of the guidelines that are worth the transition to WCAG 2.0 from WCAG 1.0, this Principle is the key. The core of interactive Web application accessibility is covered in Principle 4.   We mentioned WAI-ARIA earlier, and it’s here that it really shines.

Guideline 4.1 Compatible

Maximize compatibility with current and future user agents, including assistive technologies

Part of making applications work with assistive technologies is how you communicate with them. An accessibility Application Programming Interface (API) is the language that an application uses to communicate with an assistive technology. APIs provide the vocabulary for an application to describe what role an object plays in an interface (a button or a checkbox), what the state of the object is (is the checkbox checked?), and what you can do to an object (push a button, check a checkbox). APIs also allow an application to tell the assistive technology, “My content has updated. Here's what has changed.” The assistive technology can then determine how and when to tell the end user about the changes.

Silverlight applications and Internet Explorer both use APIs to communicate with assistive technologies. Internet Explorer was the first browser to expose HTML elements to the Microsoft Active Accessibility Interface and is one of the first browsers to implement WAI-ARIA to extend that support. Microsoft continues to work with the W3C to standardize the mapping of HTML information to accessibility APIs.

One way to test how well an application communicates with an assistive technology is to use insepct32—a free tool from Microsoft. What sorts of information should you look for? If something looks like a checkbox, is it identified as a checkbox or is identified as something else, like a graphic? If it is a checkbox, can you tell if it is checked or not checked? These are just two examples of the types of information you can learn about a user interface element in an application. With WAI-ARIA, the amount of information available about an HTML widget is much richer. A similar tool is available to inspect accessibility information in Silverlight applications. It’s called UIAVerify and is also freely available from Microsoft.

Another important aspect of this guideline is ensuring that the HTML used to create a web page is written in accordance with standards. This is what people mean when they talk about “valid code”—it is HTML that has been run through an automatic checker to ensure it meets the language standards. This is another example where Accessible by Default can have a huge impact. Expression Web, Live Writer, and other Microsoft tools make it easy for content creators to generate valid code and also make it easy to test for and correct validation errors; in some cases, the code produced by these tools automatically validates, requiring nothing further from an end user.

Conclusion

In this chapter we looked at the twelve guidelines in the Web Content Accessibility Guidelines 2.0. We learned the basic gist of each guideline and showed strategies for meeting each of them. In some cases, we showed how following the guidance allows end users to access Web content and some tips to help you figure out if content meets the guidelines. We also talked a bit about testing and the different types of testing that an organization should do to ensure that the content meets the design specifications, that it meets accessibility requirements, and that it is usable to people with a variety of needs.