Not a Checklist: Building Accessibility Compliance into Your Business Processes

Among the top million websites’ homepages, 98% have accessibility barriers, according to WebAIM. WebAIM also found an average of almost 60 accessibility barriers per homepage, concluding that less than 1% of homepages were actually accessible. As a result, there are about 2,500 federal lawsuits filed in the US about inaccessible websites and technologies every year, but other countries, including Canada and the EU, have stepped up more recently and learned the lessons of the ADA.

This blog post is adapted from a presentation made at axe-con 2021. The goal of this blog post is to highlight that complying with the ADA or the Canadian laws is not a checklist and that, in general, accessibility is not a checklist. In other words, digital accessibility is not about checking the boxes of WCAG 2.0, it’s not about compliance with the law, and it’s not a one-and-done proposition.

Rather, digital accessibility is about having your customers be able to use your website and technology. Accessibility is as dynamic and ongoing as your website is. Every time you change your website or update your technology, you’re changing its accessibility and, therefore, should be updating that accessibility.

Achieving accessibility compliance is about building accessibility into your business and development processes, so that accessibility is incorporated naturally. Accessibility practices should not be a last-minute emergency and the impetus for accessibility should not be a complaint or a lawsuit. The point of accessibility is to ensure that all your customers can reach the goods, services, and information you are trying to provide.

Example of Not-a-Checklist Accessibility Compliance: Accessibility for Ontarians with Disabilities Act (AODA)

I want to start this blog post by talking about the Accessibility for Ontarians with Disabilities Act (AODA), because it has legally incorporated much of the learning that we’ve done through the Americans with Disabilities Act over the last 30 years. AODA has seven general accessibility requirements: planning and training, information and communication, employment, transportation, the built environment, customer service, and compliance.

The web-specific requirements of the AODA are in chapter 14, and apply to any websites that a covered entity controls, either directly or through a contract. They required companies to make any new websites and web content accessible to WCAG 2.0 Level A by January 2014. By January 2021, AODA required that all websites and web content comply with WCAG 2.0 Level AA, with a few exceptions.

The AODA is not enforced by litigation, but by the Ministry of Community and Social Services. The government oversees, investigates, does audits and can impose fines of up to 50,000 or $100,000 per day. AODA has really incorporated the “compliance is not a checklist” model, because companies and agencies in Ontario must implement policies around accessibility, must implement procurement requirements, must do training of employees, and must have publicly available plans about their accessibility.

Implementation of an Accessibility Policy

The AODA’s policies require businesses and government entities to have external-facing, publicly available policies about how they achieve and/or will achieve accessibility, and a statement of organizational commitment to meet accessibility needs in a timely manner.

This requirement is mostly about high-level policies, but as an important best practice, internal policies are also necessary. Your external policies mean very little if they’re not implemented through internal policies that assign how to accomplish accessibility, who can provide expertise, who is responsible for accessibility, who holds the purse strings for accessibility, and how accessibility is measured and improved.

Accessibility Procurement

Moving on to procurement, the ADA doesn’t specifically require you to procure accessible technology. However, the AODA requires government and public sector organizations to include accessibility in their procurements, such as requests for proposals and contracts, and requires smaller organizations to pay attention to accessibility when designing, procuring, or acquiring technology. This is similar to the federal government’s Section 508 requirements, which say that if they purchase, develop, or use technology, they have to ensure that it’s accessible.

A best practice is to incorporate accessible design requirements and responsibilities into vendor and service provider contracts. That protects you, the purchaser, from having responsibility for the accessibility problems that are built into something you buy.

Employee Accessibility Training

AODA also requires training on the law for employees, for participants who develop organizational policies, and for anyone who provides goods, services or facilities on behalf of the entity. Training must be done early, must be ongoing, and must be documented. You can find training through an expert like Deque, who has instructor-led or online accessibility training.

Building an Accessibility Plan

Finally, AODA requires entities to have an accessibility plan. It recognizes that on day one, there may still be barriers. This plan has to lay out how the organization will prevent accessibility barriers from slipping in in the future, remove barriers that have already been there, and meet the legal requirements. This plan has to be publicly available on its website and reviewed and updated every five years.

A best practice for how to build this plan includes consulting with accessibility experts– they can tell you what the biggest problems are on your web properties. Also, good practice requires tracking, measuring, and reporting on progress more regularly than every five years. When I work with clients, I recommend that this review happens at least every year, if not several times a year.

Americans with Disabilities Act (ADA)

The ADA has a different framework as it covers state and local governments and public accommodations. There are 12 categories of public accommodations, but they’re most businesses that we deal with regularly, i.e. doctors, lawyers, stores, etc.

The standard for compliance with the ADA is called “effective communication.” Any communication that the entity makes to people without disabilities has to be equally effective for people with disabilities. The way you do that is by providing auxiliary aids and services. Accessible electronic and information technology, such as websites, is an auxiliary aid. So when websites are a communication method of a business or government, they need to be accessible.

