The “perilous pitfalls” of Accessibility Maturity

Business man in suit walking on a ladder over a large bear trap

Several people pointed me to an article titled “How to Avoid the 24 Perilous Pitfalls of UX Maturity” from Human Factors International. There are a lot of parallels between this article and accessibility maturity with a few deviations. This article is my take on the UX pitfalls identified in the HFI article as applied to accessibility.

Pitfall 1: Lack of Executive Interest

It is almost impossible to create a successful accessibility program without executive support. It doesn’t really matter WHY an executive supports the program. Motivation can include:

1. Sales in 508 organizations
2. Threats of lawsuits in retail, or
3. Because they actually *care* about full inclusion and doing the right thing for people with disabilities.

But the executive support must exist. Trying to run an accessibility program without executive support is the definition of an exercise in futility.

Pitfall #2: Accessibility Investment Errors

Many executives think automated testing and expensive tools are the most important thing to invest in for accessibility programs. While there is a place for these things and it’s an overall part of a comprehensive accessibility solution, it would be a mistake to start with that side of the equation. Ironing out cross-functional processes and responsibilities is far more important, and will have a more lasting impact.

Pitfall #3: No one Wants to Own Accessibility

As I wrote a couple of months ago in Where is the Best Organizational Location for Accessibility, there are many places accessibility can go including compliance, legal, program management, diversity/inclusion, and several locations in IT (design, development, and QA). No matter where the accessibility program goes, it needs to connect with all of those departments. When no one wants to own accessibility, the cross-functional communication does not happen, there is no accountability, and the program is likely to fail.

Pitfall #4: Accessibility is not on Product Roadmaps

Accessibility must be called out on product roadmaps. If accessibility QA and functional QA are performed simultaneously, there is a ton of rework involved that is a waste of resources. Doing accessibility testing too early means there is likely a lot of functional defects still present where either:

• accessibility testing will be blocked by functional issues, or;
• new code will be checked in requiring the accessibility testing to be redone

Pitfall #5: Accessibility Programs that are Missing Parts

It’s not enough for a product, website or mobile app to be accessible.

1. Social media should be accessible
2. The core corporate website should be accessible
3. Training should be accessible
4. Documentation should be accessible
5. Support should be accessible
6. Internal tools to support your accessibility testers with disabilities should be accessible

If an accessibility program is only addressing the product and not these other elements it is not enough for a comprehensive accessibility solution.

Pitfall #6: Lack of a Centralized Accessibility Office

A mature accessibility program must have a centralized accessibility office (CAO). Looking at most accessibility, UI, and UX models, you can’t get past level 3 (i.e. mid-way) without a centralized office. With a centralized office, efforts can be better coordinated and if necessary, a charge-back process can be used to make sure that the costs of accessibility are attributed back to the projects that require the most accessibility resources.

Pitfall #7: Reactive Accessibility

Good product accessibility starts with accessible design. Reactive accessibility programs don’t step in until QA begins and then ping-pongs a bunch of defects back to development to fix in the rest. Proactive programs start with accessible design, preventing the defects from occurring in the first place.

Pitfall #8: Accessibility Theoreticians

Successful accessibility programs are not an entirely theoretical exercise. One can have all the WCAG guidelines memorized, but if you don’t understand how people with cognitive disorders, dyslexia, or vision loss process information, you will create a tool which is nominally accessible but not very usable. Usability is independently important of accessibility, if it is not a usable experience for people without disabilities, it will be a horrible experience for people with disabilities.

I would much rather hire someone who has a basic understanding of how screen reader users utilize headings and what makes good and bad heading content than someone who knows that WCAG 2.4.6 is the heading requirement. For more details on important things to look for in hiring an accessibility tester, please read Hiring an accessibility tester? Here is an approach you should consider and Accessibility interview questions.

Pitfall #9: Accessibility Silos

The “A” in teAm is for Accessibility. Accessibility is best achieved as a team sport, where individual contributions play a backseat role. WCAG is largely regulatory language which is subject to interpretation. Unless the whole team is playing from one accessibility playbook, someone may interpret what constitutes “meaningful information” (for example) in one project silo differently than in another project silo. Accessibility best practices (such as no italics) may be implemented in one tool and not another. This is where consistency goes right out the window. While it is important to have a passionate accessibility leader, a streamlined accessibility program is less about individuals in silos and more about the team as a whole working from the same internal accessible rules.

Pitfall #10: Accessibility Pretenders

People who pretend that they know about accessibility aren’t helping anyone.

