In a previous article, I highlighted activities that I think help people become good (or better) accessibility managers through improving their objective accessibility knowledge. While the activities identified in that article will provide individuals with a baseline of objective accessibility knowledge, it’s the behavior patterns applied with that knowledge will make or break the success of your accessibility program. Here are eight behavior elements that I think are important for an accessibility program to achieve greatness.
Behavior Element #1: Recognize that you don’t know everything
You might have a disability, you might not. Even if you do have a disability a) you don’t have every disability possible and b) you may not use assistive technology to accommodate your disability the same way anyone else with the identical disability does. Good accessibility solutions do not create an accessible experience for one group of people with disabilities at the expense of a different group. Get many opinions from others both within and outside of your company and incorporate them into your final approach to achieve new and more accessible solutions.
Behavior Element #2: Set your accessibility destination before you get too far into the trip
Set your standard first before you get into the accessibility program implementation weeds. Are you going to go for 2.1? 2.0? Level AA, Level AA + some AAA, are you going to throw in some best practices as well? Everyone has a pet peeve about something they think is important for an accessible experience that WCAG left out that can be brought in as a best practice. You need to know what you are going to consider an “accessibility success” (in the agile world we call this DoD or Definition of Done) even if you don’t quite know how you are going to get there yet.
Behavior Element #3: Adopt a process improvement program mindset
Accessibility is not a project. It doesn’t come to an end. And even when you get it right, you can always do it better. And even if you think you are doing it perfectly, there will be a new browser, or operating system, or piece of assistive technology, or product feature to test the following week. The best accessibility is done in a continuous process improvement program loop, being visited and revisited throughout the entire design and development process. This continuous accessibility reassessment will make it easier to determine what the low hanging fruit is that can benefit from more accessibility love in your organization.
Behavior Element #4: Eat the elephant one spoonful at a time
It is easy to get overwhelmed when you think about all the things accessibility touches that you need to influence to cohesively achieve accessibility excellence. Breaking the accessibility universe down into smaller galaxies and solar systems can help with that. By following this guideline, accessibility issues can be considered and addressed at a smaller level. Small accessibility victories can be built on to get to the bigger stuff done.
Behavior Element #5: Build cross-functional respect
Accessibility is highly cross-functional in nature. It is important understand the needs and constraints of the other teams that you will need to influence. At a large company this could include everyone on the design / development side of the world (including but not limited to Design, UX, Dev, Research, QA, and Release) as well as Customer Support, Training, Legal and Procurement. Everyone brings unique skillsets to the table. It is important to build a solid foundation of trust and respect with each of these departments, so they can preach the gospel of accessibility for you when you aren’t there.
Behavior Element #6: Always look through your user lens
This one may go without saying, but, it is rare to deliver an experience that makes users happy if you don’t involve the users in the first place. This is typically done through focus groups and user interviews. Having information about your user population and their accessibility needs helps. This data will give you more insight into the types of assistive technology that your customers utilize. If you don’t have analytics, try to get some. For example, if you discover that your users with disabilities don’t use IE, you can decide to take those testing resources and reallocate them to things that your users do consider important. Use the WebAIM surveys for general population demographics for users with vision loss if you don’t have that information specifically for your web site visitors.
Behavior Element #7: Run accessibility tests independent of functional test cycles
It is important that accessibility testing cycles and functional testing cycles be independent and not overlap significantly. The reason for this is two-fold:
1) If there are significant functional defects, progress in accessibility testing will be slow and painstaking (assuming it can be done at all)
2) Accessibility testing will have to be repeated once the major functional defects have been resolved because the fixes to the defects likely touch the code that you’ve already tested.
Also, functional QA engineers generally do not have assistive technology experience and thus are not qualified to perform accessibility testing.
Behavior Element #8: Innovative solutions are not only OK, they are desired
WCAG does not mandate approaches to accessibility. For example, WCAG does not require alt-text, even though many people think it does. What WCAG does require is text equivalents for non-decorative graphics. How that is implemented is up to you ! Text equivalents can take the form of alt-text, long-desc, visual text next to pictures, or text files containing more complicated descriptions. Iterate on your accessibility solutions. If one thing doesn’t work, try something else. Don’t fall into the “we’ve never done it this way” trap.
Accessibility is more than a set of guidelines about WCAG and ARIA combined with assistive technology. Good business sense requires that the set of guidelines be implemented with positive behavior patterns that make accessibility not just something that is tacked onto the end of the SDLC, but thought about from the beginning by all segments of the company that can influence its implementation.