ACCESSIBILITY FOR EVERYONE
PLANNING FOR ACCESSIBILITY
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.
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.