Why There Isn’t (And Never Should Be) Accessibility Certification

In my work with Applause, I routinely encounter the same question from organizations around the world: Can you certify us for our accessibility? It’s a good question, as accessibility and inclusive design should be a central focus area for organizations that have digital properties or develop digital applications and solutions. Naturally, development organizations would want to check off that box on the never-ending list of things to track and complete. The answer, not sadly, is there is no such certification.

In this blog, I’ll cover a few reasons why certification would likely never be a viable option for accessibility in the digital space, and why elements of the accessibility process may give a false sense of a product or service being certified.

Vendors can confuse organizations regarding accessibility efforts

In my work, I hear teams tell me that some vendors state that they can offer accessibility certification. In many cases, it’s difficult to sort out whether the misunderstanding here is in how the vendor pitches their accessibility services, if there is intentional deceit, or misinterpretation by the receiving organization. It’s true, at the point where accessibility audits are complete and remediation of issues is also complete and tested, one might say that a website or app could be deemed “accessible.” 

The gray area is that, while the site may be accessible to a given standard, say Web Content Accessibility Guidelines (WCAG) 2.2 AA, at that point in time, it will likely only be in that state briefly. Why? If the website or app is like most – constantly being updated, with new content rolling out in various languages – there is a good chance of an accessibility issue being created within weeks of the latest audit. To ensure accessibility, you’d need to test after most changes. And, you’d continue to have to test. See the point? If you want to change and innovate, you must test for accessibility as you do so. It’s really no different than functional testing in this way.  

I also point out that most organizations currently just drive for compliance to WCAG 2.2 AA, never looking to move into AAA compliance. Why do organizations stop short of AAA? For the most part, the benefit of achieving AAA status requires a significant commitment from organizations in terms of personnel and time. At the point of reaching AA, accessibility-savvy organizations instead move their efforts toward inclusive design, a much higher-value activity, as your organization can be compliant to WCAG 2.2 AA, even AAA, while the experience you’ve created for people with disabilities (PWD) may not be pleasant, not to mention inviting or even fun. 

Inclusive design aims to improve the overall user experience for everyone, not just for PWD. How people receive an experience is personal, so any “verification” becomes a self-imposed target that results from planning, UX studies and a multitude of other factors. If an agency was to certify accessibility and inclusive design, how exactly would it do that? 

VPATs and ACRs: further certification confusion

Two common terms that may confuse organizations working toward accessibility compliance are Accessibility Conformance Report (ACR) and Voluntary Product Accessibility Template (VPAT). Both may unintentionally play into certification confusion. 

An ACR shows the degree to which an organization’s technology/digital properties meet an accessibility technical standard such as WCAG 2.2 or Section 508. A VPAT – a registered trademark format developed by the Information Technology Industry Council (ITI) – is a template that suppliers can use to complete an ACR. Since Section 508 of the Rehabilitation Act requires U.S. federal government agencies’ information and communications technology to meet certain accessibility standards, the VPAT was created so vendors could provide the required information. Now, many procurement teams require VPATs/ACRs as part of their technology sourcing strategy. 

Once completed, many companies post ACRs on their website so visitors can see the status of various digital products. Take a look at Microsoft’s ACR page. You can search their products to see how they support recognized global accessibility standards. 

Since we live in a world of certification – for example, where organizations receive certificates for financial audits or security audits – we’ve come to expect certificates for many things we achieve. Some organizations get confused when they are completing or posting an ACR. They may assume that showing accessibility status is the same as certifying a product or solution, but an ACR is solely a document that describes where a product stands against a standard. It is not a certification, nor is there an organization that legitimately certifies accessibility, anywhere. 

Sadly, some accessibility partners suggest that if an organization does an audit once, fixes the issues discovered, then posts an ACR, they’re all set. That is never the case. In addition, organizations may be prompted to add the name of the accessibility partner that has audited their site in an effort to create a sense of legitimacy (and to promote the vendor). It’s easy to see how this might lead organizations to think they are certified. 

