The five stages of grief, AKA accepting accessibility

Recently I spoke on a panel at the M-Enabling Summit about Accessibility in SaaS (Software as a Service). This is basically what I do, all day, every day, and I’ve been doing it for many years (so many years that it’s starting to get embarrassing—unless I started in accessibility when I was five years old!). I mention this because over the unspecified number of years that I have worked in accessibility, I have found that vendors’ responses to accessibility requests are surprisingly consistent. So consistent I referenced them in my “How to read a VPAT” webinar and associated article.

I call these responses the Five Stages of Grief, AKA Accepting Accessibility.

The five stages of grief—denial, anger, bargaining, depression and acceptance—were defined by Elisabeth Kubler-Ross about people who were dying. Even the most hardened anti-accessibility advocate can admit that accepting accessibility is not as bad as dying; but Kubler-Ross’ five stages still seem to apply. Just as with the five stages of grief, the five stages toward accepting accessibility are not always linear, and some stages can be missed.

Denial: we are accessible

Back in the mid-2000s (when I was only five years old 😊), I worked with Monash University on a SaaS product they had purchased. When we asked for the product’s accessibility compliance, we were sent a print-out (yes, a print-out—via fax!) of the Web Content Accessibility Guidelines 1 (yes, WCAG1!) with ticks beside each checkpoint (later called “success criteria” in WCAG2). I had been in the accessibility industry for an unspecified number of years prior to this and had actually contributed to WCAG2 with the W3C, so those ticks weren’t fooling me (the complete lack of ALT attributes was a fairly useful barometer as well).

What did we, the client, do? We told them that they weren’t accessible. They argued they were. So, we sent them a print-out of the site run through Bobby (the very first automated accessibility testing tool). And thus, we move onto the next stage.

Anger: we don’t need to be accessible / no one else has asked for accessibility compliance

A couple of weeks later we get an email telling us that they don’t need to be accessible. I have heard so many different variations on this theme: from a major ticketing company telling me that people with disabilities don’t buy tickets (to anything at all? Even the Paralympics?) to a company telling me that their CEO had given them an exception (as a CEO, perhaps I can tell the tax department that I have an exception to paying my tax obligations?).

When we questioned this “exception”, the company proceeded to tell us that “no one else has ever asked for accessibility compliance, ever”, which was laughable. This was a US company with US Government clients. VPATs (Voluntary Product Accessibility Templates) were introduced in 2001. You’d think that this excuse would not have stood the test of time, but I heard it less than a year ago from a vendor. That time it was from a mid-sized company with US universities as clients.

When we called bulls*** (in a respectful and professional way, of course), the vendor moved to the next stage.

Bargaining: it’s going to cost us millions (and you have to pay for it)

Ever since the very first accessibility litigation (in Australia against the Sydney Olympics), vendors have been screaming about how expensive accessibility compliance is, and it can be… if you are retrofitting a product. But it’s not that expensive. Vendors seem to have taken their cue from this inaugural court case, where IBM argued it would cost $16 million to make the Sydney Olympics web site accessible. When the judge ruled in favour of the litigant, he deemed the site would have cost $20,000 to make accessible. Yes, I know that was more than 20 years ago and inflation is on the rise, but it hasn’t risen that much (according to Google, $20,000 in 2000 is equivalent to about $34,000 today).

I worked for a very large Australian council in 2009. They only engaged us to train their content authors (not their developers) and do a final site audit. After the audit, they estimated that there was approximately one year’s work for one person to fix the site. Five years later, they redeveloped their site and engaged me again (this time through AccessibilityOz). This time, they committed to our whole recommended range of tasks when rebuilding the site. Once the final site audit was completed, they estimated that there would be two weeks’ worth of work to fix the errors we identified.

That same Australian council purchased a payment gateway, and we audited it before it went live. The vendor also claimed their site was accessible (via email this time), and then that they had an exception (because they were an “international” company), and then told the client it would be $2 million to fix the product and the client had to pay for it. This for a product that the client had purchased for under $100,000.

Our client was not happy. We advised that they wait for a more reasonable response from the vendor. Because, in my experience, there is always eventually a more reasonable response. Except for when there isn’t, and this brings us to stage four.

Depression: then we’ll pull our product

I hear this excuse much more from freemium vendors than paid vendors. Once a client has paid six figures for a product, the vendor isn’t going to give back that money and go home. But for the vendors that provide the content for free, this appears to be the trump card. Unfortunately (for the vendors) and fortunately (for everybody else), there is a precedent against this. In 2015, a lawsuit was brought against UC Berkeley, MIT and Stanford for not having captions on their videos. As a response to the lawsuit, UC Berkeley removed public access to their videos. The judge deemed this inappropriate (and cowardly, but that is my opinion).

When I hear this excuse, it is usually a bluff, and I don’t think it has ever worked. Even with UC Berkeley, who followed through, it still didn’t get them out of their accessibility obligations.

Which brings us to the next and, thankfully, final stage.

Acceptance: we’ll build it into our next release

After a few meetings with us and some reading of our developer resources, every single vendor we have worked with has reached this final stage and accepted that accessibility is an integral part of development. They realise that everyone needs it, that it is their responsibility and, in most cases, are thankful that their client has engaged someone else (us) to identify the accessibility issues that they need to fix. Finally, they realise they got a free accessibility audit.

Sometimes they reach out to us to provide training or a re-audit once fixes are completed. Sometimes they feel like they have burned their bridges with us, but we understand that it is a natural grieving process to go through these five stages of accepting accessibility. We don’t blame the vendors: accessibility can appear terrifying; there are so many myths about it. People think it is easier to fight it than to just accept it; but as with grief, acceptance is the only way.

And then we all live happily ever after.