Aspnet 2

  • November 2019
  • PDF
Download

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA

Overview

Download & View Aspnet 2 as PDF for free.

More details

  • Words: 14,763
  • Pages: 64
ASP.NET Technical Articles Building ASP.NET 2.0 Web Sites Using Web Standards Stephen Walther SuperExpert.com Applies to: Microsoft ASP.NET 2.0 Microsoft Visual Studio 2005 Microsoft Visual Web Developer Summary: Microsoft ASP.NET 2.0 has many features to help you design and build Web sites that are compliant with XHTML and accessibility standards. This article looks at how and why you should be building these standards-compliant sites. (78 printed pages) Contents Introduction Building XHTML Web Sites Versions of the XHTML Standard Creating XHTML Pages XHTML and ASP.NET Controls Validating XHTML Pages XHTML and DOCTYPE Switching XHTML and MIME Types Configuring XHTML Conformance Accessibility Standards Accessibility Improvements in ASP.NET 2.0 Creating Accessible Images Creating Accessible Forms Creating Accessible Navigation Creating Accessible Data Creating Accessible XHTML Creating Accessible Scripts Validating Pages for Accessibility Accessing the Amazon Web Services The Default Page XHTML Features of the Default Page Accessibility Features of the Default Page The Search Page XHTML Features of the Search Page Accessibility Features of the Search Page The Master Page XHTML Features of the Master Page Accessibility Features of the Master Page

Introduction Web standards enable you to build Web sites that are accessible to the broadest possible audience with the least amount of work. The promise of Web standards is that you can design a page once and have the page appear and function in exactly the same way in any modern browser. For example, when built against standards, a page that was designed to display a certain way in Microsoft Internet Explorer can appear the same way in other browsers, such as Mozilla Firefox, Netscape Navigator, Opera, Camino, and Safari, without requiring you to perform any additional work. An additional benefit of Web standards is that they make your Web sites more easily accessible to persons with disabilities. This is a broad audience that includes everyone from a middle-aged person with failing eyesight, to a person who just broke his or her arm while skiing, to a person who is completely blind. Standards prevent you from unintentionally blocking persons with temporary or permanent disabilities from your Web pages. The Microsoft ASP.NET 2.0 framework was designed to be the best framework for building Web sites that meet public Web standards. In particular, every control in the ASP.NET 2.0 framework was extensively reviewed and tested against both XHTML and accessibility standards. Furthermore, Microsoft Visual Studio 2005 includes new tools for validating your Web pages against both XHTML and accessibility standards. The purpose of this paper is to provide you with an overview of XHTML and accessibility standards, and explain how you can take advantage of ASP.NET 2.0 and Visual Studio 2005 to meet these standards. At the end of this paper, you are provided with a step-by-step walkthrough for creating an ASP.NET 2.0 Web site that satisfies both XHTML and accessibility standards.

