Accessibility Support in ASP.NET
ASP.NET can help you create Web applications that can be accessed by people with disabilities. Accessible Web applications enable people to use assistive technologies, such as screen readers, to work with Web pages. Accessible Web applications have the following advantages:
They are usable by the widest possible audience.
They involve design principles that frequently benefit all users, not just those with disabilities.
They meet the requirements of many institutions that require all Web applications to be accessible.
By understanding accessibility guidelines and how ASP.NET can help you meet those guidelines, you can create applications that are easier for people that have disabilities to interact with.
Accessibility Guidelines
Various organizations publish guidelines for how to create accessible applications. The following are well-known guidelines:
Web Content Accessibility Guidelines 1.0 (WCAG).
These standards are developed by the World Wide Web Consortium (W3C) and are the basis for many other accessibility standards. This includes accessibility standards that are used by governments around the world.
For the Web content accessibility guidelines, go to the World Wide Web Consortium (W3C) Web site.
The WCAG guidelines define different levels of priorities, using a scale from 1 through 3 for the checkpoints that are associated with each guideline. Some institutions require that all Web sites comply with all priority 1 and priority 2 checkpoints.
Section 508.
The United States government defines accessibility standards in section 508 of the Rehabilitation Act, which are similar to the WCAG.
For the section 508 guidelines, go to .
Microsoft accessibility guidelines.
For the Microsoft accessibility guidelines, go to Microsoft Accessibility and go to the MSDN Library and search for "Accessibility Design Guidelines for the Web."
Testing Accessibility
To a limited extent, you can test how well the Web pages comply with accessibility standards using a variety of tools that are available from third-parties.
If you have a development environment, such as Microsoft Visual Studio 2005, the environment might offer accessibility testing tools. For more information, look in the product documentation. However, design-time accessibility validation tools do not test output that is generated dynamically, such as the markup that is rendered by ASP.NET server controls or by your own code. You should test the output of your pages, in addition to using design-time accessibility validation tools.
An automated accessibility test cannot perform a complete diagnosis of the accessibility of a page or Web site. Many of the guidelines for accessibility require your judgment to determine whether features on a page comply with the guideline. For example, an automated test can determine whether you have provided alt text for all images on your page. However, the automated test cannot determine whether the alt text describes the image. Similarly, an automated test cannot objectively determine whether the colors that you are using on your page exhibit sufficient contrast for readers who require high-contrast text. Therefore, to create truly accessible applications, you must be familiar with the specifics and intent of the guidelines so that you can create your pages and meet accessibility guidelines. For another example of an accessibility check that might not be performed by a tool, alt text must exist for a graphic-only image, such as a rounded table border. Otherwise, a screen reader will read the image file. If the alt text is empty, the screen reader will correctly skip the image.
Accessibility Features in ASP.NET
Most of the time, ASP.NET controls either render markup that results in pages that meet accessibility standards or expose properties that you can set to make the pages accessible. However, sometimes ASP.NET controls render output that does not comply with all accessibility standards. For detailed information, see ASP.NET Controls and Accessibility.
General Control Features that Support Accessibility
Generally, ASP.NET controls meet accessibility requirements in the following ways:
Provide a way to specify a text equivalent for any non-text element.
Do not have color dependencies.
Render captions and table column headers with tables.
Render fieldset and legend elements that have div elements.
Do not require style sheets.
Support positioning using style properties.
Associate labels with controls.
Generate client script that is device-independent; for example, script that does not respond only to mouse clicks.
Keyboard Access
An important accessibility feature is that functionality on the page should be available to alternate forms of input. In practical terms, this means that any task that can be completed with the mouse can also be completed from the keyboard.
ASP.NET lets you include keyboard support for your pages in the following ways:
You can set tab order for controls using the TabIndex property.
You can specify a default button for a form or Panel control by setting the DefaultButton property.
You can set the focus on input controls either by using methods such as the SetFocus method or by setting the DefaultFocus property for a form.
You can define access keys for button controls by setting the AccessKey property.
You can use Label controls with text boxes, which let you define access keys for the text boxes. For detailed information, see How to: Use Label Web Server Controls as Captions.
Images and Alternate Text
Accessibility guidelines recommend providing meaningful alternate text for images on the page that have a functional purpose, such as acting as buttons or images that are rendered by data controls. This enables screen readers to report what each image on the page is for. If an image has no functional purpose beyond decoration, the alternate text should be set to an empty string so that screen readers skip the image.
By default, because the Image, ImageButton, and ImageMap controls cannot automatically generate meaningful text, these controls do not render any alternate text. Instead, you should provide the text yourself. Accessibility checkers flag image controls without alternate text as violating guidelines.
For image controls, you should do one of the following for the control:
Set the AlternateText property to meaningful text.
Set the GenerateEmptyAlternateText property to true to cause an ASP.NET Image control to render an empty string as the alternate text. Empty alternate text is interpreted by accessibility checkers to mean that you have deliberately marked the image as not important.
Controls with Inherent Images or Links
Some controls, such as the TreeView control, the Menu control, and Web Parts, render images or links as part of their markup. In these cases, the control creates alternate text for each image or link that describes its function.
For example, the TreeView control renders images for the expand and collapse buttons for each node. The TreeView control generates alternate text for these images based on the text of the node. By default, the alternate text for the image to expand a node with the text Start is rendered as Expand Start. You can specify your own alternate text by setting the ExpandImageToolTip and CollapseImageToolTip properties for the TreeView control.
Similarly, the Menu command renders alternate text for the links that it generates to expand and collapse menu items. The buttons in a Web Parts control title bar similarly render alternate text that describes the function for each button.
Skipping Repetitive Links
Assistive technology devices, such as screen readers, must enumerate every link that is on a page in the order that the pages appear in. Sometimes, such as a menu in a master page that appears at the top of every page in the Web site, the screen reader will be forced to read all entries on each page before getting to the main content of the page. For cases such as these, accessibility guidelines recommend providing a way for users to skip over lists of repetitive links. The following controls implement a way to skip repetitive links:
Each of these controls supports a SkipLinkText property. If this property is to set to a string (which can include any text), the control renders an anchor before the links that includes an invisible .gif image with alternate text. By default, the alternate text is Skip Navigation Links, but you can configure the text. The anchor links to another anchor that follows the control. This enables screen readers and similar technology to give users an opportunity to skip over the links that are generated by the control, without visually interfering with the visual display of the page. If the SkipLinkText property is set to an empty string, the control does not render the anchor tags.
Controls That Render Tables
Accessibility guidelines recommend that HTML tables include the following:
A caption to help assistive technologies identify the purpose of the table.
A way to identify column headers.
If you use the Table control to create a table, you can explicitly set its Caption property. You can create table headers using the TableHeaderRow class, setting the TableSection property to the TableHeader enumeration of the TableRowSection class. This causes the table to render a thead element. When you create cells with the TableCell control, you can set each AssociatedHeaderCellID property for the cell to the ID of a table header cell. This causes the cell to render a header attribute that associates the cell with the corresponding column heading.
The following ASP.NET server controls can render HTML tables:
These controls let you set Caption and CaptionAlign properties to create the recommended captions for the resulting table.
For these controls, if you set the UseAccessibleHeader property, the control renders th elements that have scope attributes to identify the column headers.
Two additional controls, the DataList and Repeater controls, do not automatically render thead or th elements. However, you can define header templates for these controls. For the DataList control, header templates render th elements. The Repeater control does not render any markup automatically; you define the header, body, and footer templates for the control, in which you can specify any markup. If you specify that the Repeater control should render an HTML table, you should include the appropriate markup to meet accessibility standards.
Controls that Render div Elements
Accessibility guidelines recommend dividing long forms into sections to make them easier to navigate. HTML 4.0 introduced the fieldset and legend elements to enable Web page developers to divide a form into sections.
In ASP.NET, you can use the Panel control to create subdivisions in a form. If you set the GroupingText property for the control to a string, the Panel control renders a div element that contains a fieldset element for the contents and a legend element that has the string that you used in the GroupingText property.
Some Web Parts controls render div elements also. These controls automatically render fieldset and legend elements.
Validation Controls
Many Web pages display an asterisk (*) next to a text box when an entry is required or if the user has made an error in data entry. Because an asterisk is not meaningful, you should always specify meaningful error messages in the Text and ErrorMessage properties of validator controls.
Additionally, validator controls should disable client script (EnableClientScript=false).
Login Controls
Login controls, such as the Login, ChangePassword, PasswordRecovery, and CreateUserWizard controls, include other controls, such as the Label, TextBox, and validator controls. Because you, as the Web page developer, do not necessarily have direct control over what the login controls render, the controls are designed with accessibility in mind. For example, the controls exhibit the following behavior to support accessibility:
Text boxes have associated labels.
Input controls have tab index settings.
However, if you create templates for these login controls, you must configure the controls in the templates so that the controls comply with accessibility guidelines.
Client Script and ASP.NET Server Controls
WCAG standards recommend that pages do not use client script for any functional purpose, only for non-essential effects, such as mouse rollovers. Section 508 guidelines allow for the use of client script, if assistive technologies can work with any values that are returned by the script.
Several ASP.NET Web server controls depend on client script. For example:
The LinkButton and ImageButton controls require client script to perform postbacks.
The Calendar control requires client script to support clicking day links.
The Web Parts controls rely on client script for close, minimize, and edit links.
For a complete list of controls that use client script, see ASP.NET Web Server Controls that Use Client Script.
Therefore, if you use any of the controls on a page that require client script, your page will not conform to WCAG standards. If your Web application must be 100 percent compliant with WCAG standards, you cannot use any controls on the page that rely on client script. However, these controls do comply with section 508 standards for the use of client script in a page.