Planning for Accessibility: Accessibility for Everyone: Long Form Book Review

Continuing on, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

PLANNING FOR ACCESSIBILITY

One of the scariest propositions is to be told that Accessibility is now a prime focus of your work, and your product needs to be retrofitted to be accessible. Still, that's a reality a lot of products share. To make a product truly accessible after the fact almost always requires some focus and attention (by way of example, my current company did an Accessibility audit five years ago, and the resulting work required to fix the issues found took fifty stories to complete). Designing with Accessibility in mind from the start makes things easier, but you will likely have to do some convincing. To do that, focus on the ability to navigate your site as easily as possible, make the point that it will give your product a competitive edge in the market, explain that having an accessible design will likely lower your support costs because an Accessible design would help overall UX, and it will help protect you from being sued.

The next step, of course, is to make sure that you have the right people on the team to do the work. You don't have to have Accessibility experts on your engineering teams, but you will have to come to grips with the fact that Accessibility is more than just checking off requirements in WCAG. Accessibility is best addressed when the whole company gets onboard with the approach and designs with Accessibility in mind from the beginning. Those skills take time to master and they may well be slow going for awhile. Laura does right by addressing this. Yes, a programmer can learn about the various tag structures and can create automated tests to verify they exist. That's a good start, but if we are not actively making sure we are making products that are genuinely useful to those who most need it, we're missing the point.

Using my own project as an example, we started out with a list of things to fix. We devoted two engineers and one tester (me) to see the changes through. Over time, we grew to understand what the changes would actually entail, and that it was not going to be an easy or quick fix. The resulting story work took the better part of a year to complete and we all learned a lot in the resulting year, both in the way of what the code needed and what to test for. Fact is, this was driven by a large client that was willing to buy a lot of software from us, so it was very much worth it to us to do the work. For organizations without that immediate incentive, it may be harder to convince people of the need. If you know the resulting revenue will outweigh the development costs, it's easier to go in and do what you need to. If the payoff seems distant or completely nebulous, it's a harder proposition to sell. This is where research comes in, and research means getting real users with real issues and real pain points to talk with you or share their experiences, or for you to recreate those experiences. It may be impossible to delve into every possible option, but even getting just a few different people's perspectives can tell you a lot. However, it is important to realize that, while you can get a lot of insight from a few people, it would be unwise to base all of your decisions on just those few people. Just as any one person will not be truly representative of a whole population, individuals with disabilities are just that, individuals. They can provide insights, but they will not provide all of the insights you may need.

Once you have determined the scope of the work, you will need to prepare for testing using tools that will help you accomplish your goals. get familiar with the Accessibility settings on your various systems. Use the screen readers that are available. Use the applications that are voice-driven and spend time getting good at using them. Many technologies that are available will be free or cost very little to implement. Some will cost more, especially physical devices.

Perhaps the most important things to realize is that Accessibility is not a one-off project. Once you determine that you are going t make Accessibility apriority, it becomes a part of your overall design process. That means that each and every story being developed needs to have an Accessibility discussion and ways to verify that you are designing for that purpose and testing to see that the purpose is being met.

KEY TAKEAWAY

Laura spells out the reality of making Accessibility a priority, and she uses a number of additional resources to support why this is important (want to know what those are? buy the book ;) ). Already, I can appreciate that, early on, Laura is pointing out that Accessibility is equal parts good design, solid engineering and quality practices, and continued advocacy that will go on long after the major heavy lifting to implement Accessibility has been completed. Without continually revisiting Accessibility standards, and making it a core part of your development and quality philosophy, you may find yourself having to rework many parts of your code again later.