Building XHTML Web Sites HTML is officially outdated. The World Wide Web Consortium (W3C) published the first version of XHTML as a recommendation on January 26, 2000. The XHTML standard is intended as a replacement for HTML. According to the W3C, "XHTML is the successor of HTML" (http://www.w3.org/MarkUp/). The framers of the XHTML standard have two broad goals: • •

Create a cleaner separation between document structure and presentation. Reformulate HTML as an application of XML.

In pursuit of the first goal, the W3C has been steadily removing purely presentational elements and attributes from HTML (a process that they started with HTML 4.0). For example, XHTML 1.0 Strict does not include elements such as the tag, or attributes such as the bgcolor attribute, because these elements and attributes are used

solely to describe the appearance of a document, and they have nothing to do with a document's structure. The W3C has been attempting to wean Web site designers and developers away from the idea that any particular tag should have any particular appearance. For example, you might think that the purpose of an

tag (the heading tag) is to render large, bold text in a page. That would be wrong. The

tag is used to mark a heading in a document, and nothing else. It is up to the browser to determine how the heading tag should be rendered. A screen reader used by a person with reduced eyesight might read aloud the contents of a heading tag with a booming, authoritative voice. A PDA, which doesn't support multiple font sizes, might render the contents of a heading tag with blinking text. You should not attempt to use page elements, such as the

tag, to control the appearance of a Web page. Instead, you should indicate the appearance of a Web page through the use of Cascading Style Sheets. Preferably, the Cascading Style Sheets should be external Cascading Style Sheets. Use tags and attributes to mark up the structure of a document, and use Style Sheets to control the document's presentation. The second goal of XHTML is to enforce the stricter rules of XML on HTML developers. In the words of the W3C, "XHTML 1.0 is a reformulation of HTML 4.01 as an XML 1.0 application" (http://www.w3.org/MarkUp/). In other words, when you build a Web page using XHTML, you are actually creating an XML document. An XML document has a much stricter syntax than an HTML document. For example, XML is case-sensitive, all XML attributes must be quoted, and XML tags cannot overlap. Forcing Web site developers and designers to follow the rules of a more demanding language has many benefits. One benefit is that pages written with XHTML markup are more cross-browser, crossdevice, and cross-operating system compatible. If you open a traditional HTML page in a browser, the browser will make every effort to render the page. The browser will attempt to render the page even if your HTML is a total mess. For example, Internet Explorer (and Firefox and Opera) will display the following HTML page just fine. this is bold and italic and this is bold

Internet Explorer happily displays this page, even though the page is missing opening and tags, the tag has no matching closing tag, and the case of the opening and closing tags is inconsistent. All major browsers will accommodate almost any "tag soup" of HTML tags and desperately attempt to render something. This accommodating behavior of browsers is dangerous, because different browsers (or future versions of the same browser, or the same browser running on a different operating system) might render garbled HTML in different ways. In point of fact, the latest versions of Internet Explorer, Mozilla Firefox, and Opera are surprisingly consistent in the way

that they render invalid HTML. However, once you start to play outside of the rules, there are no guarantees. If you write your Web pages with the stricter rules of XHTML, however, there is more of a chance that your Web pages will work consistently with current browsers, and that they will continue to work with new versions of current browsers introduced in the future. Few companies have the resources to test their Web sites against every browser running on every operating system and every device. If you write your pages against Web standards, you don't have to.

Versions of the XHTML Standard There are three versions of XHTML 1.0, which correspond to the three versions of HTML 4.01: • • •

XHTML 1.0 Transitional XHTML 1.0 Strict XHTML 1.0 Frameset

XHTML 1.0 Transitional contains all of the tags and attributes from HTML 4.01 Transitional. The XHTML 1.0 Transitional standard was introduced to enable existing HTML designers and developers to migrate to XHTML without experiencing too much shock and pain. XHTML 1.0 Strict differs from XHTML 1.0 Transitional by enforcing a cleaner separation between document structure and presentation. Unlike XHTML 1.0 Transitional, XHTML 1.0 Strict forces you to use Cascading Style Sheets to control the appearance of your pages. XHTML 1.0 Frameset documents are intended to be documents that use the tag to partition a browser into multiple frames (XHTML 1.0 Transitional and Strict pages cannot contain the tag). The W3C has also published XHTML 1.1 as a recommendation (on May 31, 2001). XHTML 1.1 is very similar to XHTML 1.0 Strict. The primary difference is that XHTML 1.1 can be extended with additional modules in order to support new elements. You can, for example, build XHTML 1.1 pages that also include elements from the MathML (the Mathematical Markup Language), or SVG (the Scalable Vector Language), or a custom module of your own creation. Finally, the W3C is working on a recommendation for XHTML 2.0. Because XHTML 2.0 is still in the draft stage, and no Web browser currently supports this standard, we won't discuss it in this paper. The ASP.NET 2.0 framework and Visual Studio 2005 are targeted at XHTML 1.0 Transitional. This is the least restrictive of the XHTML standards, and it is the standard

that is the most compatible with existing HTML pages. However, you can also build ASP.NET 2.0 pages that target the XHTML 1.0 Strict standard or even the XHTML 1.1 standard (see the later section, Configuring XHTML Conformance).

Creating XHTML Pages Unlike an HTML page, an XHTML page must be a well-formed and valid XML document. The differences between HTML and XHTML are summarized in Section 4 of the XHTML 1.0 recommendation. Here's a list of the most important requirements for building a valid XHTML page: 1. The page must include a valid XHTML DOCTYPE. A valid XHTML page must include an XHTML DOCTYPE before any of its content. When you create a new ASP.NET page in Visual Studio 2005 or Microsoft Visual Web Developer, the correct DOCTYPE for XHTML 1.0 Transitional is automatically included in the page. Here are the four standard XHTML DOCTYPES: XHTML 1.0 Transitional

XHTML 1.0 Strict

XHTML 1.0 Frameset

XHTML 1.1

Adding a DOCTYPE to a page has an impact on how the page is rendered in a browser. See the section below entitled XHTML and DOCTYPE Switching. 2. The root element must refer to the XHTML namespace The opening tag of an XHTML page must specify a default namespace of http://www.w3.org/1999/xhtml. Here's a sample of a valid opening tag for an XHTML 1.0 Transitional page.


xml:lang="en" lang="en">

3. All element and attribute names must be lowercase. XML is case-sensitive. Therefore, there is a difference between the

tag and the

tag. Only the former is a valid XHTML paragraph tag. 4. Attribute values must always be quoted. Always wrap attribute values in either double or single quotation marks. For example, the following is invalid XHTML. Next

In this case, the href attribute is missing quotation marks. The following is valid XHTML. Next

You can configure Visual Studio 2005 and Visual Web Developer to automatically quote attribute values, by selecting the menu option Tools, Options, Format. 5. All non-empty elements that have an opening tag must have a matching closing tag. If you have an opening

tag, then you must include a closing

tag to mark the end of the paragraph. In the case of tags that never contain any content, such as the
tag, you can either supply a both an opening and closing

tag, or you can use the empty element shorthand
. In order to make your XHTML pages backward-compatible with existing HTML browsers, you need to be careful about how you open and close your tags. For example, existing HTML browsers tend to misinterpret an opening and closing

tag as two
elements. For that reason, you should use the empty element shorthand
. Furthermore, existing HTML browsers have problems with the empty element shorthand
unless you are careful to add a space before the closing slash. So, you should add a
element to a page using
and not
. 6. There must be no overlapping tags. You can nest tags, but you are not allowed to overlap tags. For example, the following XHTML is valid. This is bold and italic

However, the following XHTML is invalid. This is bold and italic

7. There must be no attribute minimization. All attributes must have a value, even when it looks a little strange. For example, the tag is invalid XHTML, because the checked attribute does not have a value. The tag should be written . 8. The id attribute must be used instead of the name attribute. In HTML, you use the name attribute to identify , ,
, , <iframe>, , and <map> elements. While you can use the name attribute when building XHTML 1.0 Transitional pages, the name attribute has been removed from the XHTML 1.0 Strict and XHTML 1.1 standards. You should use the id attribute to identify these elements instead. 9. The contents of <script> and <style> elements must be wrapped in CDATA sections. If you use special characters such as < or &, or entity references such as < or & in a script or style sheet, then you'll need to mark the contents of your script or style sheet as a CDATA (character data) section, as follows. <script type="text/javascript">

Notice that the JavaScript function contained in the script includes a < character. If you do not wrap the script in a CDATA section, then the < character would be interpreted as marking the start of an XHTML tag. Using a CDATA section will not work with all browsers. For example, Internet Explorer considers a CDATA section in a <script> tag a syntax error. You can avoid this problem by adding JavaScript comments, as follows. <script type="text/javascript"> /*
if (a < b) return true; } /* ]]> */

JavaScript uses /* and */ to mark the beginning and end of a comment. Therefore, the CDATA section is hidden from the JavaScript, but not from the browser that parses the page. In general, it is a better idea to place your style rules and scripts in external files and reference the files from your XHTML pages. Using external style sheets and scripts enables you to avoid all of these issues.

XHTML and ASP.NET Controls Every ASP.NET control included in the ASP.NET 2.0 framework renders valid XHTML by default. In other words, you don't need to do anything special to generate valid XHTML markup when adding ASP.NET controls to a page. For example, if you add a GridView control to a page, the GridView control will generate valid XHTML markup. Three points need to be clarified here. First, the source code of a page that contains ASP.NET controls will not validate as XHTML. When validating an ASP.NET page, you need to validate the rendered content of the page (everything that you see when you select View Source in Internet Explorer) and not the source of the page. Second, there is nothing that prevents you from writing invalid XHTML when creating an ASP.NET page. You can, of course, add any tag to an ASP.NET page that you want. For example, if you add a tag to your page, then your page will not validate as XHTML 1.0 Strict. Finally, there are no guarantees when you use custom ASP.NET controls. If you buy a third-party ASP.NET control—for example, a super enhanced DataGrid control—the control may or may not render valid XHTML. It's the control vendor's responsibility to do the right thing.

Validating XHTML Pages Visual Studio 2005 and Visual Web Developer automatically validate your Web pages as you build the pages. Validation problems are indicated in Source view by either green or red squiggles under the offending content. Red squiggles correspond to validation errors such as a missing closing tag. Green squiggles correspond to validation warnings such as the use of deprecated tags. You can hover your mouse over any squiggle to view a ToolTip that contains the validation error or warning message (see Figure 1). Alternatively, you can view a list of

validation errors and warnings in the Error List window (select View, Other Windows, Error List).

Figure 1. Validating an XHTML document (Click the graphic for a larger image.) By default, Visual Studio 2005 and Visual Web Developer are configured to validate pages against the Internet Explorer 6.0 schema. If you want to validate your pages against an XHTML schema, then you need to select one of the XHTML schemas from the dropdown list in the toolbar, or you can select Tools, Options, Validation to select a target schema. As an alternative, you can validate your ASP.NET pages by using the W3C validation service. The W3C validation service enables you to validate a page by supplying a URL or by uploading the source of an XHTML page.

XHTML and DOCTYPE Switching Specifying a DOCTYPE for a Web page impacts the way in which the page is rendered by a browser. Internet Explorer, Mozilla Firefox, and Opera all support a feature called DOCTYPE Switching (also called DOCTYPE Sniffing). DOCTYPE Switching was introduced to enable browsers to render both standardscompliant and legacy Web sites correctly. Most Web sites were developed to render HTML pages and not XHTML pages. Browsers use the presence of a DOCTYPE to determine when a page should be rendered by using standards.

Internet Explorer 6+ supports two rendering modes, called Quirks mode and Standards mode. When Internet Explorer renders a page that contains a valid XHTML (or HTML 4.0) DOCTYPE, it renders the page in Standards mode; otherwise, it renders the page in Quirks mode (for details, see CSS Enhancements in Internet Explorer 6). The Opera browser (Opera 7+) supports the same two rendering modes (Quirks and Standards) as Internet Explorer (for details, see http://www.opera.com/docs/specs/doctype/). Mozilla Firefox 1+ supports three rendering modes: Quirks mode, Almost Standards mode, and Standards mode. Firefox's Almost Standards mode corresponds to Internet Explorer's and Opera's Standards mode. When a page contains a valid XHTML 1.0 Transitional DOCTYPE (and it is served with a text/html MIME type), Firefox renders the page in Almost Standards mode. When a page contains either an XHTML 1.0 Strict or XHTML 1.1 DOCTYPE (or the page is served with an XML MIME type), the page is rendered in Standards mode (for details, see http://www.mozilla.org/docs/webdeveloper/quirks/doctypes.html). You can determine a browser's current rendering mode by temporarily adding the following client-side script to a page (this script works in the latest versions of Internet Explorer, Firefox, and Opera). <script type="text/javascript"> alert( document.compatMode );

You need to care about the browser rendering mode, because it affects the way in which Cascading Style Sheets are applied to the page. If you convert your existing HTML pages into XHTML pages, they might look very different when you open them in your browser. For example, Internet Explorer calculates the size of page elements in different ways, depending on the rendering mode (it uses a different CSS Box Model). In Quirks mode, the width of an element is calculated by summing the width of the element's content, padding, borders, and margins. In Standards mode, the width of an element is calculated by taking into account only the width of the element's content. For example, consider the following two
tags.
First Box
Second Box


The two
elements are the same, except for the second
element's additional padding. In Quirks mode (see Figure 2), the two
elements appear to be the same size, because the additional padding of the second
element is taken into account when calculating its width (the total width of both elements is 400px). In Standards mode (see Figure 3), the second
element appears wider than the first
element, because padding is not taken into account when calculating the width of an element (the total width of both elements is wider than 400px).

Figure 2. Quirks mode

Figure 3. Standards mode

This is only one example of browser differences in Quirks mode. In Quirks mode, each browser implements the W3C Cascading Style Sheet standards in significantly different ways. The beautiful thing about switching to Standards mode is that it forces almost all modern browsers to interpret the W3C standards in a very similar way (not exactly the same, but much better). If you want your Web pages to appear in the same way across browsers, then it is a good idea to trigger Standards mode (in Internet Explorer and Opera) and Almost Standards mode (in Firefox), by including an XHTML 1.0 Transitional DOCTYPE. Fortunately, Visual Studio 2005 and Visual Web Developer automatically add this DOCTYPE, by default, to every new page ASP.NET page.

XHTML and MIME Types When a Web browser requests a page from a Web server, the Web server serves the page with a certain MIME type (also called a Content type). For example, an HTML page is served with the text/html MIME type, a GIF image is served with an image/gif MIME type, and a Microsoft Word document is served with an application/msword MIME type. A browser uses the MIME type to determine how a page (or other resource) should be handled. For instance, if a browser gets a file from a Web server that has a recognizable image MIME type, the browser attempts to interpret and render the file as an image. If a browser gets a file that has an application/msword MIME type, the browser might automatically open Microsoft Word to display the document (the exact behavior here depends on the browser and how it is configured). The W3C has introduced a MIME type for XHTML documents. This new MIME type is application/xhtml+xml. The W3C recommends that you use the application/xhtml+xml MIME type when serving XHTML documents, because XHTML pages should be interpreted in a stricter way than legacy HTML pages. You can serve an ASP.NET page with a particular MIME type by including the ContentType attribute in a page directive. For example, including the following directive at the top of an ASP.NET page causes the page to be served as application/xhtml+xml. <%@ ContentType="application/xhtml+xml" %>

There is one glaring problem with the W3C's recommendation: not all browsers recognize application/xhtml+xml. In particular, Internet Explorer (the most popular Web browser in the history of the world) does not recognize the application/xhtml+xml MIME type. Therefore, serving your XHTML pages using the recommended application/xhtml+xml MIME type is not a viable option. There are three ways that you can work around this problem. You can serve your XHTML pages by using the text/html MIME type, you can serve your XHTML pages by

using the application/xml (or text/xml) MIME type, or you can use content negotiation. Let's explore each of these options. The first option, serving your pages as text/html, is the easiest option. An ASP.NET page is served with this MIME type by default. Better yet, the W3C recommends this option when serving pages to existing HTML browsers (see http://www.w3.org/TR/xhtmlmedia-types/). If you are creating XHTML 1.0 Transitional pages, and the primary audience for your Web application is using a browser that does not understand the application/xhtml+xml MIME type, then serving your pages as text/html seems perfectly sensible. After all, the XHTML 1.0 Transitional standard was introduced to make it easier for developers to migrate existing HTML pages to XHTML. This claim is controversial. For example, Ian Hickson argues that XHTML pages should never be served as text/html, because this option promotes sloppy, broken XHTML pages (see http://hixie.ch/advocacy/xhtml). He recommends that authors stick to HTML 4.0 until more browsers completely support XHTML standards. The second option is to serve your XHTML pages as XML, using either the application/xml or text/xml MIME type. When Internet Explorer is served an XML document, the document is parsed as an XML document and rendered to the browser. (The document is represented by the XML DOM exposed by the document.XMLDocument object.) The advantage of serving an XHTML document as XML is that any problems with the XHTML document will be caught by Internet Explorer's XML parser. For example, if your document contains overlapping tags, or if the value of an attribute is not wrapped in quotation marks, then the document is not rendered, and an error message is displayed (see Figure 4). XHTML purists consider this behavior a good thing, because it prevents you from writing malformed XHTML.

Figure 4. Displaying XML in Internet Explorer The problem with this approach is that Internet Explorer, by default, renders the source of an XML document. So, if you serve an XHTML document as XML, your Web site visitors will see the source of your XHTML documents and not the desired rendered output. The W3C suggests a "trick" for getting around this problem (see http://www.w3.org/MarkUp/2004/xhtml-faq#ie): If you transform an XHTML document into HTML by using an XSLT transformation, then your document will be parsed as XML and displayed as HTML. For example, the ASP.NET page in Listing 1 will be served as an XML document but transformed into an HTML document. The resulting page displays correctly in Internet Explorer, Opera, and Firefox. Listing 1. XMLPage.aspx <%@ Page Language="VB" ContentType="text/xml" %> My Page




The page directive causes this page to be rendered as text/xml. The second line in the listing refers to an XSLT style sheet, named copy.xsl, that performs an identity transformation on the current document. In other words, it does absolutely nothing, except copy all of the elements from the original XML document into a new HTML document. The source for copy.xsl is contained in Listing 2. Listing 2. Copy.xsl <stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform">

This solution works, but it doesn't seem very elegant. You do get the extra validation step when the XML document is parsed. However, if you are building your ASP.NET pages in Visual Studio 2005 or Visual Web Developer, the same validation is performed by the development environment in Source view. At the end of the day, Internet Explorer receives the same document as it would get if you had sent it text/html. The third option, content negotiation, best combines the spirit of the W3C recommendations with the greatest degree of browser compatibility (see http://www.w3.org/2003/01/xhtml-mimetype/content-negotiation). When you use content negotiation, you serve an ASP.NET page with different MIME types to different browsers. If a browser claims that it supports XHTML, then you serve it XHTML; otherwise, you serve the browser the page with the text/html MIME type. The Global.asax in Listing 3 contains the necessary code for serving different MIME types to different browsers. If you add this file to your Web project, then the MIME type of every ASP.NET page will be modified with each request. When a page is served to Firefox or Opera, the page will be served as application/xhtml+xml. Internet Explorer 6, on the other hand, will receive text/html pages. Listing 3. Global.asax <script runat="server"> Sub Application_PreSendRequestHeaders(ByVal s As Object, _ ByVal e As EventArgs) If Array.IndexOf(Request.AcceptTypes, _ "application/xhtml+xml") > -1 Then Response.ContentType = "application/xhtml+xml" End If

End Sub

Configuring XHTML Conformance The default behavior of the ASP.NET 2.0 framework is to render pages that validate against XHTML 1.0 Transitional. Most developers building Web sites will want to target this standard, because it is the standard that is the most compatible with existing HTML pages. However, there are situations in which this standard might be either too lax or too strict. For example, if you are feeling ambitious, you might decide to build an XHTML 1.0 Strict, or even an XHTML 1.1, Web site. After all, the goal of the XHTML 1.0 Transitional standard is to act as a springboard to these more restrictive standards. Because, by default, the ASP.NET 2.0 framework targets XHTML 1.0 Transitional, some of the ASP.NET controls will render attributes that are not compatible with XHTML 1.0 Strict or XHTML 1.1. Alternatively, you might discover that the XHTML 1.0 Transitional standard is too restrictive. Microsoft had to make several changes to existing ASP.NET 1.1 controls in order to comply with the XHTML 1.0 Transitional standard. Some of these changes might break an existing ASP.NET 1.1 Web site. In order to keep everyone happy, Microsoft created a new configuration option, named xhtmlConformance, that you can set in your Web site's configuration file. The new configuration option enables you to specify the level of XHTML conformance of your Web pages. It looks like this. <system.web> <xhtmlConformance mode="transitional" />

By default, xhtmlConformance is set to the value transitional. However, you can also set this option to the value strict or legacy. If you set the xhtmlConformance option to strict, then certain attributes will no longer be rendered by the standard ASP.NET controls. For example, the ASP.NET
control will no longer render a name attribute. Unless your ASP.NET pages contain (nonstandards-compliant) client-side scripts, you won't notice any changes when switching from transitional to strict mode. If you set the xhtmlConformance option to legacy, then the ASP.NET framework will revert to ASP.NET 1.1 rendering behavior for some elements and attributes (but not all).

In this case, the ASP.NET framework will render content that is not compatible with any XHTML standard, and your pages will no longer validate against the XHTML standards. For example, in legacy mode, the
tag is not rendered with its required XHTML closing slash (
). Setting xhtmlConformance to legacy mode only makes sense when you run into a problem migrating an existing ASP.NET 1.1 application to ASP.NET 2.0.

Building Accessible ASP.NET Web Sites The benefit of following public Web standards is that they make your Web pages accessible to the greatest number of people with the least amount of work. In particular, accessibility standards enable you to build Web sites that can be more easily accessed by persons with disabilities. It is worth emphasizing, once again, that a broad audience of Web site users has one form of disability or another. Think of the members of your own family and consider how many of them would have trouble interacting with a Web page. I have aging relatives who are blind or who are losing their motor coordination. My guess is that many readers of this paper also have aging parents or grandparents who would find it challenging to use most Web sites. There are many good reasons for building accessible Web sites: financial, moral, legal, and so on. Let's concentrate, however, on the legal motivations. In the United States, any Web site developed by a federal agency is required by Section 508 of the Rehabilitation Act to be accessible to persons with disabilities. This law applies to federal agencies and companies that contract with federal agencies (see http://www.section508.gov). Other countries have similar requirements. For example, in Canada, the Treasury Board Common Look and Feel Standards require that Web sites developed by federal agencies be accessible. In Australia, the Disability Discrimination Act requires that all Web sites hosted on Australian servers (regardless of whether or not it is a government Web site) be accessible. (For more details on accessibility laws, see http://www.w3.org/WAI/Policy.) I don't know any Web site developer who would intentionally build a Web site that is not accessible to persons with disabilities. The problem is that most developers are not familiar with the various accessibility standards. In the following sections of this paper, you'll be provided with an overview of the two most important accessibility standards: the WCAG and Section 508 standards You'll also learn how to build accessible Web pages by using ASP.NET controls. Finally, you'll learn how to "validate" your Web pages for accessibility.

Accessibility Standards

Almost all accessibility standards and laws derive from the W3C Web Content Accessibility 1.0 Guidelines (WCAG). These guidelines were first published by the World Wide Web Consortium as a recommendation on May 5, 1999 (see http://www.w3.org/TR/WCAG10). The WCAG consists of 14 guidelines. Each guideline, in turn, consists of one or more checkpoints that further clarify the guideline. Each checkpoint is ranked with a priority between 1 and 3. To make it easier to implement the guidelines, the W3C has published a set of documents that contain techniques for following the guidelines (see http://www.w3.org/TR/WCAG10-TECHS/). You can claim different levels of conformance with the WCAG guidelines. If you claim that your Web site satisfies all priority 1 checkpoints, then you can display a logo that claims Conformance Level A. When a Web site meets all priority 1 and 2 checkpoints, the Web site can display a logo for Conformance Level Double-A. Finally, a Web site that satisfies all checkpoints can display the logo for Conformance Level Triple-A (see http://www.w3.org/WAI/WCAG1-Conformance.html). The Section 508 guidelines derive from the WCAG guidelines. In the United States, federal agencies (and companies who contract with federal agencies) need to be most concerned with this set of guidelines, because these guidelines have the force of law. You can read the complete text of the Section 508 guidelines at the Section 508 Web site. The ASP.NET 2.0 framework was designed to enable you to meet all WCAG priority 1 and priority 2 checkpoints, and all Section 508 guidelines. These guidelines were taken very seriously. Every developer working on the ASP.NET 2.0 framework was required to review and test every ASP.NET control for accessibility. Furthermore, every developer had a screen reader installed on his or her desktop so that pages could be tested against the guidelines.

Accessibility Improvements in ASP.NET 2.0 This paper focuses on six areas of accessibility improvements in the ASP.NET 2.0 framework. In the following sections, you learn how to use ASP.NET controls to display accessible images, forms, navigation, data, and XHTML. At the end of this section, we'll also consider accessibility issues related to using client-side scripts in ASP.NET pages.

Creating Accessible Images You should not assume that everyone who interacts with your Web site can actually see your Web site. If someone is blind or has low vision, that person might need to use either a screen reader or a Braille display to visit your Web pages. A screen reader reads the text in your Web pages by using a speech synthesizer. A Braille display transforms the text in your pages into a Braille representation.

Images and other non-text page elements, such as Java, Shockwave, and Flash content, is useless content for someone who cannot see. If you want to make your Web site accessible to people who have low-vision or who are blind, then you need to provide text equivalents for all non-textual content in your Web pages. Each and every image in a Web page should include an alt attribute. The alt attribute is used to represent alternate text read by a screen reader or other assistive device. Here's how you use the alt attribute. Image of Products

The alt attribute should contain a description of the image. It should never, under any circumstances, simply contain the filename of the image. The purpose of the alt attribute is to convey the same information to someone who is blind as the image conveys to someone who is sighted. Writing the value of an alt attribute requires human interpretation of the meaning of the element. For this reason, the process of creating alt attributes cannot be automated. Every ASP.NET control that displays an image includes a method for supplying alternate text for the image. For example, the ASP.NET Image control includes an AlternateText property. If you use an Image control, then you need to set the AlternateText attribute to a meaningful value.

If an image is used only as a design element, then you should set its alt attribute to an empty string. If an image has no useful information to convey, then there is no reason to clutter up a screen reader's narration of the page.

Special measures had to be taken in the ASP.NET 2.0 framework to enable you to render empty AlternateText. If you assign empty text to an attribute of an ASP.NET control, then the ASP.NET control will not render the attribute at all. For example, imagine that you add the following ASP.NET Image control to a page.

In this case, the following tag is rendered.

Notice that the alt attribute has disappeared. This is the default behavior of all ASP.NET control attributes. When you do not assign an attribute a value, it is not rendered. Unfortunately, in this case, we really want to render an empty value for the alt attribute.

To work around this problem, a new property was introduced into the ASP.NET 2.0 framework to enable you to display empty alternate text with an Image control: the GenerateEmptyAlternateText property.

If you use the GenerateEmptyAlternateText property, then an alt="" attribute is correctly rendered. When an image represents something truly complicated, such as an organizational chart, then you cannot use the alt attribute to provide an alternate text description. When you need to provide a long description of the meaning of an image, then you need to use the longdesc attribute. The longdesc attribute accepts either a relative or absolute URL for its value. The URL should link to a page that contains a textual description of the contents of the image. Here's a sample of how you can use this attribute with the tag. Company Organization Chart

The ASP.NET Image control includes a property, named DescriptionUrl, that corresponds to the HTML longdesc attribute. Here's a sample of how you can use this property.

Creating Accessible Forms Web page forms can create problems for persons with low vision and for persons with reduced motor coordination. If you access a Web page form through a screen reader, then it might be difficult to associate form fields with their corresponding labels. For example, imagine that a Web page contains the following form.
First Name:
Last Name:


This form displays input fields for a person's first name and last name. In this case, because the form is displayed in a table, it might be difficult for a user of a screen reader to associate the proper label with the proper form field. In HTML 4.0, a new tag was introduced to enable you to associate a form field label with a form field: the name="txtLastName" id="txtLastName" />

The