• The court in Gomez v. GNC fined GNC severely for claiming that their head of IT was an accessibility expert where he had no specific training or practical experience.
• The DOT fined SAS severely for pretending that two separate websites (one accessible, one not) constituted an equal experience for its customers.

Make sure your staff isn’t pretending by creating robust training programs and having at least some percentage of your staff IAAP certified.

Pitfall #11: Adequate Staffing

Adequate staffing is a huge problem for accessibility programs. With 70 % of testing being manual, all it takes is one late release crashing into an on-time release to throw a program completely off the rails. Not only do you need enough staff, in larger programs you need to plan to be able to surge staff quickly for short projects. This is difficult because of the required qualifications.

Accessibility Marketplace will help address very short term needs for accessibility staffing without forcing companies to go to large expensive consulting companies for longer-term commitments. Crowdsourcing through Applause, Test.io or Digivante (formerly BugFinders.com) who all have robust accessibility practices is another option.

Pitfall #12: Overseas Contributors

Overseas contributors are not a pitfall per-se, but need to be carefully handled. Accessibility requirements primarily come from the EU and the US. It is difficult to find people with EU and US accessibility knowledge where most inexpensive overseas contractors are located in Asia, South America, and Eastern Europe. Training and certification is even more important when an organization is using overseas contributors, because they tend to operate without a lot of timezone overlap with their US counterparts and need the information and authority to make recommendations without the primary staff available to avoid delays. This is where a strong internal document on accessibility implementation and best practices specific to your organization is absolutely essential.

Pitfall #13: “Feel good” Accessibility Programs

Some “accessibility” programs are so understaffed that they are literally only there to make it look like the organization is making some level of effort to create equal access for people with disabilities. This clearly falls under the category of being #Diversish — talking the talk, but not including people with disabilities in any type of meaningful way in corporate programs.

Pitfall #14: UX Personas that don’t have Disabilities

In order to do UX concerning the usability experience for people with disabilities, the group owning user research must have personas with disabilities. This is as simple as adapting an existing set of personas and giving each one of them a common disability. Put Jason, your IT guy, on the autism spectrum. He gets distracted easily by motion, likes simple layouts, and hates bright colors. Give Sandy, your accountant, a broken dominant arm. She won’t be able to use a mouse for 6 weeks while she has a cast on and will mostly be a keyboard and speech user. Then recruit to fill your user interviews matching those personas.

Pitfall #15: Majority of Testers don’t have Disabilities

Like doing UX without disability representation, having testers that are knowledgeable about accessibility but without disabilities isn’t going to give you full representation. I know how to use VoiceOver, for example, but I have the bias of being sighted. I don’t use it the same way a person who relies on VO operation does. Make sure your teams have a good blend of both people with and people without disabilities.

Pitfall #16: Lack of Accessibility Governance

Someone needs to have the authority to stop a release from going public if a pre-agreed to level of accessibility has not been achieved. You might think “oh, that’s easy, that should be the accessibility manager.” However, if the accessibility manager is pulling the emergency brake on a release, that creates resentment against accessibility from people whose bonuses might be based on whether or not a release went out on time. To avoid that type of situation, it is better to have some type of governance council that needs to sign off on a release, where accessibility is one-component of that sign-off.

Pitfall #17: Turnover

In a thriving organization, there will always be staff turnover. Accessibility is no exception. In fact if anything, accessibility-related positions are subject to more turnover than average. The current litigation and regulatory landscape makes accessibility an extremely hot skill to have right now. It has to be self-taught, there isn’t a lot in the way of new grad accessibility knowledge. This in turn makes people with accessibility skills very, very marketable.

Accessibility is very contractor-dependent and agencies will move people with accessibility skills around. It is not uncommon to train someone, and six months later the vendor has moved them to some other contract and you find yourself having to start over. A modularized, role specific accessibility training program is necessary to quickly ramp up new employees and contractors who may come in without the accessibility skills needed to produce accessible products.

Pitfall #18: Keeping Accessibility Skills Current

Accessibility is an ever-evolving topic. New topics include:

• Accessible Blockchain
• Accessibility in VR
• Accessibility and AI.

Standards evolve as well:

• WCAG 2.1 became final last June.
• The EU is updating their standards in December of 2019

Unless your core accessibility staff are keeping up with all the changes, they will quickly fall behind.

Conclusion

Few people (myself included) will get them ALL right. But it’s important to know which potential pitfall areas an accessibility program is not doing well at, so that you can try to improve on them. When improvement is not easily achievable, at least it helps to understand the implications of the pitfalls.

Whether your organization is just starting on its road to accessibility or trying to maximize accessibility maturity, it is always better to learn from other’s costly mistakes that can be easily avoided rather than to learn about them by making them yourself.