Accessibility Shouldn’t Be An Afterthought

All too often, it seems a project is released without any thoughts to accessibility, whether it’s a new website, a utility students are being asked to use in the classroom, plans for a building, or some similar public tool or development. It’s clear from the plans and the presentation that no one stopped to think about accessibility for a second during the process of working on the project, even when legal requirements mandate that it be accessible. And the developers are subsequently shocked, just shocked, when disabled people point out the problems and ask that they be fixed. Or, perhaps worse, they thrust their project at a group of disabled people and ask them if there are any problems, effectively demanding that they work as accessibility consultants for free.

Here’s the thing: accessibility should not be an afterthought. It should be integrated right into the planning of any project, especially a project being produced in a social justice or educational setting, and the fact that accessibility is still considered an ‘extra’ is very telling.

From a purely utilitarian standpoint, thinking of accessibility while in development cuts costs. If people are thinking ahead, they can plan it right into the structure of a project and make it easy to implement. Case in point: when Fort Bragg remodeled City Hall, they didn’t bother ramping the front entrance, forcing wheelchair users to go around the back. Disabled people complained, and they were forced to add an expensive and clunky ramp to the front. That problem could have been avoided by thinking about this issue from the start and involving disabled people in the plans for remodeling and developing City Hall.

With web applications, it’s even more critical to think about accessibility early, because it’s possible to build a fully accessible app from the ground up, but it’s a lot harder to go backwards and hack accessibility into an application. In some cases, it might be largely unsalvageable because of the way it’s structured, which means that a lot of money, time, and energy is going to have to go into reworking it and making it function for disabled users. And many accessibility implementations are very simple and easy, serving not just disabled people but other users who might appreciate extra features; take, for example, the large number of people who use text-to-speech functions without being blind or visually impaired.

But I’m not thinking about utilitarian issues here. I’m thinking about the message sent to the disability community when accessibility is not prioritised with other project goals. By not considering accessibility early in development, people are sending a clear message that disabled people are not wanted, and that they aren’t considered viable users of a product. This dismisses a huge chunk of the population who might need or want that product. By telling disabled people that they aren’t valued as users, developers are also telling them that they aren’t valued as human beings; not making something accessible from the start is like hanging a ‘no crips allowed’ sign, and people need to stop being surprised when disabled people read the writing on the wall.

Accessibility should be built into the groundwork because disabled people are part of the community using that product and you want to make it clear that they aren’t just tolerated, not just included, but actively integrated into the product base. That requires actually taking accessibility seriously, rather than tacking it on after the fact.

That means actually hiring an accessibility consultant. Shockingly, not all disabled people know everything there is about disability, and fewer still know about the specific accessibility issues pertaining to various products. I, for example, know some accessibility tricks for websites, but if you were developing an Android app, I wouldn’t be able to help you make it fully accessible for blind users, because I am not familiar with how blind folks navigate Android phones, how they use them, and what kinds of features they want in an app. I also know zilch about app development.

You know who does? An accessibility consultant, who has specific training and experience in these issues along with the development background to root accessibility suggestions in an understanding of the strengths and limitations of the platform.

You would pay a consultant to make sure a project met other standards, and you should pay an accessibility consultant, because accessibility consulting is work. It requires spending time and sometimes money acquiring knowledge, developing it, and maintaining it. Professional development is key because people need to learn about emerging new technologies, how older technologies are supported, and how the disability community is evolving. Professional development also needs to include an understanding of the industry the consultant works in, such as architecture or software development. Your architectural expert, for example, needs to know how buildings are built, what the building code requires, and what you can do to make a building as accessible as possible to the greatest number of users. That costs money, and you shouldn’t expect it for free, or ask for it once the building is finished and people are pointing out the glaring problems with it.

There is a fundamental lack of respect here in the inherent decision to not include disability issues in the planning phases, and then to expect disabled people to pick up the slack for free. Access is a human right, and the onus to protect that right shouldn’t be on the community that is struggling to survive in a hostile world. It should be on the community that routinely infringes upon that right, making it difficult for disabled people to navigate the world.

Don’t make accessibility an afterthought: make it a key component of your project planning.