David Sills's muse is fueled by Bach, Beethoven, and Brahms (and Berlioz and Boulez). He has no life, which comports well with the über-geekitude to which he aspires. He reads and writes fitfully in English, Spanish, French, German, Italian (mostly medieval), C, VB, Perl.... Oh, and Java and XSLT, lots and lots of Java and XSLT. Trained somewhere in darkest Central America, he works today at DataSource, Inc., on the product team for the CASE tool Abri. David has posted 9 posts at DZone. View Full User Profile

Selenium and Section 508

01.01.2009
| 19713 views |
  • submit to reddit

Selenium is a popular test tool for web applications. It was developed from 2004 onwards, originally to acceptance-test a time-and-expense-reporting application for ThoughtWorks. Members of ThoughtWorks are still involved in its development, as are others, on the OpenQA web site.

Selenium is written in JavaScript and runs within a browser. There are several versions of the tool: the easiest to deploy and try out is the Selenium IDE. This is available as a Firefox extension here. Once installed, the extension is very easy to use. It allows users to record tests by simply clicking and typing through them and to edit and replay them as needed. You can also build up tests manually, if you wish.

Possibly easiest to use is the editor interface:


Selenium IDESelenium IDE

There are three lines that may be filled in for each command in each test, shown in the editor interface as Command, Target, and Value. Not all commands require all three; all commands, of course, require the Command line to be filled in. Each command has its own set of parameters. These are stored as HTML files by the IDE, with a command structure that looks like this:

  <tr>
    <td>Command</td>
    <td>Target</td>
    <td>Value</td>
  </tr>

I actually prefer the HTML form of the tests and often build tests in HTML directly (which can be done in the Source tab of the interface or in your favorite text editor). Your mileage, of course, may vary, but I shall be using the HTML form of the tests in this article.

Selenium logs the state of its testing (JavaScript can't, of course, write to files) in the Log Console. This is just a table of results built up at runtime. Some Selenium tests give less-than-ideal feedback about exactly what it was that went wrong, but even limited error messages can often be useful.

The downside of using the Selenium IDE is that it only runs in Firefox. I rarely find this a limitation, and it is not one for the current article. Most of the tests herein use XPath to identify things that should or should not exist in the web application; if the Firefox tests succeed, the web application is fine, in whatever browser it is actually viewed. Should Selenium solutions be required in other browsers, it is not difficult to use the IDE to convert the tests to other languages, for example Java (where they are converted to JUnit tests); in those languages, typically, other browsers are supported, but the IDE cannot be used.
One extremely useful aspect of Selenium it that it allows you to extend the functions it provides by adding your own. I do this quite frequently; there are a number of user-contributed extensions here. We shall see two examples of this later on.
Selenium has become an absolutely necessary part of my development and testing regime. It makes test-driven development possible in a web environment without a lot of fuss and bother.

Section 508

Section 508 is a part of the Rehabilitation Act of 1973, as amended in 1998 (29 U.S.C. § 794d). People with disabilities often found the web forbidding and inaccessible, since it often didn't even minimally take into account the needs of people whose approach to the web is not visual or mouse based. The idea of Section 508 was to make such information (not only web applications, but that is our focus here) accessible by removing barriers that held users back and to encourage the development of technologies that would make accessibility easier over time. The law applies to Federal agencies, but as a standard is a good thing to keep in mind whenever developing for the web: nothing in Section 508 requires making anything more difficult to use for any user and making information available to more users simply increases our user base.

Purpose of this article

In many cases, the adaptations required to meet Section 508 standards are not onerous. Rather, they are things we tend to forget when we don't ourselves use them routinely.

The purpose of the present article is to show that Selenium testing can be used effectively as an aide-mémoire, ensuring that we don't forget to put in features that will make our web sites more accessible and that we don't put in features that will make them less accessible.

I personally create a test script for my applications that use JSPs that simply navigates to (and therefore compiles) all JSPs automatically, testing for Section 508 compliance along the way. Automated as part of my build process, I find this a useful way to avoid the "hang" time that JSPs can sometimes (and irritatingly) cause, and at the same time to ensure that I haven't missed a chance for Section 508 compliance that costs me little if anything and enables access.

Script tags

While external style sheets (using the link tag) can be overridden by users with specific issues, enabling those users to modify the appearance of an HTML page to satisfy their specific needs, inline CSS styles defined within HTML cannot be so overridden. The test itself to catch cases of this is a simple check of the number of style elements in the HTML page, using XPath (the verify option, in Selenium, does not stop the test case, even if it must report a failure of the test):

  <tr>
<td>verifyXpathCount</td>
<td>//style</td>
<td>0</td>
</tr>

 

Alt attributes (round 1)

Each content-carrying image should have an alt textual description for non-visual users. Were it this simple, the test would be relatively straightforward:

  <tr>
<td>verifyXpathCount</td>
<td>//img[not(normalize-space(@alt))]</td>
<td>0</td>
</tr>

As we shall see later, this rule comes with an exception, which may or may not apply to your site.

The same logic applies to various animation types (Java applets, Flash files, video files, audio files, and other plug-ins):

  <tr>
<td>verifyXpathCount</td>
<td>//applet[not(normalize-space(@alt))]</td>
<td>0</td>
</tr>
<tr>
<td>verifyXpathCount</td>
<td>//object[not(normalize-space())]</td>
<td>0</td>
</tr>

Again, your specific cases may differ slightly, but this should point the way towards a solution.

Published at DZone with permission of its author, David Sills.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mostly Harmless replied on Thu, 2009/01/01 - 6:07pm

It is still ridiculous to me that Selenium uses an HTML file with tables rather than a proper XML file. In 2003 or 4 a friend and I sent them a patch to support XML. They passed on it. Too bad.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.