Karl Groves recently published automated web accessibility test data for many of the Alexa Top 100 web sites. The results paint a rather stark picture of web accessibility. We agree with Karl’s suggestion that while automated testing is not a direct indicator of true accessibility issues, “poor performance in automated testing is strongly correlated with poor performance in manual testing.” Jennison commented that not all errors are created equally, and this is very true, yet the preponderance of automated errors is clearly indicative of serious issues.
The table below outlines errors for the home pages of the Alexa Top 100 US sites (excluding porn, content farm, and advertising sites). The WAVE toolbar was used to calculate errors. Because the WAVE toolbar evaluates content after JavaScript is processed, and because WAVE errors almost universally indicate a significant accessibility issue, the number of errors is generally a good indicator of true end user accessibility issues.
Site Data
Conclusion
Care should be taken in interpreting these results. These data should not be used to cast a sweeping judgement on a site. Home pages are often dissimilar to content pages, though these data generally correlate to Karl’s more extensive analysis. Regardless, the fact that an average of 25 errors per home page are present, and that only 4 of the 100 home pages had 0 errors is rather telling. There is much that still needs to be done to improve web accessibility.
It would be more helpful if you linked to the test results than the page.
Ted-
Because the results were collected using the WAVE toolbar, I can’t link to those results. One needs to load the home page and activate the toolbar to view the number of errors.
Thanks for posting this follow-up and including the many sites I did not include. Initially I also had a breakdown of which errors occur most often but a corrupted table caused me to have to rebuild the database and I lost that data. It was rather unsurprising, really: Missing alt attributes, missing form labels, inaccessible tables, keyboard accessibility, etc. What I hope to be able to do in the future is provide a ranking that takes into consideration not only the volume of errors but the density & severity of them as well.
I would put more energy into finding why accessibility has deteriorated and address the core issue: CMS systems, site builder tools and large framework systems..
Most sites are built with CMS systems or site builder tools, the website creator doesn’t need to know html or or understand accessibility issues. Its up to the strength of the application developer to add proper label when the user selects an image or form.
Example — WordPress: Content person adds an image in the Admin Control. Title tags required, alt tags not required, no explanation of what an alt tag is. Content person wouldn’t have a clue so doesn’t think to add it. I think an easy fix for the WordPress application developers to combine the title and alt into one…
I could make this comment 5 pages long…
Karl-
We’re working on a similar system to capture specific WAVE error data across a number of pages. It is, as you know, a bit tricky to assign severity to an automated error. One missing alt text has virtually no impact while another can render something very inaccessible, for example. Still, I think more data across more pages would be helpful.
This was done more out of curiosity than for scientific usefulness. For example, the Facebook homepage had 8 errors, yet the logged in interface has 123.
Nancy-
With the possible exception of WordPress.com, I doubt any of the sites listed are built on a traditional CMS. CMS accessibility is certainly an issue for many sites, but the biggest issue is lack of education. I’ve consulted on a handful of the sites in this list (and am happy that all of them among the better sites) and can attest that education, not tools, is the key to better accessibility.
Seems only Government sites(in US and Canada) try enforce accessibility. mainly because they can get sued for violating section 208 of ADA. I’m working on a project with PDF accessibility for the Government of Canada and from the experience it seems like 99% of PDFs online are not fully accessible.
Does AQUA also test PDF files?
There’s a great tool from XY Media – PAC,(www.xymedia.ch) but even that is not full proof, you still need manual testing.
Perhaps a lot of the errors are caused by dynamic HTML – tools like MS Visual Studio and ASP.Net tend to create very bad HTML.