Assess Your Access

If you feel brave enough, go ask your architect or technical lead if they ve designed and coded the new application or Web site with accessibility in mind. Then brace yourself! It s pointless to get upset about the answer. Instead, it s more productive to define a plan to fix the problem. First, you ll need to understand that architects and developers typically aren t concerned with accessibility. Second, you must understand that they may not know how to build accessibility into an application.

Wikipedia defines accessibility as follows: Accessibility is a general term used to describe the degree to which a product (e.g., device, service, environment) is accessible by as many people as possible. ... Accessibility is often used to focus on people with disabilities and their right of access to entities, often through \[the\] use of assistive technology (http://en.wikipedia.org/wiki/Accessibility).

One example of an assistive technology is the screen reader software named JAWS, available from Freedom Scientific (http://www.freedomscientific.com/products/fs/jaws-product-page.asp), which vocalizes text on a Web page so visually impaired individuals can navigate a Web site.

In an ideal world, the application you design and write needs to cater to the needs of individuals with disabilities. Aside from the fact that disabled individuals form part of your customer base, it is also a federal requirement. See the Americans with Disabilities Act, 42 U.S.C. section 12182 (http://www.ada.gov/pubs/ada.htm). Most developed countries also have similar regulations.

Failure to comply with these requirements means your product now becomes a target for lawsuits. In the past, these lawsuits were primarily aimed at government entities. However, this lawsuit landscape is changing. National Federation of the Blind (NFB) et al. v Target Corporation was filed in Superior Court of California for the county of Alameda in 2006 (http://pub.bna.com/eclr/06cv1802_100207.pdf). In a nutshell, NFB et al. alleges that the Target Web site (http://www.target.com) violates the Americans with Disabilities Act (ADA), Unruh Civil Rights Act, Cal. Civ. Code section 51 (Unruh Act), and the Disabled Persons Act, Cal. Civ. Code section 54.1 (DPA).

Common sense should dictate that even a successful defense of a class action lawsuit will cost an arm and several legs. Why go through the expense when you can proactively address these concerns in a way that is not cost prohibitive?

First, you must understand that your application design needs to focus on the common accessibility barriers in an application:

The good news is that Visual Studio .NET 2005 and later supports accessibility and incorporates integrated accessibility testing tools. The bad news is that the support is considerably less than 100%. Be mindful of those shortfalls when building an application or Web site that is in compliance with the ADA.

Microsoft has made an effort to promote accessibility development in .NET. Accessibility Support in ASP.NET outlines the approaches that should be used (http://msdn2.microsoft.com/en-us/library/ms228004.aspx). The key guidelines are:

In addition to these guidelines, be aware that certain types of Web applications, such as hosted User Control applications and Smart Client applications, need to monitor for accessibility-related changes. For these applications, accessibility-related changes occur when the user enables Windows high-contrast mode (see Figure 1). The code listing in Figure 2 shows some bare-bones code.

 
Figure 1: Enable high-contract mode.

public Form1()

\{

    InitializeComponent();

   //ACCESSIBILITY: Hook the user preference change event

Microsoft.Win32.SystemEvents.UserPreferenceChanged+= new Microsoft.Win32.UserPreferenceChangedEventHandler(

this.UserPreferenceChanged);

\}

//ACCESSIBILITY

private void UserPreferenceChanged(object sender,

   Microsoft.Win32.UserPreferenceChangedEventArgs e)

\{

 if (SystemInformation.HighContrast)

 \{

    //Adjust controls for accessibility

    if (SystemInformation.HighContrast)

       if (!button1.BackColor.IsSystemColor)

           button1.BackColor =

           System.Drawing.SystemColors.Control;

 \}

 else

 \{

    //reset controls

    Button1.BackColor = Color.Blue;

 \}

\}

Figure 2: Bare-bones, high-contrast mode support.

In the code listed in Figure 2, examine the SystemInformation.HighContrast property to determine if high-contrast mode is activated. Then take appropriate action, such as iterating the form control tree to apply accessibility changes to each control on the form. Some of the changes should include:

As you can see from Figure 3, in high-contrast mode, the colors for each control on a form will change automatically to a color that allows a high degree of contrast (such as black and white). However, these changes only occur if the colors on the form are Windows system colors. High-contrast mode has no affect on controls that use Web or Custom colors.  

Figure 3: A form in high-contrast mode.

As you can see, the majority of changes that need to be made require very little effort. The challenge is in knowing the accessibility requirements. Take time to familiarize yourself with these popular published guidelines on developing applications for accessibility:

The accessibility best practices are described at msdn2.microsoft.com/en-us/library/aa350483.aspx.

Once you ve built an application with accessibility in mind, you can test your Web application for accessibility by using:

Accessibility testing doesn t necessarily need to rely on sophisticated tools. One simple test you can perform is to unplug your mouse, then try to use your application. If you can t use the application successfully using the keyboard alone, end-users with mobility impairments will have difficulty using your application.

Because Visual Studio .NET falls short of the accessibility mark, you ll need to familiarize yourself with the complete list of .NET controls that do not completely support accessibility guidelines. Avoid these controls if possible. If you can t avoid these controls, then learn how to configure them to improve accessibility. The list of controls that lack support for accessibility is described at http://msdn2.microsoft.com/en-us/library/ms227996.aspx.

The stakes are high in NFB, et al. v Target Corporation. It could define the scope of ADA to include or exclude Web sites, even if they are not tied to a brick-and-mortar location. Dan Goldstein of Brown, Goldstein & Levy noted that The blind of America seek only the same rights and opportunities \[that\] others take for granted. \[NFB v Target Corporation\] should be a wake-up call to all businesses that their services must be accessible to all. See http://www.dralegal.org for the complete article. At the time of this writing, NFB, et al. v Target Corporation is still pending; the court has not adjudicated the merits of the plaintiff s claim.