As mentioned in a previous post, many websites claim to meet the W3C Web Content Accessibility Guidelines (WCAG), but these claims are often based on automated tests, and couldn't be further from the truth.
Automated tests are useful but limited and should only be used as part of a wider range of tests incorporating a number of different tools and methods - including user testing.
However, in some circumstances you may not have the time or resources for such in-depth user testing, or have been brought in at last-minute only to find that the site is "almost live". In those cases you are going to have to get stuck in and test it yourself... but where do you start?
In this post, I will go through the methods and tools we use to test the various sites that come under the responsibility of Shropshire Council.
The method...
The best thing you can use to test a website is a human being. You will find that a reasonably short run-through of the main features of a website will immediately give you an idea of the quality and consistency of the underlying design and user experience.
If something seems odd, hard to understand or awkward to use, chances are that the same thing may be even more confusing or harder to use for others, and so is something to investigate further using other tools and methods.
That being said, some issues may not be readily apparent by just browsing through a website, and so I do rely heavily on some Firefox add-ons and web-based tools to assist me, which I will mention as we go along. (Some of these are also available for Google Chrome)
The tools for...
Keyboard navigation
Before breaking out any specific tools, the first thing I try out when testing a website is non-mouse navigation - can I get to what I want using standard keyboard shortcuts?
You can try this yourself, just visit one of your favourite websites, then make a mental note of a link somewhere in the middle of the content. Now try getting to that link just by using the Tab key.
How did that go? Were you lucky enough to find a site that allowed you to easily keep track of where you are on the page?
On an accessible site you should be able to follow your own progress through all the links on the page, usually by looking out for visual effects similar or identical to those that would occur if you hover your mouse cursor over them.
Sadly, chances are you are looking at a website that hasn't put any thought into accessibility and you are still struggling to pick up where you are. In those cases, you may have had to figure out which element had the default dotted outline that most browsers use as a fall-back for focus, or were keeping an eye on the status bar for the changes to the URL preview.
The frustrating thing about all of this is how simple the fix can be.
For standard (X)HTML websites using CSS, the way a link behaves is normally determined by the ":hover" pseudo-class. For example:
a {
color: blue;
}
a:hover {
color: darkblue;
text-decoration: underline;
}
For those not clued up on CSS, this will underline the link and turn the text a darker shade of blue when you hover over it.
To allow the exact same links to react the same way for keyboard navigation, all you need is the :focus pseudo-class, like so:
a:hover,
a:focus {
color: darkblue;
text-decoration: underline;
}
Simple, eh?
Properly structured source code & content
Like most web developers, I use a number of add-ons to test and evaluate websites. I tend to do most of my testing in Firefox, taking advantage of the large amount of add-ons available for it. For accessibility testing I use HTML Validator, the Web Developer toolbar, the WAVE Toolbar (still marked as an "experimental" add-on) and Firebug to evaluate the source code and stylesheets on a page.
HTML Validator
The HTML Validator tool is simple to use, as the icon in the status/add-on bar will change to give a visual status of the page validity as soon as it has finished loading. Double-clicking on the icon will launch a new window containing the page source code and detailed results of any warnings or errors. By selecting one of the warnings/errors in the list it will show you where it occurs within the source code itself by scrolling to and highlighting the offending line. The beauty is that you can configure it to check for a particular level of accessibility (as defined by WAI WCAG1.0), which will identify elements that either fail outright, or will require manual checking.
Web Developer toolbar
The Web Developer toolbar has an array of useful features, but for accessibility testing there are a couple of them that stand out. For graphics-heavy pages, the ability to display the alt attributes on all images is a massive time saver, making it easy to see where images are missing the attribute or when it is not used properly.
Similarly, being able to view a page outline that has been constructed from the header tags within the markup gives a quick preview of how a page might be interpreted by a screen reader. As the outline properly nests the headers hierarchically based on their tags, it shows where headers have been missed out or used in the wrong order, for instance, when someone has used a H3 following a H1 when they should have used a H2.
WAVE Toolbar
The WAVE Toolbar combines most of the elements of the HTML Validator and the Web Developer toolbar that I've previously mentioned, albeit with a visual overlay of validation warnings/errors on the page itself rather than its source. It's a nice user-friendly way of showing people why a page fails, handy if you need to explain your work to someone who isn't well-versed in HTML.
Firebug
Last, but not least, the Firebug add-on. This has become one of my most heavily relied upon tools in recent years, and is normally the first add-on I advise any budding web developer to install. The ability to view and edit HTML and CSS in the browser is amazingly useful for identifying solutions to any accessibility issues that are identified by the other tools, especially when combined with the ability to add your own custom style sheets via the Web Developer toolbar.
Using colours properly
Much like when it comes to picking out what clothes you are going to wear, there are certain colours and styles that go together well in website design. The combination of these factors can help or hinder visually impaired users when it comes to reading your content, but can also influence how everyone uses your site.
I usually start by getting an overview of the homepage and a standard content page using an automated contrast checker (such as the the Juicy Studio Accessibility Toolbar or WCAG Contrast Checker add-ons for Firefox, or www.checkmycolours.com).
As I've said before, automated tools are good, but they aren't 100% accurate. With contrast checkers the results are based on an evaluation of your CSS and (X)HTML code, but these can often misinterpret how some rules should be applied, and more importantly, don't take into account pseudo-classes or scripting influences. This means that you may be getting a mixture of false positive and negative results on the test, and are ignoring some potential UI issues.
Because of these limitations, it is still necessary to manually check certain aspects of the design, for instance, the :hover/:focus effects on links and form elements.
In these situations you will have to identify the colour values used for these events, and use the manual colour comparison tools available in the WCAG Contrast Checker. I use Firebug to identify a link/button and use the options in the Style menu to get to the :hover & :focus rules, and the Computed tab to see the actual values of an element, as sometimes contrast is only an issue if the font-size is below a certain pixel value (normally about 18px).
If you are looking to tweak a colour a bit in order to make it compliant, take a look at http://snook.ca/technical/colour_contrast/colour.html. Just enter your foreground and background colours and use the sliders to find the best match for your level of accessibility.
Summary
Because of the complexity of modern web designs and the underlying technologies that they are based on, there is no "magic bullet" for accessibility testing. It is only by combining a number of different tools and resources, coupled with good old human ingenuity and common sense that a website can be properly evaluated.
If you want to properly plan for and test for accessibility, remember to ask the people who rely most on accessible websites, and be sure to listen to any suggestions they may have.
The development of shropshire.gov.uk website was aided by the involvement of a local centre that provides training and advice for disabled people, whose input greatly influenced the finished product as well as all the versions we have released since.