Still, posting ACRs is a best practice for accessibility transparency, even though it does not mean accessibility compliance, because – in addition to an organization’s voluntary posting of their products’ accessibility status – posting ACRs and accessibility plans tends to have an anti-lawsuit effect. It’s hard for law firms who are looking for accessibility lawsuits to serve a demand letter to an organization that openly shares what it’s doing to actively meet accessibility standards. This is interesting as there is no expectation that a product or digital property be 100 percent compliant when you fill out a VPAT to complete an ACR: you’re simply stating where you are on your accessibility journey. In fact, you may have found a major accessibility issue you are working on. That’s fine, put it on your ACR and continue working to remedy it.

Technology constantly changes, and so should you     

Things change fast. Nothing is ever “one and done.”

This point may be the most obvious reason why an accessibility certification would likely never be viable. And this is why some of the global leaders in accessibility and inclusive designs do frequent audits. For example, Applause has worked with Cisco Webex for years. They now have a very robust accessibility and inclusive design program that is packed with best practices. As an example of this, they use a PEACE acronym (people, education, accountability, compliance and empathy) – as a motivational fulcrum that supports their organization’s commitment to their accessibility efforts. 

Cisco has many complex products. For example, the Webex platform has many components, with frequent releases impacting different elements of the platform. Not all of the elements may need an audit every six months, or even annually, but some may, and others may require assessment much more frequently than every six months. 

In reality, auditing must happen, but to minimize new issues reaching production, development may require in-sprint testing, as there may be a considerable backlog of issues. Audit frequency really comes down to the product release cadence. Some products have new features added almost daily. To avoid arbitrary audit planning, organizations need to consider what’s changing and how fast. They need to train staff, retain knowledge, welcome feedback and celebrate their progress.  

The need to test for accessibility issues becomes even more staggering when you consider the new devices being released into the market – desktops, laptops, tablets, mobile phones and the assistive devices that operate on them. Are you ready for the next  iPhone or Samsung release? What about using the latest release of JAWS screen reader on both? As you can see, when you consider all of the device possibilities, OSes and assistive technologies available, finding a certifiable state of accessibility becomes much like finding a real-life unicorn. Accessibility must be created in an organization’s culture, cared for and fed, and it’s an ongoing journey. It’s like fitness. You don’t become fit and stay fit unless you continue to incorporate all the elements required for long term success.  

Overlays overblown: There’s no shortcut to accessibility compliance

You can’t blame someone for looking for a shortcut. When it comes to overlays, the shortcut ends at a swamp.

An accessibility overlay (also called a widget) is an automated piece of software that can detect and fix accessibility issues. Simply put, it is a piece of code, usually Javascript, added to a website. This code runs within the user’s web browser and modifies how the website is presented. For example, if a user requires different color contrast on a website or wants to increase the font size, this code change enables this. But there’s a catch. 

While overlays may have a perceived immediate positive impact on what the user requires, they often break the experience because the website wasn’t built with accessibility in mind. For example, increasing the font size from 10 to 22 points may help a user read the font, but create another problem. Now that the font is larger, a button that was coded to display right next to specific text may have been moved to an unintended position on the page. In other words, the site wasn’t set up to handle the font change in a truly accessible way. The user may have to scroll way down the page, then scroll over to the right to locate the button, if the user is even able to find it at all. If this issue had been considered within coding for accessibility, it would have been written to keep the button from moving. Many other things can go wrong when accessibility isn’t thoroughly baked into a website: Users may not be able to pause animations, or spacing intended to help people with cognitive disabilities may be impacted, just to name a few. 

Of course, the biggest issue with overlays is the false sense of being accessible. And, as I’ve said, this leads some to believe that they are “certified” due to the sense of security that overlays may provide. If you’re not fully educated on what overlays can and can’t do, it would be natural to think that they act as a gatekeeper for accessibility issues and protect you. 

In a recent lawsuit listed on ClassAction.org, accessiBe, a solution provider whose purpose is to help companies comply with ADA and adhere to WCAG, is charged with not being able to ensure ADA compliance as advertised. The suit claims that accessiBe leverages companies’ fear of litigation, time-consuming manual testing and remediation to mislead them into believing that their overlay will make them compliant. As stated in the article: 

