9.11. Applying Accessibility Testing to the ASP.NET Family
This chapter has spent a great deal of time talking about the techniques and tools to make web applications accessible, now it's time to put this new found knowledge into practice.
9.11.1. WebForms and ASP.NET MVC Applications
The methodology used for testing both WebForms and ASP.NET MVC applications is the same. We are going to use the WROX Pizza store demo web application example to illustrate the steps for finding accessibility issues.
9.11.1.1. Initial Look
The very first thing you should do is take a peek under the hood of the web application and see how the HTML is being rendered. No fancy tools are needed for this step, it's just a matter of using the built-in functionality of the web browser to view the source. Figure 9-41 is simply using the View Source option within Firefox.
During the initial look at the source you start to see how much work will be required to make the site accessible. The very first line of the source is a line to pay close attention to. In Figure 9-44 the first line indicates that this document should adhere to the XHML 1.0 Strict guideline. While looking though the remainder of the source, you should make sure that the document follows this HTML compliance standard; if it doesn't then automated tools will fail because the document is not XHTML 1.0 Strict compliant, as the first line indicated. Visual Studio will produce warnings to try to help developers adhere to the document type set in their pages. A common error with the document type tag that can be caught while reviewing the code is when the html tag is not lower case.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/ xhtml1/DTD/xhtml1-strict.dtd">
Figure 9-41. Source View of the Wrox Pizza Demo Web Application
The other major element you look for while in source view is if tables have been used for layout. In the example above, the initial look though the code looks ok. No tables have been used for formatting elements, it appears that heavy CSS was used which is a good thing. After looking though at the source of this web application, I feel that the web application is to a point where using a tool would yield good results, meaning I don't think there are going to be hundreds of accessibility errors based upon my initial assessment.
9.11.1.2. Tools
The first tool you could use is contained in the WAVE toolbar called "Text Only." This renders the site w/out CSS and images, which is the equivalent of running it though the Lynx text browser. In this step of accessibility testing you're looking to see that the document has a very clean structure, meaning it's easy to read in "Text only" mode. Figure 9-42 shows the Wrox Pizza demo application in "Text only" mode, and the first accessibility element I notice missing is skip navigation. As you will recall, skip navigation is a concept that allows users who cannot use a pointer device such as a mouse to skip past complex or frequently appearing navigation elements. You should make sure that this accessibility element is added before running more tools on the application. Besides the test data that is entered to the site, the Wrox Pizza Store application renders very readable in Text-only mode, and this is what you would expect to see in a site that is considered accessible.
Figure 9-42. Wrox Pizza store in Text only mode
After checking how the web application is rendered in a text only view, You can then use a tool to begin checking the application for accessibility. Figure 9-43 shows the Wrox Pizza store application rendered using the WAVE Error, Features and Alerts tool contained in the WAVE toolbar. Figure 9-44 shows that the WAVE tool found many accessibility issues with the Wrox Pizza store product menu page. The red trapezoid images that have been rendered next to each one of the product images, indicates that alterative text has not been added to each of these images. In this type of application (application that uses pictures to describe something, it is extremely important to have a very descriptive alternative text for each product image to describe exactly what the product looks like. The rest of the page looks OK, so you can move on to the next step.
In the next step for testing the Wrox Pizza store web application for accessibility, you should check to see if the site conforms to a specific standard. This site was not developed for the United States government and does not need to adhere to section 508, so we will adhere to WCAG 1.0 and test for priority 1, 2, and 3. To complete this task we will be using the Cynthia Says compliance tool. Simply navigate to http://www.contentquality.com and point the tool to the web page you would like to test. The only issue with this tool is that the page needs to be accessible from the Internet, so this could cause issues on many projects and there are other tools that perform the exact same task that do not carry this same requirement. The report that Cynthia Says generates is very useful and formatted in a style that is easy to read, which is why we like to use it. Figure 9-44 is an excerpt of the report that Cynthia Says generated for the Wrox Pizza Store Product Menu page. Figure 9-44 only shows a list of the elements that failed. The only elements blocking this page of the Wrox Pizza site from WCAG 1.0 compliance is setting the alternative text for the images, an issue which we discovered earlier in the testing process. Along with the alternative text issue, the page is missing a few metadata tags for the natural language, title, and description of the page.
Figure 9-43. Wrox Pizza store using WAVE toolbar
Performing the tasks in this section will become second nature and with a little practice, these steps can be run very quickly to ensure accessibility compliance throughout the application development lifecycle.
Figure 9-44. Wrox Pizza store Cynthia Says excerpts
