Everyone is correct when saying to integrate automated solutions with manual reviews, because no solution in the world can scan against the full WCAG 2.0 checklist.

However when managing thousands (if not hundreds of thousands) of pages, it is very sensible to deploy an enterpirse tool that can scan whole sites, sub sections, content etc at one time.

Most solutions freely available are quite limited in what they can show and do not allow any form of customisation, therefore can present a number of barriers to people wanting to understand what the reports show.

Drop me an email and I can set up some demos for you to look at an enterprise solution and how this may help you see the real value in using an automated tool as well as maunal reviews etc. (User feedback is critical as well)

kareem@hisoftware.com

I am very in Web accessibility and I am conducting a research on web accessibility of UK public sector website. I have been reading
Central Office of Information(COI)(2008) Delivering inclusive websites [Internet]. Available from:

COI recommends that website developers and testers should be aware of the limitations and capabilities of the automated tools.

However, there is only information on performance of Boby and all the previous academic research was performed using Boby automated tools. I am just wondering how the website developers and testers suppose to know about limitations and capabilities of the automated tools except Boby.

It would be great to be able to rely totally on automated tools for website evaluation, but it’s not possible with the current state of the tools. At some point, people need to do testing. On some level, tools may never be able to fully do the job. Our world is full of exceptions, uncommon circumstance, and change. I use automated tools as mechanism to find trouble areas, then examining the situation for myself. In the end, it comes down to a judgment call.

I’ve tested the various evaluation tools with our own tool. The outcome of this automated test doesn’t say much about accessibility, but at least shows some room for improvement when it comes to build quality…
Unfortunately, only three of the examined tools offered the possibility to link to the actual test result.

The quick test confirms Peter’s conclusion: what lacks is a unified web evaluation methodology that provides consistent results across tools.

Such a methodology exists for version 1.0 of the Web Content Accessibility Guidelines; for our own tool we used UWEM version 1.1.

Hopefully, funding will become available for UWEM version 2, based on the far more recent WCAG 2.0. It would not only be very convenient to use this specification during the development of the new version of our test tool, but will also lead to more consistency of test results. But I’m not very confident that UWEM version 2 will be developed any time soon…

It most certainly isn’t, but when working with code we should certainly be closing any gaps before our content ends up in the public domain. By closing gaps I mean locking your code up so it is valid and then having real users validate your sites flow through real world testing. This is often a lot cheaper than people suspect and reaps results infinitely more relevant.