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.
Possibly easiest to use is the editor interface:
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:
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.
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.
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.
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):
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:
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):
Again, your specific cases may differ slightly, but this should point the way towards a solution.