Radical Candor about Accessibility Day-to-day Job Responsibilities

Some days you get to tilt windmills, some days the windmills tilt you

So far in the category of “accessibility as a career”, I’ve written articles about:

Self-study tips for qualifying to work in accessibility
Questions managers should be asking if they are interviewing accessibility testers (and don’t know a lot about accessibility themselves), and
Questions you should be asking if you are interviewing for an accessibility job.

So I’m turning the trio into a quartet by discussing what exactly an accessibility manager does day-to-day — in fairly blunt terms.

You spend a lot of time attending meetings trying to convince people to do things that aren’t even close to the top of their priority list

Accessibility is rarely at the top of most product manager’s MVP list. BF Skinner proved that behavior that is rewarded gets repeated. The opposite is also true — what is not rewarded usually drops to the bottom of most individuals’ “what I think is important” list. Accessibility is a behavior that is not frequently rewarded on the product side of the house. This part of the accessibility management job is literally like a continuous tug of war where you start by:

Telling people it’s the right thing to do.
If that doesn’t work, moving on to the fact that making software accessible is a good business decision.
And finally, if necessary, bringing in the nuclear argument which is “if you don’t do this, you are going to get sued.” In some situations the nuclear argument also includes “we can’t sell to the government unless we make the products we sell accessible”. Either of these arguments may involve dragging in corporate attorneys which is never fun.

Lather, rinse, and repeat this process with all impacted groups in your company.

It isn’t enough for the product to be accessible. Support functions, corporate websites, marketing material, documentation, training, surveys, and all third-party components have to be accessible as well for the end-to-end experience to be completely independently navigable by a person with a disability.

And perhaps doing the same for employee-facing tools

The first point above only addresses the customer side of the equation. Most companies start with that since the public is more likely to sue them than employees. If you are tasked with (or want to take on) employee related accessibility, procurement and IT are other departments to add to that list. Employee-facing tools are typically more inaccessible than anything customer-facing. Your employer has leverage over who it buys from because it can always buy from someone else. Ask yourself and your co-workers the following questions:

What does having completely inaccessible employee-facing tools say about the company’s true intent towards inclusion?
Is your D&I program in with both feet or #Diversish?
What does allowing inaccessible tool procurement say about the company’s commitment to employing people with disabilities?
Why would a company treat employees (or potential employees) with disabilities with less respect than the members of the public it has zero relationship with?

More than 50 years ago, Eldridge Cleaver said “ There is no more neutrality in the world. You either have to be part of the solution, or you’re going to be part of the problem.” (frequently paraphrased as “If you aren’t part of the solution you are part of the problem”). People with disabilities cannot be fully, independently successful in any employment setting unless the tools they are given are completely accessible. The problem is that the unemployment rate for people with disabilities is 250 % higher than people without disabilities. At least part of the solution is making internal tools accessible.

Once you convince people to make something accessible, the next fight is getting it on the roadmap

Getting accessibility on the roadmap and keeping it there is the next thing I spend a lot of time on. There are two accessibility approaches once the product owners are on board:

Reactive accessibility, which is basically taking an inaccessible product and retrofitting accessibility in. This approach is more expensive, less effective, and more likely to result in schedule delays.
Proactive accessibility, which is designing and implementing the product with accessibility in mind. This is the preferred approach.

Sometimes there is no choice but to be reactive, but proactive is always the better option. Proactive accessibility is better, faster, and cheaper. In either case, you need to make sure that enough time is allocated to account for accessibility, including fixing bugs. The younger the accessibility program, the more time you will need to allocate to fixing bugs. You also need to make sure that when things start running late and schedules are crashed, that accessibility isn’t deleted or made parallel with some other effort (such as functional QA) that renders the results useless.

Implementing automated testing

Many executives that own accessibility want to start with this item first, because they think automated accessibility testing will solve all of their accessibility problems. What they don’t realize is that only 30 % of the accessibility guidelines can be tested through some type of code analysis tool. So this is definitely not a “one and done” type of process. Automated tests are good for smoke testing and preventing some regressions since you can get results quickly through automated testing. It is relatively straight forward to implement an accessibility module into an already existing automated testing program. For bonus points, you will want your automated test suite to report in a format that can be easily uploaded into your defect tracking system after confirmed. Otherwise, someone will be stuck with logging all those tickets manually.

You will need to find people to help you

It is really really hard to find accessibility professionals that are both qualified AND reasonably priced (especially in the SF Bay Area). As discussed in the self-study tips article, this is not a topic that comes up in most standardized CS or UI college-level courses, though more bootcamp-like programs (General Assembly is one) are starting to add accessibility to their curricula. Though it is appearing more frequently, accessibility is included in perhaps 1–2 % of college CS programs. Even when accessibility courses are available, they are rarely required. This seems a little shortsighted given the new focus on accessibility in the public sector and lawsuits. Colleges who want to improve their percentage of employed graduates really should really get with the accessibility program because it makes their students much more employable.

Because of the scarcity of reasonably-priced full-time resources, you will likely at least in part be forced to look at contingent workers in accessibility consultancies to support your testing effort. This is especially true for larger companies who have larger testing requirements.

