Automated testing (in general) is not “very limited”. In fact regression testing a modern software development project demands automated testing.

When you write “it will find some issues, but it will seriously not find many others” are you referring to Raakt or automated tools in general? If you are referring to the latter I think you may be misinformed on how many of these tools work. There are many tools available that automates testing of functionality (e.g. user scenarios). Developers define the testing scenario which can then be run automatically whenever there is a code change. Check Selenium for an example.

As for automated accessibility testing I believe you are proposing a false dichotomy. Just because an automated test does not find all accessibility issues it does not make it useless. Finding some issues are better than none, right?

Please note that I do not prepose replacing manual testing. I just want to reduce the number of issues reaching QA and thereby lower the project development costs.

From experience, typical scenario is design, develop, testing (functional, usability, accessibility), content.

The projects I usually work on hand over sites with dummy text, it is usually down to the customer to maintain the content.

Whilst I understand your attempt at creating a tool to identify problems straight away, automated testing is really very limited. Yes it will find some issues, but it will seriously not find many others. The problem with checklist style automation is that only the checklists are tested for, what about everything else? You may find that the focus ends up becoming on passing the automated tests rather than focusing on accessibility issues.

What about compatibility, functionality, user scenarios, performance?

Just like software testing, usability and accessibility should be seen as part of the development process, considered as early on as feasable. Why not treat accessibility as software testing? I’m a software tester and test for accessibility when doing my tests.

You may find this post on the topic of software automation from James Bach of interest: http://www.satisfice.com/blog/archives/58

Test Automation
Rule #1: A good manual test cannot be automated.
Rule #1B: If you can truly automate a manual test, it couldn’t have been a good manual test.
Rule #1C: If you have a great automated test, it’s not the same as the manual test that you believe you were automating.

Once you get your automated tests focussing on the easy stuff, it leaves you free to spot the other issues earlier. It also helps with developer education - since they’re exposed to many of the issues throughout the development process.

I’m thoroughly sick of folk who want to keep accessibility / usability / whatever apart from the development process. It just helps make bad products.