This Week in Accessibility: What we can learn from the “WebAIM Million”

A human hand reaching out being drowned in a sea of pages

Summary of an accessibility analysis of the top 1,000,000 home pages

This week being the syzygy of accessibility conferences, WebAIM took the opportunity to publish its accessibility analysis of the top one million web pages consisting of home pages from 730 unique top-level domains, .com (521,316), .org (76,489), and .net (39,757) being the most common and 6,010 distinct .edu home pages.

It’s a long, very detailed, research-oriented, high-quality study. If you are the kind of person who geeks out on stats, read it at its source. Otherwise, here are what I think are the high points. Or low points, depending on how you view the issue.

  • There was an average of 59.6 errors per home page.
  • Users with disabilities would expect to encounter software detectable errors on 1 in every 13 elements with which they engage.
  • 97.8% of home pages had software detectable WCAG 2.0 Level AA non-compliance

While these results look bad, in actuality, the true results are probably much worse for the following reasons:

  1. WAVE as awesome as it is can only detect about 30 % of WCAG 2.0 Level AA errors.
  2. If an organization doesn’t care enough about accessibility to clean up their easy-to-find issues that can be uncovered with almost no effort, chances are they aren’t doing testing with screen readers, assistive technology hardware, or putting any effort into making sure things that require extensive manual testing (positive tab index values anyone?)
  3. The 10 new Level AA web standards from 2.1 Level AA were not included in the review
  4. Mobile web as a platform was not, since you can’t run WAVE over a mobile website. All identified desktop errors would likely also be visible on mobile, and there would likely be additional mobile specific errors on iPhone (especially plus sized iphones), iPad, and Android as well.

There is a lot of accessibility low hanging fruit out there

The most widely reported issue by far was that > 90 % of pages were missing skip links (AKA bypass blocks). The pages that did have skip links or bypass blocks were more accessible than pages that didn’t have them. This particular issue typically does require code to fix.

The remaining “WebAIM Million” widespread defects are what I call “5 minute, no-code fixes” — from the time you open the page it takes five minutes or less to fix, test, and push to production most likely through your CMS without any code changes required. Remember the old GEICO commercial — so easy a caveman could do it? (sorry couldn’t find a captioned version). Literally that is the category of these types of fixes.

  • 85.30% of pages analyzed had low contrast text. This defect which is simple to fix probably affects the largest number of people including people over 65, people with colorblindness, people who are low vision, and many people who just have crummy vision such as severe astigmatism who don’t consider themselves disabled.
  • 68% of pages analyzed had missing alternative text. Secondarily, almost 50 % of the use of longdesc as alternative text was invalid.
  • 58.10% of pages analyzed had empty links
  • 52.80% of pages analyzed had missing form input labels
  • 36.3 % of pages had skipped headings, and almost 15 % had no headings at all. This one might require code depending on your CMS, but since headings are an important navigation tool for screen reader users, it is one of the top WCAG 2.0 AA guidelines out there.
  • 33.10% of pages analyzed had missing language flags
  • 25% of pages analyzed had empty button identifiers

Any of the above would either hinder (at best) or completely block (at worst) a person with a disability from being able to access your digital property. This fruit is so low hanging, if it were any lower it would be rotting on the ground. I would definitely not want to be the lawyer put in a position of arguing that an organization didn’t have the time, resources or expertise to solve these issues. With a judge with any level of competency, that argument would get laughed right out of the courtroom.

Organizations are trying to be accessible, but clearly failing to get it right

60.1% of the 1 million home pages WebAIM reviewed used ARIA. You don’t use ARIA unless you are trying to make things accessible. Despite the majority of pages using ARIA, home pages that had ARIA averaged 11.2 more errors per page than pages without ARIA.

To paraphrase Yoda — in accessibility, do or do not, there is no try. There are no points granted to defendants in accessibility lawsuits for trying. If anything, using ARIA and having more errors than average makes an organization look worse — it confirms they KNEW enough about accessibility to put ARIA code in, but didn’t care enough to do a comprehensive job at it. Enough said.

Tool choice says a lot about an organization’s accessibility maturity

Organizations who use Squarespace had only half as many defects as average. Wordpress was just about average while sites using Blogger had a whopping 237 % above average. JQuery and Lazy.js utilization were also associated with significantly higher levels of defects.

Bootstrap utilization was associated with a 10 % increase in defects. I suspect this is at least in part due to the use of earlier versions of Bootstrap that weren’t accessible. If your organization uses Bootstrap make sure you are on Bootstrap 4 or use the Paypal bootstrap accessibility plug in. Yes, Bootstrap upgrades are painful (I’ve been involved with two of them so I have the scars to back this up) but they are less painful than getting sued. There are some good LinkedIn learning classes on Bootstrap upgrades. Earlier versions of Bootstrap are a steaming pile of accessibility dung.

Angular and React were both associated with a higher level of per-page defects. While WebAIM did not comment on the root cause for this, I suspect some known issues in compatibility between Angular/React and ARIA could have been the source of at least some of the increased number of issues? I will be investigating this further as it is a significant issue in the code I am currently working on.

Choice of partners says a lot too

ALL of the ad partners were associated with higher levels of defects. Anecdotally, I noticed this as a major issue also when working on cookies and GDPR implementations as the global head of accessibility for McDonald’s. Shockingly, Google was one of the worst. Companies using AdSense have almost 88% more accessibility defects per home page on average. Google has such a good reputation for accessibility, this stat was probably the most surprising in the report to me.

If an organization is voluntarily choosing to enter into a contract with any third party, such as providers of ads, cookies, mapping, search, zip codes, or surveys — The organization doing the choosing becomes liable for the third-party vendor’s inaccessibility. While an organization may be able to recover damages against the partner, both parties will likely get sued. Practice safe accessibility — choose your partners carefully !

Conclusion

If you haven’t run WAVE or a paid accessibility analysis tool from one of the industry leading vendors like Accessibility Oz, Deque, or Level Access on your main site and microsites, DO IT !!!!!

WAVE results are what lawyers who make millions from filing accessibility lawsuits use to decide who to sue. Time and time again, publicly available accessibility lawsuit pleadings mention WAVE results in the statement of facts. If your organization has accessibility defects that are identifiable via WAVE, it has a drastically higher chance of getting sued.

Take your audit results, find the low hanging fruit and do a search and destroy. For more information on how to prioritize issues found in an audit, read an article I wrote last Thanksgiving called Prioritizing Accessibility Defects for Remediation.