And that means negotiating your company’s vendor on-boarding and purchase order process

While this may be easy to do at smaller companies, pushing through new vendors and purchase orders at large companies and then managing those projects once approved can be a Herculean task in and of itself.

You may have a sourcing department who wants to provide input into your vendor selection process, while understanding absolutely nothing about the topic of accessibility or the current state of the market.
Non-disclosure agreements are always recommended, because you don’t want conversations about your corporate inaccessibility to be easily discoverable by plaintiff’s lawyers.
Projects need to be scoped, which requires writing very detailed statements of work.
The work has to be supervised, and invoices have to be reviewed.
The results generated through outside testing need to get looped back into your defect tracking system and prioritized for remediation.

Centralized accessibility budget or cross-charging?

Once question that comes up when establishing vendor relationships and drafting statements of work is “which department is paying for this work?” If you came into a fully-functioning accessibility program, that may already be determined for you. But if you came into an ineffective program (not doing enough, therefore probably didn’t budget enough) or are establishing a new program, finding a budget to charge is going to be a problem. Centralized budgets are easier to deal with, but some companies insist on cross-charging back to the departments that the work is being done for. Which unfortunately makes the first step (convincing the product teams to do it) even harder.

Training internal folks

You can’t rely 100 % on contingent workforces. Training internal people in the following areas is important:

Accessibility history, theory, and basics
How to do very basic screen reader, keyboard, or magnification testing
Color analysis for designers
Accessibility programming techniques for web, native iOS, and native android (whichever is relevant for the programmer in question)
How to interpret the results of automated tests
When to bring in the accessibility team for help

Partners typically need training too

Most companies have at least one third-party product integrated into something that they need to make accessible. Some have several. This includes things like chat systems, search optimization, ad providers, surveys, maps, news feeds, loyalty programs, business portals and processing credit card transactions just to name a few. Some of these partners are too small for the ADA to apply to directly. But as soon as they contract to work with a company the ADA does apply to, that company’s obligations under the ADA are imputed to the small partner. To look at it in reverse, if they screw up, the large company may be the one who gets sued. Yeah, the large company might be able to get any damages back from the small partner, but that doesn’t reverse brand damage, isn’t guaranteed and is a time-consuming headache. By providing the same training to partners that you provide to internal employees, you reduce the chances of something bad happening from partners delivering inaccessible goods and services.

Growth by acquisition can be a necessary headache

Like the issue with partners above, if your company is large and grows in part by acquiring other smaller startups, accessibility laws that the other company may have been able to ignore now come roaring into force. It is good to consider this question during the merger and acquisition process and prepare to put together a plan for achieving full accessibility as soon as is practical.

Timezone differences will kick your ass

India and China are common locations for many of the more cost-effective contingent accessibility testing resources. In addition, the developers you may be working with could be located in all kinds of far away places. It is fairly common for me to have a 7 am call in Eastern Europe, do my regular job in the Pacific timezone (frequently involving early calls in Boston and Atlanta and occasionally a 4 pm call to Australia), followed by a 9 pm call with folks in India. I also frequently do calls with India on Sunday nights Pacific time (Monday morning in India and Australia) to get their work week off to the right start without blocking out time during my work week.

To make all of this work, a good communications plan is essential

Accessibility managers typically need both internal and external communications plans.You can’t spread your accessibility message alone, especially across a large company. You need to leverage existing communications channels and create accessibility champions in every department possible. Items in your accessibility communications plan can include:

Office hours
Intake process
Confluence Pages
Accessibility newsletters
Accessibility talks at internal meetings/conferences
External accessibility conferences

Another powerful communications tool is an accessibility Slack channel. This will allow anyone at your company to ask an accessibility question at any time and for all members of the channel to see the answer. Slack itself is accessible, FTW (see my section above about choosing accessible employee-facing tools).

And sometimes you actually get to test stuff …

Periodically I will get to dust the rust off of my VoiceOver or magnification user skills and actually test something. I am a keyboard-only user, so I live that live just like I breathe. Being able to quickly whip out your phone and demonstrate to someone why something is such a terrible experience is a very powerful tool. Always add “why” or “how” to the rules when explaining them — why is alt-text important? How do people who can’t see use headers to navigate.

So why bother?

This is one of the rare jobs in tech where if you are successful, you can go to sleep satisfied with the knowledge that you probably improved someone’s life somewhere. Most accessibility managers go into this field because it has some sort of personal meaning for them. That means despite some of the drawbacks I’ve identified above, they get to do something that they love every day, which makes it feel less like work.

Accessibility is a great career if you have the internal fortitude to be regularly practicing which can at best be euphemistically refer to as “professional courage”. I was sort of joking about the Dona Quixote theme at the top but not really. In some organizations, executives only want to do what is minimally required to avoid lawsuits and achieve compliance. The best places to work are where WCAG 2.1 is a floor, and you can explore things like how personalization benefits people with disabilities and do real user research with customers with disabilities to improve the experience, not just make it accessible.

Thanks to Scott Mathis for the idea for the title of this article.