I received a question the other day from one of the guys I mentor asking about how to go about testing the accessibility of a website.
It’s fairly common for many testers to have never had to consider accessibility testing before. It’s something I’ve been doing for some time now but I can’t quite remember how I first got interested in it, by luck I think. I think it’s fairly essential for most web testers now even if the site under test is not aiming to achieve any type of compliance. Especially as the tools available can also help in other areas of testing too.
I also believe that you can only really test for accessibility by understanding why you are doing it. Some people run a few checks, reckon it’s all good and don’t really understand why they are testing for accessibility. Useful article here with some good insights : http://www.cnn.com/2009/TECH/12/15/cnet.web.accessibility/index.html I think nothing can replace meeting people with accessibility requirements and getting first hand stories of why accessible sites are so important. There are lots of Internet based activities many of us take for granted. It’s a really powerful experience learning and understanding from people who have problems accessing sites and other online material that I take for granted.
I’m not just talking about none sighted disabilities, accessibility encompasses a lot more than that, including cognitive, speech, hearing and the incredibly common colour blindness. All of these ultimately marginalise people, exclude people from the web or make their experience online all that bit more complicated and difficult.
But why should this be the case when we have professional testers (and other disciplines) on the team? The main reason really is because most website/app teams don’t spend time considering, designing, coding and testing against internationally recognised accessibility standards (WCAG: Web Content Accessibility Guidelines); maybe because they don’t know they should be or maybe because they don’t really know where to go for information.
The irony is that creating a site that is accessible opens your reach up to a much wider audience and doesn’t really cost much more to produce. (there could be a steep learning curve and extra costs for specialist testing though). It often results in a much better design and user experience too. But ultimately the main reason for improving the accessibility of your sites and apps is to empower more people to interact with the web. Right?
I believe it’s time we, as testers, take a little bit of ownership with accessibility. If no-one else on the project team will then why not be the champion of accessibility? After all it takes less than about 5 seconds (after installing tools) to say whether a site fails compliance and believe me, many will. A little bit longer if the online checkers give a yes it’s all clear.
A quick check and you can raise your concerns with the team. How passionate you feel about pushing for more accessibility after that is down to you, your environment and your products purpose, audience and context.
Before I rush in to explaining some basic tools it’s important to point out that the WCAG standards have shifted over the last year from WCAG 1.0 to WCAG 2.0. Many of the tools for testing accessibility are still using 1.0 so there could be some extra leg work. This is not necessarily a problem as they are still valid (in most cases) but if you have requirements double check what compliance level and version they are against. As with all things these things evolve over time.
Compliance to the standards isn’t as simple as leaving it to an online checker or automated tool. It takes seconds to point out a failure but much longer to prove compliance. Checking is fine…testing is another thing.
Here’s an example.
If a site has a field for the text entry of the users “name” then it needs to have a label for the field, primarily so screen readers can inform the user what they need to enter. So if the field has no label an online checker or tool will instantly fail this. No label = no pass.
But if the field does have a label then the checker will say “yes, that is OK” even if the “name” field has a label of “Do you like blue cheese?”
This is a very basic example, some are not quite as clear cut as this and many are nowhere near as simple. There are lots of subtleties and loads of documents to read to get your head around it but the main message is; don’t just rely on an automated/tool based check, human inspection is required.
It is also not enough to assume that a quick scoot around the site with a screen reader is enough to prove it’s OK. There’s simply no replacement for real end users testing the site/app. For example, I once tested a site for screen readers and a number of other devices and gave it an all clear. But we also sent the site off to an external charity for real end user testing who gave it the once over and reported loads of things back. Things I would NEVER have found. “Accessible sites still need to be usable” was one of the quotes fed back. They could get end to end, but not as smoothly as they should be able to.
As a starting point my advice would be to download and install FireFox web browser and then install the accessibility toolbar (https://addons.mozilla.org/en-US/firefox/addon/5809).
Then open a site and on the accessibility toolbar click Reports > Accessibility Report and see what it says. The toolbar is awesome and has loads of options but some good highlights for me are the Scripting > Disable Scripting which disables all scripts on the page. There’s also a really quick way of turning off CSS (Style > Author CSS > Off) without having to search for the option in the browser settings and the ability to show text equivalents of objects and images (Text Equivalents > List of Images/List of Objects)
The FireFox add-on is not the only one out there, but it’s one of the most complete and a really easy way to quickly assess the state of your site’s accessibility.
Here’s some useful links and also a link to my ‘delicious’ accessibility feed which will grow over time.
Actual Guidelines- http://www.w3.org/TR/WCAG20/
Overview of WCAG – http://www.w3.org/WAI/intro/wcag.php
Understanding WCAG 2.0 – http://www.w3.org/TR/UNDERSTANDING-WCAG20/
Techniques for WCAG 2.0 – http://www.w3.org/TR/WCAG20-TECHS/
FireFox 2.0 add-ons
TAW3 en un clic – https://addons.mozilla.org/en-US/firefox/addon/1158
This is a really good add on which gives you a link in the Tools menu: Tools > TAW It
When clicked it grabs the page you are on and gives you a new page with each validation error, query or warning highlighted with relevant failure information included. It also gives you a good list of areas that require human checking. Their website also offers a validation process as well as a WCAG 2.0 Beta checking site. (http://www.tawdis.net/ingles.html?lang=en)
FireFox Accessibility Extension – https://addons.mozilla.org/en-US/firefox/addon/5809
The FireFox add on.
W3C validator – http://validator.w3.org/
T.A.W checker (as mentioned in FireFox add on section) – http://www.tawdis.net/ingles.html?lang=en
There are loads more links and useful tools over on my delicious feed under the accessibility tag, link below. The beauty of using the following delicious feed is that the list will grow as I add more social bookmarks rather than a static web page that I have to keep updating.
I hope this gives you a really basic introduction to accessibility testing. I’ve not even scratched the surface here, but it should be enough to get going.