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.
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.
Do not design content in a way that is known to cause seizures
WCAG 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. 
Figure 6: Example of link text that makes sense when read out of context
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?
Make text content readable and understandable
 Figure 7: An example of IntelliSense, a list of language codes in Expression Web
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 (or 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 happening and 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 select the 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.
Figure 8: Live Search showing search results for the correct spelling of a search term as well as the misspelled phrase
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.
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.
Conclusion
Throughout this guide we’ve learned about practical strategies for making web content accessible and that there are several pieces that need to fit together to create an organizational approach to accessibility. We’ve learned how important it is for an organization to set accessibility standards and seen a real-world example, the Accessibility Kit for SharePoint, that helps integrate accessibility testing into the development process—making it easier to meet organizational standards. We’ve seen how accessibility can increase sales and decrease maintenance costs, building a good business case for integrating accessibility into an organization’s web development processes. A key strategy for helping developers implement accessibility is to make it easy for them to make the right decisions and we learned about several examples of Accessible by Default, where accessibility strategies are built into development products.
The European Dialogues on Web Accessibility have been a rewarding experience and created the basis for an evolving body of knowledge that can help us reach our shared goal of an accessible Web. Microsoft and HiSoftware will continue to partner with others to improve the Riga Dashboard and increase web accessibility.
List of Resources Microsoft Products
Accessible Media Player: http://www.codeplex.com/amp
inspect32: http://www.microsoft.com/downloads/details.aspx?familyid=3755582A-A707-460A-BF21-1373316E13F0&displaylang=en
Internet Explorer: http://www.microsoft.com/windows/products/winfamily/ie/
Microsoft Expression (includes Studio, Design, Web, Media, Blend and Encoder): http://www.microsoft.com/expression/
Microsoft Office: http://office.microsoft.com/
Microsoft Office SharePoint Server (MOSS): http://www.microsoft.com/Sharepoint/
Silverlight: http://silverlight.net/
Windows Live (including Live Writer): http://windowslivewriter.spaces.live.com/
Windows Media Player: http://www.microsoft.com/windows/windowsmedia/player/
HiSoftware Products
Accessibility Kit for SharePoint: http://aks.hisoftware.com/
HiSoftware solutions for accessibility:
http://www.hisoftware.com/hmcc/
http://www.hisoftware.com/MOSS/MOSSsolutions.htm
W3C Standards
The World Wide Web Consortium (W3C) maintains the following Web standards.
Cascading Style Sheets (CSS): http://www.w3.org/TR/CSS/
Hypertext Markup Language (HTML): http://www.w3.org/TR/html/
Web Accessibility Imitative Accessible Rich Internet Applications (WAI-ARIA): http://www.w3.org/WAI/intro/aria.php
Web Content Accessibility Guidelines (WCAG) 1.0: http://www.w3.org/WAI/intro/wcag10docs.php
WCAG 2.0: http://www.w3.org/WAI/intro/wcag20.php
About This Guide
This guide was created by Microsoft and HiSoftware to summarize the practical strategies discussed at the European Dialogues on Web Accessibility. Contributors to this guide include James Thurston, Dana Simberkoff, Cynthia Shelly, and Wendy Chisholm.
Microsoft
Microsoft Corporation is a multinational computer technology corporation that develops, manufactures, licenses, and supports a wide range of software products for computing devices. Founded in 1975, Microsoft is the worldwide leader in software, services and solutions that help people and businesses realize their full potential. More information about Microsoft accessibility is available at: http://www.microsoft.com/enable/
HiSoftware
Founded in 1998, HiSoftware is a leading provider of software, services, and on-demand solutions that test, repair, monitor and enforce audited Web content, quality, and regulatory compliance. The company’s solutions empower content developers, Web site architects, and executives to work collaboratively to create and manage corporate Web standards for accessibility, financial banking compliance, privacy, operational security, search engine optimization, site quality and performance, and application transaction testing. With over 4,000 customers across 88 countries, HiSoftware’s clients boast many of the world’s largest public and private sites including US and international government agencies and Global 2000 companies such as Gateway, HP, California State University, US Department of Transportation and Microsoft. For more information about HiSoftware and its solutions go to www.hisoftware.com
There is now the opportunity and the imperative to make real progress toward a more inclusive society through an accessible Web.
This handbook from Microsoft and HiSoftware is one result of a series of interactive dialogues on the current state of Web accessibility between government officials, industry leaders, and NGO representatives across several European countries. It combines practical strategies with some of the perspectives, goals, and vision that came out of those dialogues. Our intent is to provide a tool that will help organizations worldwide foster accessibility in their operations.
This handbook begins with a summary of the important knowledge shared at the series of European dialogues on Web accessibility. Those lessons-learned and best practices are followed by an example process for implementing a comprehensive Web accessibility program in any organization. Building on that framework, there is an example of a product and community that helps organizations implement some of the practical strategies from the dialogues. Finally, there is a discussion of specific tools and tips to understand and meet Web accessibility standards.
Dostları ilə paylaş: |
