5 Approaches to Dealing with 3rd party (in)accessibility
I have an embarrassing confession to make. Tenon has accessibility problems. Some of them are our fault. Some of them are based on conscious decisions. Some of them are due to our use of 3rd party content and controls. But regardless of where the issues come from, once they’re on our system they’re ours to deal with. Let’s talk about 5 ways you can deal with inaccessible code.
Before I continue, I want to point out one option that isn’t listed below: “Leave it as-is”. Historically, legal cases around inaccessible ICT have mostly exempted third party content, but that often depends on the nature and source of the third party content. Platform accessibility issues are never exempted as far as I know. So if you’re an e-retailer being threatened with a lawsuit, you can’t deflect liability over to your vendor if their platform is the basis for your entire presence. As a general rule: that which is hosted on a domain that you own is your responsibility.
If it is already on your system
One of the biggest sources of accessibility issues on the Tenon website was the “McAfee Trustmark” we had in the footer of each page. The intent for having it there was for visitors to know that we take security seriously. Unfortunately, it doesn’t appear that the folks at McAfee took accessibility seriously. The service itself is pretty cool but at $149 a month, it didn’t add much value. Add the non-existent value to the accessibility issues, and it was an easy decision for us. We took it off and removed a pile of accessibility issues. If a feature doesn’t have a direct user benefit and has accessibility issues, the decision is easy: dump it and move on.
Sometimes you can’t just decide to do away with a feature altogether. When it comes to widgets and add-ons to sites based on WordPress or Drupal, there are often alternatives available that you can try. Another case where I’ve seen this work is with features that allow you to add your company’s job postings. Often the best approach is just find a replacement that meets your business goals in a more accessible manner. This approach obviously means you’ll need to invest a fair amount of time searching for an accessible alternative but let’s face it, that’s an exercise you should’ve done the first time around.
Fork it and fix it
On the homepage of Tenon, we use Code Mirror. We discovered some issues with keyboard accessibility and created our own fork to fix them. Some issues remain that we want to fix before issuing a pull request. For now, we have at least made some improvements and are planning on doing more. At times this approach may help deal with immediate issues but it can also lock you into your own forked version. The absolute best approach in this case is to issue a pull request with your improvements. This not only helps you and your users but also helps others who are also using the same product.
Improve it after the fact
Push on the Vendor
Over at the Tenon blog, I documented this a little bit when I discussed build vs. buy is even harder when you care about accessibility. In our case, Intercom.io is an extremely valuable service for use to help our customers. At the same time, we recognize that providing excellent customer service in real time is an important differentiator. No other accessibility tool vendor allows you to talk to support staff directly in real time. A large number of customers have told us that this level of support solidified their decision to go with Tenon. Intercom has had a direct ROI for us. Nevertheless, we can’t just look the other way on the product’s accessibility issues. We’ve communicated our concerns with the vendor and will continue to do so until either they address accessibility or there’s a suitable accessible alternative. We’ve even toyed with the idea of making our own.
Avoiding the problem
Of course not choosing the inaccessible product is the best approach. Unfortunately, most people don’t realize the product is inaccessible until it is too late. One of the ways that people in the public sector have tried to deal with this is by requiring a document like a VPAT or GPAT. Vendor statements on accessibility are often laughably poor and may not even exist. This leaves you with only one choice: Test it yourself or have someone else test it. Yes, I’m suggesting that you test someone else’s product before you choose it – the same as you would to verify that it meets your business needs, privacy needs, and security needs.
Determining the level of effort you expend on doing this testing is proportional to your exposure to risk and how much impact the specific product will have on that risk. In many cases, you can get a good idea of how accessible the product is by doing only a handful of tests. The results of such testing will be less-than-scientific, but will definitely give you a strong understanding of whether you should bother moving forward with that product or look elsewhere. Once you’ve narrowed down your choices, you can decide whether a full-blown audit is warranted.
It is impossible – and a horrible business decision – to roll your own code for every system you use and every piece of functionality on that system. A lot of things go into deciding what 3rd party product you should use. Accessibility needs to be one of those things you consider strongly, especially in the United States where litigation is happening at an unprecedented pace. There’s no such thing as “perfect” accessibility, but hopefully this post helps provide guidance in choosing the right product and how to deal with any lingering accessibility issues once the choice has been made.