Table of Contents- Page 1
- Introduction
- Accessibility and the Law
- Accessibility Issues in Web Pages
- Recommendations for Maximizing Accessibility
- Assisting Navigation
- Identifying Elements and Accessing Alternate Content
- General Recommendations
- CSS Style Sheets
- Testing Your Sites and Applications
- Page 2
- Server Control Accessibility Enhancements in ASP.NET 2.0
- Example 1: Accessibility with HtmlLink and GridView Controls
- Linking a CSS Stylesheet with the New HtmlLink Control
- Connecting a Label Control and Specifying a HotKey
- Page 3
- Captions, scope, and headers Attributes in the GridView Control
- Adding a Table Caption
- Specifying Meaningful Column Names
- Specifying the Row Header in a GridView Control
- Viewing the Results in the IBM Home Page Reader
- About the Author
- download sample code
Introduction Some two years ago, I was honored to be part of the design review panel for ASP.NET, looking at the proposed feature set for version 2.0. That seems a long time ago now, but one of concerns I expressed at the time was that ASP.NET should provide better support for developers to add features to their pages that improve accessibility for all users. The World Wide Web Consortium (W3C) and many other industry bodies have long been pushing for wider support across all sites for disabled and disadvantaged users, many of whom use special types of user agent to access Web pages. The W3C issues guidelines under the umbrella of the Web Accessibility Initiative (WAI), whose mission is "...to lead the Web to its full potential..." includes amongst its goals "... promoting a high degree of usability for people with disabilities" (see http://www.w3.org/WAI/ for more details). Other sites provide useful guides, software, and tools that make it easier to build and test pages that maximize accessibility. You only have to search the Web for "Web Accessibility Guidelines" to get some idea of the variety and number of sites devoted to this topic. However, this article is not a general reference to accessibility issues or a primer on building accessible pages. What it does cover is how the ASP.NET team at Microsoft has added new features to the Framework that you can take advantage of in your Web applications to more easily provide better support for alternative types of browsers and user agents. It involves little extra effort on the part of the developer but can make the world of a difference to users. Accessibility and the Law While the issues of providing reasonable accessibility for as large a proportion of the population as possible might seem to be justifiable on their own, you also have to consider the legal ramifications of not following such a policy. As in most walks of life, governments are unwilling to leave it to industry to manage their own affairs. To some extent, this is understandable - the W3C accessibility initiatives have been around for a while, yet recent surveys show that only a small number of "large commercial Web sites" (around 20%) have made any real attempts at implementing them. In the US, the accepted standards are based on the Section 508 Standards for Electronic and Information Technology (see http://www.access-board.gov/sec508/guide/). These were originally aimed at companies providing products or services to government departments and public bodies, stating that: "Any organization or company that contracts with the Federal government must ensure that its Web site and electronic data are available to the public in a manner that is accessible to people with disabilities." The meaning of the phrase "contracts with" is becoming more tenuous as time goes by... In Europe, in June 2002, the eEurope Action Plan was adopted by the Feira European Council. One of the specific targets of this plan is to improve access to the Web for people with disabilities and, of course, to adopt and implement the results of the Web Accessibility Initiative project. A statement from the council says that: "In Europe, we have now clearly established that actions must be taken to identify and remove these [accessibility] barriers. The European Commission is fully committed to this goal." In the United Kingdom, a 1999 Act of Parliament, The Disability Rights Commission Act is in force, and in 2003 the commission began a formal (and ongoing) investigation into Web site accessibility for disabled people. It is currently carrying out "... a systematic evaluation of the extent to which the current design of websites ... facilitates or hinders use by disabled people in England, Scotland and Wales." It is also performing "...analysis of the reasons for any recurrent barriers identified by the evaluation ..." and producing "... recommendations for further work which will contribute towards enabling disabled people to enjoy full access to, and use of, the Web." Probably the most direct and unequivocal indication of the way governments around the world are beginning to involve themselves in accessibility issues is from Australia. Dr. Sev Ozdowski, the acting Disability Discrimination Commissioner at the time, said: "Under the Federal Disability Discrimination Act - as well as under equivalent laws in all Australian States - it is unlawful to discriminate against a person on the grounds of their disability by having a Web site which they cannot access." ... "The World Wide Web Consortium has developed Web access guidelines, and non-compliance with them by the operators of Australian Web sites is in breach of the Act." And, to demonstrate how the Australian law has already been applied, probably the most famous of all actions taken by disabled Web users was when Bruce Maguire (a blind person) cited the Act in a claim against the Sydney Organizing Committee for the Olympic Games, which were held in 1999/2000. He complained to the committee that images on the Olympics.com Web site had no text equivalent for screen readers and Braille displays. SOCOG failed to react to directives and were fined A$20,000. There are similar clauses in the UK Disability Discrimination Act, the US Americans with Disabilities Act, the Canadian Human Rights Act, plus various provincial, state, and territorial human-rights codes. Following settlement of the claim and the subsequent fine on SOCOG, the Toronto-based Web Content Consultancy contenu.nu stated that: "The case of Maguire vs. SOCOG will inevitably come into play as a precedent for legal cases worldwide." Accessibility Issues in Web Pages Web pages today are very different from the original vision of the World Wide Web pioneers. They saw it as a sharing and publishing environment for scientific information, rather than the public network offering online retailing, the source of references material on every topic under the sun, and the general entertainment arena that it has now become. Wide public access and the continuing commercialization of the Web have brought changes in the type of content it offers. The most remarkable change has been the move away from the functional, mainly text-based, types of pages. Today, the Web is ruled as much by designers and graphic artists as by developers and network specialists. Web pages have become more complicated. No longer is it permissible for your company "home page" to contain a picture of your offices and a simple text menu for the services you offer. Now you have to have drop-down or pop-up menus with myriad links, graphics (preferably animated), and dozens of headlines that lead to press releases, new product details, or testimonials of your services. All this is fine if your visitors can look at the page and easily identify the areas that interest them, or scan up and down the links to other pages looking for what they want. And, should they stray to the wrong page, it's usually pretty obvious from a quick glance. However, things are nowhere near this easy for all visitors. A proportion of visitors will have difficulties with most current Web sites, which are designed almost without exception for people who have reasonable eyesight and are using a pointer device such as a mouse, trackball or graphics tablet. There are many people to whom one or both of these conditions cannot be applied. Often they will be using a specially designed user agent, or maybe a simple text-based browser. Or it might be aural page reader, which reads the contents of pages out loud, or a Braille reader that translates the text into a format that can be read by fingertip on a special output device. For all these types of device, even the most basic Web site or Web application (designed and tested only in a modern graphical browser such as Internet Explorer) can be hard to read. At best, navigation through the site can be challenging, and certain parts of the content may be meaningless. Graphics and pictures won't be displayed on text-based devices, while color-blind users may not be able to distinguish between the different lines or pie segments in your charts. At worst, it may be completely impossible use online forms, to even access parts of the site at all. Areas for Improvement Accessibility problems for Web sites generally fall into three areas: - Navigation issues - how easy is it to find and load specific pages without images and without the traditional pointing devices?
- Visual content issues - do parts of the site depend solely on images and/or colors to provide information, which color-blind, partially sighted and blind users will not be able to access?
- Data input issues - on pages where the user has to interact with controls, is this possible without a mouse, graphics tablet or other type of pointing device?
Unfortunately, it's not easy to cleanly subdivide the techniques you should be using to improve accessibility into these three simple categories. Some features span more than one category, as you'll see when we look at them in more detail.
This article is about the accessibility improvements in ASP.NET 2.0. These improvements are mostly implemented as new or updated features for the sever controls that are a fundamental part of ASP.NET. So, it makes sense to look at them on a control-by-control basis. However, for completeness, we've summarized the general technical recommendations that are part of the W3C Web Accessibility Initiative in the next section. Not all of the topics it covers are applicable to this article, as they are not directly achievable just through the enhancements to the ASP.NET 2.0 control set. Recommendations for Maximizing Accessibility This section summarizes the recommendations for improving accessibility for visitors in your Web pages and Web applications. For more details see the W3C site at http://www.w3.org/TR/WCAG20/. Assisting Navigation - Provide one or more hyperlinks that point to the content areas of each page as the first item in that page (before any headings, images, etc). These "skip to" links allow users to go straight to the content without having to navigate past your menu bars or other sets of site navigation links. Alternatively, use CSS absolute positioning to place the menu bars or site navigation links at the end of the page source, yet still allowing them to appear at the top or left of the page when rendered in the browser.
- Make the structural layout of every page similar (if this is appropriate for the content)
- Include a meaningful <title> element in every page
- Avoid self-referring links (links that reference the current page)
- Avoid meaningless text such as "click here" in hyperlinks
- Lay out the content of HTML tables so they can be read from left to right (rather than vertically) and still make sense
- Use <th> elements for the columns and row headings in a table
- Add a scope attribute to all table row and column headers, to indicate that the header cell identifies the data in that row (scope="row") or column (scope="col"). The new and updated server controls in ASP.NET 2.0 make this much easier
- Put control captions in the "expected" places on an HTML <form>, for example to the left of a textbox or list control and to the right of a radio button or checkbox
- Use <label> elements on complex forms, with the for attribute to link them to the control to which they apply.
Identifying Elements and Accessing Alternate Content - Include a name and a title attribute on all <frame> elements and include a <noframes> section for user agents that don't support frames, explaining how to access the content in this case
- Include a title attribute in all interactive elements, such as <a>, <input>, <select>, <textarea>, etc.
- Include an alt attribute on every image element, containing a brief but meaningful text description of the image
- Use the longdesc attribute or the widely accepted "d-link" approach to provide a link for any content that is graphical in nature to display a separate page containing a description of the content. Remember that aural content may not be suitable for all users, and so provide a text description or transcript where possible as well.
- Always include alt="" (an empty string) on images that do not contribute to page content
- Include an alt attribute in every <area> definition of a client-side image map, and avoid server-side image maps - which cannot be described to user in any kind of meaningful way
General Recommendations - Use generic font sizes such as x-small and large to allow the user to enlarge the display font in their browser
- Provide alternative text content, where possible, inside all <object> or <applet> elements, but outside any <param> elements they might contain
- Do not generate visual content with client-side script, or - if you must - use a <noscript> section for alternative content
CSS Style Sheets - Link your CSS style sheets using a <link> element so that the user agent can decide whether to download them or not, and they can be cached and reused in other pages if applicable:
<link rel="stylesheet" title="Default" href="defaultstyle.css" type="text/css" />
- Consider providing multiple style sheets that specify (for example) monochrome colors or larger text sizes. Use a specific value for the title attribute of each one, and indicate that it is an alternative stylesheet by using rel="alternate stylesheet" in the <link> element.
- Note that not all browsers and user agents allow the user to specify the stylesheet to be applied, though some allow users to specify their own custom stylesheet
- Page readers and devices output content in the order it occurs in the page source. CSS absolute positioning can be used to position elements in Web browsers while providing optimum order for page readers, for example, menus and non-informational content can be placed visually at the top of the page, while being located at the end of the page source
Testing Your Sites and Applications Appreciating that you need to improve accessibility in your own sites, or build it into new sites, is only half the battle. Knowing where to start, what to do, and how best to do it is not easy. There are tools to help you check your pages. Examples can be found at the Watchfire 'Bobby' Accessibility Test Tools site (http://bobby.watchfire.com/), UsableNet (http://www.usablenet.com/) and at http://cast.org/products/. Guidelines and standards can be found at W3C's own site: the Web Content Accessibility Guidelines are at http://www.w3.org/TR/WAI-WEBCONTENT/, and the W3C Policy and Laws Guide by Country are at http://www.w3.org/WAI/Policy/. Other more direct techniques are to test your site using one of the specialist browsers or user agents. Try accessing your pages in a text-only browser such as Lynx (http://lynx.browser.org/) to see if you can navigate through all the pages without a mouse, and understand what they contain when there are no images. Or try an aural page reader, such as the IBM Home Page Reader (http://www-306.ibm.com/able/solution_offerings/hpr.html). Turn off your screen and see if you can navigate through your own site when the links and content are read out aloud. • Server Control Accessibility Enhancements in ASP.NET 2.0 >>
|
