Stop me if you've heard this one before: "We're putting accessibility (features) on the roadmap." Or this one: "We don't need to make it accessible since we don't have any blind users ¹ ."

It belies an attitude that's all too common in the software industry: That accessibility is something you can build once and be done with. That it's an extra feature, not something core to a product. That it's optional, a business decision, to make your product accessible.

Just as with security, this is a misunderstanding of the nature of accessibility. Security is something you have to always think about, and always work on; you are never "done". And the same with accessibility.

Learning firsthand about accessibility

For most of my life, I had not needed accessibility tech ² . I could use products on the "happy path" of good mobility, vision, and hearing. Almost everything was accessible to me, because I had the abilities that designers expected of users.

Then my arms and hands failed me. In the summer and fall of 2022, I developed nerve pain in my arms. If I typed for more than a couple of sentences, I would get this strong pain in one of my arms and hands, and I always had weird nerve sensations. I didn't recognize what it was at first, because it first felt like I'd just scraped the skin. The pain developed fairly quickly: my arm felt funny on a walk with the kids, then in the evening I was typing and it hurt, and by the morning I couldn't drive because the steering wheel vibrations were intensely painful.

I'm a software engineer, so typing has always been core to my ability to do my job. I had previously said that my hands were my most valuable body part, probably after my brain. So when I was unable to type, I was pretty scared. What would happen to me, and my family, if I couldn't type and couldn't do my job?

Enter: accessibility. I invested in learning to use Talon so that I could write code again, write Slack messages again. It was slow, it interfered with my thinking since it wasn't natural, but it was so empowering to be able to produce something without physical pain.

For a little while it was just the one arm, but when the second one developed pain as well I could no longer use my mouse without pain. Now I would have to use the keyboard to navigate everything. I'm about to find out firsthand just how inconsistent accessibility is. Some software worked very well for me, including terminals and our own product. Other software, like a well-known issue tracker, was all but unusable without a mouse and required very different workflows to work around it. Most software was somewhere in the middle, with a lot working but some commonly used features just failing; I still don't know how to go back and edit a specific message in Slack without a keyboard, only the most recent one.

Accessibility affects everyone

I'm not alone in my brush with accessibility. If you've ever broken an arm or a leg, you know how hard it can be to interact with the world with limited mobility. If you've lost your glasses and stumbled around at dawn on the running trail ³ , you know vision impairment can make everything harder to use.

There are plenty of statistics out there on how many people are disabled, and how many will be temporarily disabled. That's there, a search away. Right here, though, is an argument from our humanity.

We all go through life with a tenuous relationship with our abilities. As my loss (and regaining) of typing ability showed me, we can lose some of our abilities on a moment's notice, and this loss can be temporary. Each of us may become disabled at any point in the future, without warning. Sometimes it's temporary; sometimes it's permanent.

Accessibility isn't optional

"People with disabilities" isn't a demographic you can choose to ignore. In many ways, it's not a demographic ⁴ , but a shifting subset of the population. But if you do choose to ignore people with disabilities, you're hurting everyone.

If you think you don't have users with disabilities, you... might be right, in the worst way. Your software might be so inaccessible that users with any sort of disability cannot use it. That was nearly my experience with an issue tracker; it was almost impossible to use, I had people move issues for me sometimes. But that doesn't mean that no one with a disability tries to, wants to, or should be able to use your software.

There's a famous story about planes in World War II where we were armoring the wrong parts of them. We were seeing only the ones that survived, so we assumed that where there weren't bullet holes, we didn't need to add armor. But that's exactly where we needed more armor, because a hit in that area would down the plane entirely.

This is the same situation in software. If you're looking at the population as a whole and a particular segment of it is not represented in your userbase, it might be your fault. It means that something about your software isn't working for those people. If you have no users with disabilities, then... they probably can't use your software if they wanted to.

It's kind of silly to say "we have no blind users, so we don't need to make the software screen-reader friendly." If you never do the work, they'll never be able to use it.

On top of all this, accessibility is required by law for a great deal of software. I'm not a lawyer, so that's just about where I'll leave it, but be aware that in the US and other countries, you may be open to lawsuits if you don't make your software reasonable accessible.

A requirement, not a feature

Accessibility is something that may affect each of us. We have brushes with it throughout our lives. And it's something that isn't optional.

It's not something we can put on our roadmaps once and be done with. It demands continued effort throughout the entire process of software development, just as with security and performance. Accessibility is something you work on throughout the life cycle of your product.

Don't get me wrong, accessibility can have features. There are sometimes features you can add to make software much more accessible in particular ways. Just, accessibility as a whole isn't a feature, but a requirement for development. It's part of each feature you work on.

Making a feature accessible is just one of many aspects of the work to complete a feature. You have to make that feature secure, and performant, and accessble. It's not something you can delay or choose not to do; it's something you must do as part of routine development.

If you want to do the right thing, make sure you add accessibility requirements as part of the completion criteria for things you work on.