The true cost of universal accessibility
We have a long road ahead to an Accessible Web, and it comes with a significant backlog of work to be done. However, today’s development practices ensure that this backlog will grow exponentially — unless we measure it and address it soon.
The Accessibility Deficit
Over the past few years, the Web Content Accessibility Guidelines (WCAG) have emerged as the legal standard that all websites should adhere to in the US. However, virtually every live website or application has accessibility issues that keep it from being 100% compliant with WCAG guidelines.
The backlog of those unresolved issues is a form of technical debt: it’s the accumulated cost of not performing necessary work now before rolling out a technology deliverable. Like financial debt, it carries interest as delayed fixes are costlier to implement. Most technical debt arises from the conscious decision to put off fixes that may delay a launch, thus borrowing from future resources. In contrast, most accessibility debt is accrued unconsciously — usually out of ignorance of standards like WCAG.
Accessibility debt is straightforward to calculate: one starts with the number of person-hours it would take to make a component or theme accessible, then adds up those little bits of debt for a website- or project-wide total.
But what if you were to think like an economist and tallied up the accessibility debt across different websites or apps of a given type? Now you have a statistic that’s useful for planning on a different level. Let’s call this the accessibility deficit and define it below.
Accessibility Deficit:
The total of technical debt related to accessibility that can be attributed to a given technology, project, or component.
You could have an accessibility deficit for a component like a date picker, or for a WordPress theme, or for technology like Slack or LinkedIn. Or you could add up all of these accessibility deficits and come up with a truly macroeconomic statistic: the Global Accessibility Deficit. This figure could be used for planning investment in accessibility, or in planning policy or regulations.
Just how large are these deficits? Let’s start with a simple example.
How accessibility debt starts
A front-end developer creates an open-source photo gallery component that’s reactive, and she’s very diligent with her testing. Her javascript chops are very strong, while her knowledge of accessibility is a bit thin in places. She tests her component to the best of her ability on various browsers, devices, and breakpoints using available tools and plugins.
Satisfied with her work, she posts the source code for the photo gallery on GitHub and puts the word out in the front-end developer community. Within a short time, the gallery has been downloaded 15,000 times and has been put into production at least 10,000 times.
Since our developer is working pro bono and donating her work to the front-end community, she hasn’t considered hiring expert testers to ensure that her work product is accessible. After all, they’re often are billed out at $200 per hour.
10,000 sites x 2 hours = 10 person-years
As the photo gallery gets widely used, some accessibility issues begin to pop up. A fellow developer spends a weekend coming up with a patch for the issue. Let’s say it takes an average user about 1 hour to diagnose the issue and another hour to implement the patch. Multiply those two hours by 10,000 instances in production, and now you’re talking 20,000 hours or 10 person-years of developer time to make every live instance of this component accessible. That’s a few orders of magnitude greater than the 300 hours that our front-end dev originally invested in development and testing.
A more popular example
Suppose instead we look at a Divi, a popular theming framework used with WordPress. It’s the foundation for many WordPress themes, and there are 1,134,000 sites in production that use this framework. It’s popular enough to make the Top 20 list of frameworks on Builtwith.com.
The original Divi framework was not designed to be accessible; its standard markup contains numerous accessibility violations. In fact, to make Divi accessible, you’d need to install an accessibility plug-in to replace the markup with new code that meets accessibility guidelines. But most of the themes that have been built on Divi are based on the standard, inaccessible markup. Let’s assume that every Divi user would want to make the framework accessible by upgrading their theme to an accessible version (if that exists) or making accessibility fixes themselves on their own site(s). Now let’s assume that it would only take 8 hours to do so on average.
Using the same math as before, we have 1,135,000 sites multiplied by 8 hours, giving us a total of 9,080,000 person-hours. Divide by 2,000 hours per year, and now you have 4,540 person-years — or roughly 4.5 person-millennia.
There’s a lot you could do with that kind of manpower… in fact, you could probably build a pyramid. Personally, I’m deeply troubled by that magnitude of wasted human effort.
Going even further
Now imagine every other WordPress theme, every site built with Drupal, Joomla, SharePoint, Sitecore, every Angular or React component… now your accessibility deficit now approaches the size of the gross domestic product (GDP) of a small country.
Our accessibility deficit is a lot like pollution: every accessibility violation is like tailpipe emissions or asbestos that becomes a large and urgent problem when it accumulates. Unless you educate today’s offenders, then the problem is sure to grow and with it the accessibility deficit.
So, what benefit is there of calculating accessibility debt at this scale?
At the most macro level, it could drive funding for accessibility remediation from government, corporate, or even philanthropic sources. Without an estimate of cost, it’s hard to make the argument for allocating any funds. If you’re able to monitor the Accessibility Deficit closely over time, then you can also start calculating the return on investment (ROI) of any funding.
You could also calculate a per capita Accessibility Deficit to compare major developer communities. You would divide the community’s Accessibility Deficit by the number of members. Using this metric, it would not be difficult to determine the most accessible communities, making possible a rating or award like the Disability Equality Index. Given the tribalism and competition between developer communities, this could be a strong motivating factor for promoting accessibility in their respective cultures.
The Accessibility Deficit can also be tracked for large-scale open-source projects like React, Bootstrap, or WordPress. It could be used to pinpoint the worst offenders within each project, like a popular theme or a date picker. These offenders could then be placed first in line for remediation — they’d be the Superfund sites of accessibility.
Like pollution, our lack of digital accessibility is a macro-level issue that takes large-scale efforts and funding to fix. How is it then, that we don’t have macro-level statistics to measure this issue?
Coming soon: how to chip away at the Accessibility Deficit on the micro level: Accessibility product labeling for software and components.