Part of the standard for what’s effective is that it has to be timely. If you have a website that provides information to people without disabilities 24/7/365, people with disabilities should be able to get that information 24/7/365 as well. In other words, you cannot have an inaccessible website and say that your customer service line is an effective alternative if it is not available 24/7/365 like an accessible website would be.

The website also has to protect the privacy and independence of the individual with a disability. Oftentimes, companies will say, “well, my website’s not accessible, but I’ll have customer service read aloud what the customer wants and take their credit card information.” However, that’s not as private as what people without disabilities get, so that’s a problem. It’s also not an independent way for people with disabilities to access the goods, services and information on the website.

In summary, effective communication has to be accessible, timely, private, and independent. People with disabilities should be able to acquire the same information, engage in the same interactions, and enjoy the same goods and services as people without disabilities with substantially equivalent ease of use. The question you should keep in mind is, “is this as easy for people with disabilities as it is for people without disabilities?”

So, what’s the standard? The standard is effective communication. Federal government agencies, the Justice Department, the Section 508 law that applies to federal government agencies, the Department of Health and Human Services, and the Department of Education have all recognized that WCAG 2.0 Level AA is a means of achieving effective communication.

This standard was never enacted into regulations, so you are not required specifically to comply with WCAG 2.0 Level AA, but if you choose to, that’ll cover you. If you can find another way to do it without complying with WCAG 2.0 Level AA, you are free to do that, but you’ll have to prove that it achieves effective communication.

There are two defenses to the effective communication requirement. The first is undue burden, in that being accessible would be so significantly difficult or expensive compared to all your entity’s available resources that you just can’t do it. The second defense is that having effective communication would fundamentally alter the nature of the goods or services, i.e. that it would make them not do the things that they’re supposed to do.

Both these defenses need to be documented in writing by an official who has budgetary authority, and they need to layout why accessibility is an undue burden or a fundamental alteration. Also, the entity still has to provide an alternative mechanism to get effective communication, so if the website is not accessible, the entity still has to provide another way people with disabilities can get the same information with substantially equivalent ease of use.

Implementation of Accessibility

Let’s review the five major buckets of business process implementation for accessibility. The AODA lays some of these out much more explicitly than the ADA does, but U.S. organizations that implement the ADA have discovered that these best practices actually work. Ultimately, AODA learned from our experiences with the ADA and made these things part of the law, because you’re more likely to actually achieve compliance if you focus on these buckets of approaches to accessibility.

Accessibility Policies and Staff

One of the first things that folks need to do is adopt an accessibility policy and publicize it. My firm has a policy that we will comply with WCAG 2.0 or WCAG 2.1 level A and AA. It’s very important to set the standards so people know how you’re judging yourself.

Some folks say to me, “well, if we adopt a policy, they’re going to think that we have to comply with it right now and we’re not ready, so maybe we won’t adopt a policy,” or that “it’s going to highlight that we’re not ready and we’re putting a target on our back to say we haven’t achieved accessibility yet.” My answer is, every person with a disability who goes to your website already knows if it’s not accessible.

An accessibility policy makes the disability community much more patient with you if they know that you know your website is inaccessible, and you have a plan. Ideally, you have a plan with benchmarks and deadlines and assigned responsible staff who have the authority and expertise to take it on. If this is in place, then the disability community is more likely to believe you and say, “Okay, we’re going to keep watching, but we’re not just going to go after you through litigation or turning you into a federal agency. Show us that you know and that you’re working on it and how you’re doing that.” More transparency leads to more patience on the disability community’s part.

Next, hire and/or assign responsible staff that have both sufficient authority and budgetary resources to get the job done and who have sufficient expertise to understand what the problems are and how to fix them.

Furthermore, it’s really important to train developers to build things to be accessible from the beginning. Also, don’t forget to train the content creators– a lot of stuff that’s on your websites and in your technology starts with someone who types up a document or a PowerPoint. If content creators know how to make it accessible from the beginning, then it’s much easier to keep it accessible throughout the process until it’s live on your website. If they don’t know how, then you’re spending more resources on the back end, making it accessible too late. Be sure to provide experts and resources for both developers and content creators so when they run into a problem they know who to turn to internally or externally.

Lastly, ensure that everything that gets posted gets reviewed before it gets posted, i.e. create a bottleneck. I know, we all hate a bottleneck, but a bottleneck will save you a lot of trouble in the long term. If there are pre-posting reviews, you’ll also have a process if you’re going to pursue an exception for undue burden or fundamental alteration.

In the AODA, an undue burden is if a piece of technology is unconvertible, or if it’s not within the control of the organization. In the ADA, someone with the appropriate authorities needs to review any request for an exception and decide whether it really meets the standards for the exception, document that it meets the standards for the exception and why, and document the interim alternative measure for getting people information in the meantime.

