Ten Behaviors that Require no Talent

Being on Time / Being Prepared

Timing and preparation are a huge components in being successful at accessibility. If you start your accessibility work at the design stage, you are only slightly late. All of your project independent accessibility preparation such as:

• Strategy
• Process
• Tools
• Training

should begin even before your start your first accessibility test or design cycle. This is why it is so difficult to start an accessibility program when there is already a lot of inaccessible software that has been released. It really is like running two separate accessibility programs. The first accessibility program focuses on remediating the inaccessible software. Simultaneously, the second program is trying to prevent releasing any new software (or new features in old software) that are inaccessible, which would increase the accessibility debt that has to be dealt with by program #1.

Work Ethic

The reward for a good accessibility program is… accessible software ! For companies that come under Section 508 or EN 301 549, the reward is also the ability to sell that software to the public sector. I don’t know many accessibility managers who care much about sales (except to the extent that they are necessary to keep the accessibility program running). I do know MANY accessibility managers who care about the impact their work has on the social integration, equal opportunities, and employment improvement chances available to People with Disabilities. Being able to improve one person’s life is the reward.

Effort / Energy / Doing Extra

Accessibility is not a low effort career.

• You will spend a lot of time justifying why your work should take priority to people who sometimes couldn’t care less.
• You will never get all of the resources you need.
• Your project never finishes. Any time your software is fully accessible, you are one misguided update (code or content) away from returning to inaccessibility.

There is always room to do extra in accessibility, especially in the testing component. Test on an extra browser, an extra OS version, an extra screen reader, or other piece of assistive technology.

Body Language

When you go into accessibility, the first thing you should do is take EVERYTHING you have ever been told or learned about body language and forget it. People who are blind, have significant vision loss, or who are on the spectrum frequently do not make eye contact that would be considered appropriate by ableds. People in pain grimace involuntarily. People with hearing loss may encroach one’s personal space in order to better perceive speech. If I shift my body position in my wheelchair, it is just as much likely to be to avoid a pressure point as it is to be mirroring your position. Accessibility as a career attracts people with disabilities, and you need to understand what’s normal for them, not apply what’s considered normal for everyone else TO them.

Attitude / Passion

I’m super partial to the late Stella Young’s quote on attitude and disabilities. From her TED talk titled “I’m not your inspiration, thank you very much,” Stella said:

The reason the saying ‘the only disability in life is a bad attitude” is BS is because it’s not true. No amount of smiling at a flight of stairs has ever made it turn into a ramp… No amount of standing in the middle of a book shop and radiating a positive attitude is going to turn all those books into Braille.

Some of my best accessibility and disability advocacy work has been done because I’m mad, bordering on raging anger. Some people consider that state of mind a “bad attitude” because I’m not looking at a problem radiating sunshine. What I am doing is looking at a problem cursing the idiots that decided that it was OK to discriminate against 18 % of the population. That anger drives my passion to not only fix the problem, but educate the people involved in creating the problem in the first place to make sure it never happens again.

Being Coachable

Accessibility is the ultimate project for two-way coaching — coaching designers, product managers, and developers to create accessible software, and being coached by others about what they want the software to be like and why. While there are accessibility guidelines, there is a ton of discretion and flexibility on how those guidelines should be implemented. For example, WCAG 2.2.2 states that a pause, stop, or hide mechanism is required when certain conditions occur. Nowhere does the guideline say:

• Which one of the three (pause, stop, hide) should be used
• What type of mechanism it should be (button? toggle? slider? gesture? keyboard shortcut? All of the above?)

This is where input from others is essential. No accessibility manager can say “it has to be a button, dammit” because the guidelines don’t support that declaration. Sometimes companies have very fixed ideas about what they want their software to appear like visually. It is a good accessibility manager’s job to take that vision and make that work in an accessible manner, not rewrite the vision citing the accessibility guidelines, when the accessibility guidelines don’t support their stance.