Accessibility Debt — What is it? How to pay it off ???

Sometimes, accessibility isn’t important until suddenly it is.

Image for post
Image for post
Cartoon young man kicking a can

The accessibility paradigm shift from “yeah, eventually” to being included as part of “business as usual” usually derives from one of the following occurances:

  1. a lost sales opportunity over lack of accessibility compliance
  2. an EEOC complaint alleging discrimination based on disability
  3. a lawsuit filed over lack of accessibility
  4. Negative impact to brand reputation over a lack of inclusion

At many companies the “accessibility can” has repeatedly been kicked down the road (it’s not important … it’s not important) and then suddenly, it’s the most important thing for your company and your company needs it now. That can result in your accessibility effort getting kicked into overdrive, when it was previously stagnating or non-existent. The steps identified below are one way of accomplishing this.

Image for post
Image for post
National Debt Clock and federal spending information overlayed in front of a government building

“Tech Debt” is the phrase used to describe development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution which might take more effort initially to deploy, but in the long run is the better choice.

Continuing to code and release inaccessible components creates more “accessibility debt”, not less. No one really wants to put code into production where the first thing they have to do after it is released is spend time, effort and money fixing it.

The only way to avoid allowing accessibility debt to grow is to draw a line in the sand.

“As of <date>, all new <designs, code> will be accessible”

  • Some companies that have a formal project kick off process will be able to choose a cut-off date that projects go into intake.
  • Others will have to use other formalized steps such as when project goes into design.
  • The final group will be forced into a date that has been set by regulatory agencies

Even if the end product isn’t fully accessible in the subsequent release, by requiring new features to be accessible, you are getting closer to an overall accessible product. Effort can be expended to remediate the non-compliant older code, while new functionality or code extensions will be accessible because of the line in the sand that is not to be crossed.

If you are an introvert, or suffer from “imposter syndrome”, getting loud about accessibility is going to be hard. It requires putting yourself out there at every opportunity and screaming “Accessibility is more important than customer feature requests!

If you are lucky, you have customers demanding accessibility. But more often than not, the potential customers you are discriminating against are silent. 91 % of people with disabilities reported that they have left a site and gone to a competitors without saying a word because the first site they visited was not accessible to them. This is proof that if you are not accessible, there is likely a whole world of potential customers who voluntarily opt out of becoming your customers, because of the accessibility issues your company has ignored over time. Just because your executive staff hasn’t heard that accessibility is a problem, doesn’t mean that it isn’t a problem. My boss wrote a great article called “Have you talked to your non-customers lately” While it does not directly address accessibility, it outlines a number of very important reasons why people/companies who could be your customers but aren’t are just as important if not more so than people/companies who ARE your customers.

Communicating about accessibility is the most important thing an accessibility manager (or anyone concerned about accessibility or people with disabilities) does. Those communications can be extremely varied and creative including:

  1. Get in front of your executives: Try to convince their executive assistants or chiefs of staff to put you on their calendar. If that doesn’t work, figure out how to corral them privately. When your executives identify what is important for the next Quarter/Year, urge them to include accessibility on that list. When the CEO publicly states something is important, people listen.
  2. Brown Bag lunches: Have informal meetings with people who need to understand accessibility. Designers, developers and program managers should be the target audience here.
  3. Office Hours: Make yourself available (at times friendly to the folks overseas as well, who sometimes need this help even more) to answer any and all accessibility questions.
  4. Newsletters / Articles / Confluence pages: Write as you can on accessibility. Any time you need to stop and take more than 5 minutes to explain something person-to-person, it’s a good idea to jot down some notes as the starting point for an article. Recording your thoughts:
  • benefits everyone, not just the few people around when you were discussing the topic
  • ensures consistent advice — this is especially true if you are making any judgment calls in the advice you are providing.
  • gives you the opportunity to rethink your answer as you are writing your notes — something new might pop into your mind that makes the answer you previously gave more complete

5. Start an accessibility slack channel or some other form of two-way internal design/developer communication. This encourages people to ask their questions in a group where others can answer, or if you are the one answering, where others can read the question and your answer.

6. Actively participate in development, design and UI slack channels—Every time a conversation comes up on one of these slack channels that implicates accessibility, I add my $.02. Should something be modal or non-modal? (the answer from the accessibility perspective is usually modal, if you choose non-modal, help out your screen reader users by letting them know when they’ve dropped back to the underlying page). Does this pop-over look OK? (don’t block the underlying content, and make sure you can get to the data from the keyboard).

7. Get others to include accessibility in their talks / newsletters / articles: Talk to people that you know are doing talks / newsletters / articles and see if you can insinuate accessibility into their work — any time the word diverse, inclusive, bias, or abilities shows up, there should be an explicit mention of disabilities. Until this is completely baked into your company DNA, this can’t possibly get mentioned enough. Because accessibility teams are typically small, you need to leverage the collective knowledge of your team through others to get more mentions. An important place to get accessibility mentioned is in employee orientation. It sets the expectations early on that being inclusive is important to the company.

8. Training: Training. Training. And more training. You need to make it easy (and hopefully fun, or at the least, not boring) for people to learn what they need to know about accessibility to get their jobs done correctly.

9. Demos: Demos. Demos. And more demos. The most effective way to get people to inherently understand the need for accessibility is to show them how assistive technology is used by people with disabilities.

Conclusion

It’s not enough to get accessible, you have to STAY accessible. That is why accessibility is a program and not a project. Employee and contractor turnover are a threat to both getting and staying accessible, and getting as many communications points about accessibility out there is essential to spreading the message of accessibility which will reduce your organization’s accessibility debt.

Written by

Accessibility Architect @ VMware. W3C Silver, ITI & IAAP GLC committees. Degrees in CS, law, business. Wheelchair user w/ a deaf daughter.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store