Inaccessible Third-party Content and Code — Why it is Important, and How to Address it
Cardboard with post-it note — Time for New Content
In the United States, various parts of the federal government have made it painfully and consistently clear in its rulings that the federal government doesn’t care who created inaccessible content or code, if it’s on your site, then the site owner is responsible for making it accessible.
The History
There are at least three rulings between the United States federal government and various inaccessible websites owned by for-profit companies catering to US customers.
H&R Block
Early in 2014, the Department of Justice entered into an agreement with H&R Block. In this agreement, the DOJ again specifically called out third-party content stating that “H&R Block shall provide a method of obtaining and using such content that conforms to WCAG 2.0 AA.” Furthermore, the DOJ specifically granted H&R Block additional time for remedying the third-party maps widget. Presumably, this grant of extra time for this specific component was made in recognition that this type of content was more difficult than average to make accessible, and the third-party nature meant it would take longer since it wasn’t entirely in H&R Block’s control.
Peapod
Later in 2014, the Department of Justice entered into a similar agreement with Peapod. Section 12(e) of the Peapod Settlement Agreement specifically addressed “3rd party content.” It required Peapod to seek commitments from vendors to provide WCAG 2.0 AA compliant content. The agreement also stated that if the vendors could not make a commitment to accessibility, that Peapod could make the inaccessible content compliant. This would seem to imply, for example, that Peapod could create Closed Captioning if it received video from a vendor that wasn’t captioned.
The only “out” provided to Peapod by the DoJ was if making the content accessible “would fundamentally alter the nature of its goods and services or would result in an undue burden.” Most US courts look not at departmental budgets, but the assets of an entire company in determining whether something constitutes an “undue burden.” It is impossible to see how the inexpensive cost associated with the closed captioning example above would ever satisfy even the most basic undue burden analysis. Likewise, adding closed captioning to a video that wasn’t captioned by the vendor hardly constitutes a fundamental alteration of goods and services.
Scandinavian Airlines
The most recent consent order regarding inaccessible websites comes from the Department of Transportation with respect to Scandinavian Airlines’ website inaccessibility, which did not call out third party content at all. Instead, the consent order focused on site functionality, stating that everything relating to core functions had to meet WCAG 2.0 Level AA. If any of these core functions or their content came from a third party, the DOT would presumably expect Scandinavian Airlines to deal with that inaccessibility as part of their responsibilities under the consent order.
Why?
The purpose of the ADA with respect to digital accessibility is to ensure that people with disabilities experience full and equal enjoyment of the goods, services, facilities, privileges, advantages, and accommodations of a company through its websites and mobile applications.
Assume that a company comes under the ADA as a public accommodation, if the US Government’s enforcement divisions exempted content and behavior created by third parties, the company that is the public accommodation could conceivably outsource the entire content and creation of a website and not experience any consequences if any of the resulting site were inaccessible. This result would be at complete cross-purposes to the ADA itself. Companies choose who they partner with, and voluntarily enter into contracts. If companies don’t choose carefully, their partner’s mistakes can end up getting imputed to them.
What to Do
There are several things a company can do to help mitigate the harm of third-party inaccessible content.
1) Include the level of accessibility required in your contracts
Every contract for goods and services should include a clause regarding the chosen accessibility standard. Don’t be surprised to hear a vendor says that they’ve never been asked to do this before, or that the ADA doesn’t apply to them, especially if it is a small vendor or one based outside of the US. A smaller (or foreign) company may not come directly under the ADA as a public accommodation, but that doesn’t mean they get to pass on their exemption to your company. Rather, it’s the reverse: If your company comes under the ADA as a public accommodation, your obligation to be accessible needs to be passed on to all your vendors regardless of where they are physically located.
2) Require remediation plus some other penalty for lack of compliance (or bonus for compliance, depending on whether your prefer carrots or sticks)
Your vendor will not have any skin in the game unless there is some type of penalty for lack of compliance. Learning to be accessible requires an upfront investment of time and money. Vendors will not be internally motivated to make that investment (especially if the ADA doesn’t apply to them directly) there needs to be external motivation for making the investment. I have been in environments where that motivation did not exist, and it is a constant, frustrating vicious circle of:
- Vendor doesn’t train its staff, or uses subcontractors who don’t train
- Vendor delivers non-compliant content/code
- The procuring company effectively acts as external QA for the vendor, reports defects to the vendor
- Time elapses. Eventually the vendor submits fixes
- Acquiring company must test again because the vendor isn’t trustworthy-
- Eventually the vendor is replaced, and you start over with a new vendor
I could write an entire long article on how this is a huge waste of time and resources. Building in accessibility from the beginning is the only way to do it correctly, and there either needs to be a carrot or a stick in the contract to nudge the vendor to making the necessary changes in their processes or training to deliver accessible code and content.
3) Specify a deadline for remediation for each type of inaccessible issue
If your vendor is creating content that will only be live for three weeks, giving them four weeks to fix it (assuming you don’t catch the issue until production) means accessible content will never go live. Keep this in mind when you are working through how much time to allow the vendor to remediate inaccessible content or code.
4) Make sure the contract addresses vendor remediation costs
Who wants to pay a vendor for creating inaccessible material and pay them again to fix it, while you are incurring the QA and auditing costs and potential schedule delays? That is basically the opposite of a penalty, that’s an incentive for your vendor to completely ignore accessibility, even if it is in the contract. Yet, if your contract does not address that remediation needs to be performed entirely at the vendor’s expense, that is exactly what may happen.
Conclusion
If you like living dangerously, by all means, ignore the accessibility of your third-party content. You may get sued, but it will be the vendor’s fault, right? Even though that might be the case, that certainly does not make it OK. Do not underestimate the disruption such a suit will cause, or the cost in time, energy, and legal bills fighting it. Also, do not over-estimate your ability to get the money back from the vendor under a warranty or counterclaim. Including accessibility as part of your procurement process when evaluating vendors (how committed are they to it, how have they demonstrated the ability to be accessible in the past) is an important part of evaluating vendors that will be contributing content or code to a corporate website that comes under WCAG 2.0 or 2.1 Level AA.