“To bring a website into compliance with the ADA and industry-standard Web Content Accessibility Guidelines (WCAG), experts recommend that site operators primarily use manual methods of testing and remediating underlying code, the filing explains. Many experts maintain that conforming to these standards cannot be achieved on a wholly automated basis, the suit notes.”     

If it’s for humans, involve humans in the SDLC

As I’ve mentioned, there is no organization that provides (legitimate) certification of accessibility. Not ADA, not the World Wide Web Consortium, not the U.S. government, not the European Union. The only true “certification” is how well your digital properties and solutions work for PWD. For example, Chase bank hears from customers with disabilities who report they chose Chase because of the fact the mobile app and branches are more accessible than other banks’. 

Organizations must work hard to include as many of the world’s incredibly diverse population in the accessible experiences they build. This diversity is the secret sauce. It’s a pipeline to new perspectives, cultural nuance, creative suggestions and the innovations that flow from this input. So, it’s no surprise that to do this you must involve diverse input in the design and conception phase of the SDLC. Waiting to test until the end of a product development cycle does not work.   

As stated previously, overlays/widgets can’t possibly account for the accessible features humans can tell you they need. Again, to use the analogy of fitness, overlays are like following a generic fitness plan that takes no personalization into account, vs. working with a trainer who looks at your health holistically and builds a specific plan for you. In fact, I follow commentary in social media channels by accessibility advocates – many of whom have disabilities – and they routinely say that overlays do not meet their needs. They are not inclusive.

According to the World Health Organization, approximately 1.6 billion people (about 16% of the world’s population) have a disability. As a fraction, that’s 4/25, or just shy of one in five people. As an organization, you’d want about the same representation of PWD in your product development. At Applause, we work hard to involve our global community of testers who represent the world’s diversity. Our global testers bring cultural perspectives and years of expertise in testing as well as experience as regular consumers of our customers’ products and services. Our testers come from all walks of life and represent the wide variety of disabilities that people live with every day.

There is a constant need to test, be it for accessibility or core functional testing. Testing must evolve with your product roadmap and strategy – and if your product serves humans – then involving them in the product development early and often is key.     

Commitment and dedication is the best certification of success

From my experience, leading organizations in accessibility and inclusive design practices build their own discipline, ethic, culture and rigorously execute their accessibility plan. They didn’t reach this advanced stage overnight. It began with a few employees who became educated and exposed to issues facing PWD. They sought executive buy-in and then efforts slowly gained momentum. They leveraged evangelists to educate different groups, typically by having them meet with PWD in empathy sessions, where the specific guest speaker shares how he/she moves through the digital world and the challenges they face. Only through this exposure, and resulting empathy, do personnel in your organization put a human face on the user.

It’s not technically difficult to progress accessibility efforts, but it requires a cultural shift in organizations. The goal is not certification, but the ongoing streamlined and optimized digital experiences you provide to your users…and the joy you bring to them by showing them that you care, and that they are part of the success of your business.

Planning, education and consistency matters

Use this simple checklist to keep your accessibility and inclusive design efforts on track:

• Seek a reputable third-party partner. If you don’t have in-house expertise on accessibility and inclusive design, seek a vendor who understands that accessibility is an ongoing journey, and who has access to a wide variety of testers, including PWD.
• Understand ACRs and VPATs. Test for WCAG conformance as you develop and publish ACRs to inform your community of your ongoing accessibility efforts.
• Know that ACRs do not equal certification. Nor do statements from an accessibility partner attesting to recent audits and results.
• Recognize that technology and human expectations constantly change. Organizations must constantly re-evaluate accessibility testing and strategy related to it.
• Avoid overlays. They do not represent actual input by PWD and they are not built into the accessibility code on your digital properties or solutions.
• Use humans to build when you’re building for humans. There’s no better way to make a great product or experience.

Applause is happy to speak to you regarding any accessibility or inclusivity questions you may have.