I also recommend establishing accountability mechanisms for developers and content creators who do create inaccessible material. It’s great to have a bottleneck, but if a developer keeps putting things up to the bottleneck that aren’t accessible and someone else has to keep fixing them, then that’s not ideal. That developer or content creator ought to have it come up in their performance review because that will generate much more interest in ensuring that things are accessible before they move forward.

Accessibility and Procurement

Accessible procurement is a big problem for lots of organizations. It’s very important to put accessibility language in your contracts and in your RFPs and to have a procurement accessibility policy that is quite clear to your vendors. Your contracts should also require that vendors will certify that their product is accessible and that they will note any exceptions to that and why.

Ultimately, vendors’ exceptions are going to have to meet your undue burden or fundamental alteration standard. The vendor should let you audit their product for accessibility and they should also audit their own product for accessibility. The contract should provide that if there’s a problem, the vendor will fix it. You don’t want to have to fix a vendor’s accessibility issues yourself or pay someone else to fix it.

Remediation

The first thing you need to do is identify any barriers that already exist in your website or web content. This can be accomplished by an audit done by an external partner. Following the audit, there’s the process of prioritizing which issues to fix. We all know you can’t fix every accessibility issue in one day, so prioritizing the critical or severe barriers that affect the most customers is important. Another way to prioritize which issues to fix is by the importance of the function. In other words, how severe is the barrier: is it inconvenient to the user, or does it totally block the user from accessing this button or function or service? You can also prioritize easy wins by fixing issues that occur on every page.

I always advise people to have a barrier elimination plan, and you can do this a variety of ways. You can do it page by page, barrier type by barrier type, etc. Any of those is fine as long as you’re remediating them on a priority basis. It’s also important to assign people who are responsible for getting it done, overseeing getting it done, tracking and reporting on progress, and assigning resources (money, staff, and time).

Remember to track and report progress, and then continue to update your progress. AODA requires that every five years you report on your accessibility progress, but that is far too long to tell whether you’re making progress. While the disability community may be more patient if you are being transparent about what you’re doing and when you’re doing it, five years is still an awfully long time.

Sample Remediation Worksheet

Above is a partial sample worksheet for remediation of accessibility barriers. It illustrates that an organization is going to develop and implement a policy, resources, who’s going to do it, how much time they are going to devote to it, and a completion date.

It’s essential that you establish and publish interim means for providing alternative access during the accessibility remediation process. This could be delivered in the following ways:

• Phone line where trained staff will read web information
• Email address to request accessible versions of documents
• Process for escalating accessibility requests/complaints
• Vendors with deadlines for converting to accessible formats on request

Audits

I highly recommend measuring and monitoring accessibility progress through combinations of automated and manual or user audits. You can do such audits internally or you can hire a qualified vendor. However, testing with user audits, ie. with real people with disabilities, is very important to avoid the false negatives and false positives that automated audits often provide and to identify how significant each barrier really is in context.

I recommend a series of audits that are based on how good each business unit’s controls are in place for accessibility. Specifically, look at what accessibility controls are in place– does this unit have a good policy, does it have trained people who know how to do what they’re doing, did it do really well on its last audit, and does it have a bottleneck before posting?

Frequency Guidelines for Monitoring of Accessibility Compliance:

Feedback

Lastly, make sure to get feedback. Accessibility compliance is beyond internally monitoring what we have fixed so far, if we have met our deadlines, and if your website or content is complying with WCAG. People with disabilities who are trying to use your website are actually your best experts, and many of them will give you feedback for free. So, invite feedback by saying “we really want to hear from you,” welcome it, and respond.

Don’t ask people to send the feedback to an anonymous email address, as that is not a very satisfying mechanism of giving feedback to the person who’s giving it. Publicize your efforts, your plans, and your progress. When I talk to companies who’ve been found to have a problem, I say, “lean into it, use yourself as a case study, be a model for the next group, but get on it, and publicize every accomplishment you make.”

Lastly, hire user testers that are people with disabilities – they bring tremendous expertise to this work. Hire them to also be your beta testers before you roll something out.

In Summary

To sum it all up, accessibility compliance is about welcoming all customers. Accessibility is not about avoiding a disability lawsuit. You may avoid a disability lawsuit, but people can sue over anything. Hopefully, you will avoid losing a disability lawsuit if you do these things, but what you’re really trying to do is welcome all customers.

Companies that are in the B2B context say, “Well, my customers aren’t people, they’re other companies.” Well, those customers that are other companies have ADA, AODA, or EU obligations– you don’t want to make your clients violate the law because they won’t like it and they won’t come back. Furthermore, employees and customers of your customers have accessibility needs. You should be prepared to answer the accessibility questions that your customers are going to ask.

In essence, it’s best to solve accessibility problems you may encounter using the implementation approaches above with tech staff, content creators, supervisors, and customers who will give you feedback– not lawyers.