Accessibility Wednesday

In the fall of 2018, I had the good pleasure of attending the Connect.Tech conference in Atlanta, GA. There were great talks about React, user experience design, and exciting new features for JavaScript.

But the sessions that had the greatest impact on me were all focused on accessibility.

Accessibility is important

It might seem obvious to you, but I needed to hear that loudly proclaimed from the keynote stage.

Accessibility isn’t just about our friends and neighbors with disabilities; it’s about making applications that work well for everyone. The Curb Cut Effect is a perfect example about how accommodations make everyone’s lives easier.

I was treating accessibility as if it was icing on a cake—something that was nice to have but not essential. Unfortunately, it was that type of thinking that allows inaccessible apps to flourish.

Accessibility is not a feature; it’s part of the product. If our app isn’t accessible, then it isn’t done.

“Whoa, what was I doing before?”

Hearing all that was like a light switch being flipped in my mind—and with that came loads of guilt and regret for all the neighbors I had neglected for the decade I had been developing. I felt especially convicted by my experiences in my previous career.

Before becoming a developer, I studied education in college and spent three years working as a teacher. The importance of creating an inclusive environment and the value of accommodations was drilled into us early on, and we studied how great accommodations increase learning outcomes for all students.

Further yet, I had seen those benefits first hand while working in over a dozen schools across Pennsylvania and Georgia.

If accessibility was so important to my previous career, why wouldn’t it be the same in my new one as a developer?

“Okay… now what?”

Impressed with a sudden desire to make all the things accessible, I left the conference and looked online for resources to help.

I first tried to read the Web Content Accessibility Guidelines 2.1, which weren’t as difficult to grasp as I had feared. Even so, the content was dense and a tough slog for a newbie.

Seeking more digestible information, I found other resources on W3C to be helpful, especially those specifically for developers.

I was working with React Native at the time, so I created Awesome React Native Accessibility, a repo with a list of mobile-specific resources. Progress on that halted when I switched to a React project at work.

At this point, I was starting to feel a little overwhelmed. Everywhere I looked were categories, rules, laws, practices, and oodles of examples of companies doing it wrong. It all seemed like too much.

Accessibility is hard

I was beginning to think that maybe accessibility was too difficult, too technical, too intricate for me. And I’m sure that I am not alone in having thought that.

But the reality is that developing for accessibility is a skill. And just like any other skill, it requires little bites and regular practice. Over time you will improve, and eventually what seemed difficult will become second nature.

There is a reason we don’t learn to walk by running. Our brains weren’t designed to work that way. As the father of a now-cruising baby, I feel particularly qualified to say that learning to walk is hard work. It’s filled with failures, bumps, and bruises. Same with riding a bike, learning to read, or adjusting to a AAC device.

You will fail at first (and second and third), but as long as you persevere, you can be successful. You can learn. You can grow.

Let’s learn about accessibility

I am determined: I want to become an accessible developer. I want to bake accessibility in for as many neighbors as possible into every application on which I work.

In order to meet that goal, I need to learn more about accessibility. And that’s where this article comes in. This is the kick-off to a series called “Accessibility Wednesday” where I will share accessibility tid-bits for developers.

These won’t be full articles—neither you nor I have time for that. Rather, I’ll share images, links, and code samples on Twitter with the hashtag #a11ywednesday. Everything will be available in a GitHub repo for easy reference.

Remember: I’m no expert (yet)

Since I am not an authoritative resource on accessibility, I will make sure to include references and citations to every applicable tidbit. Is MLA formatting still a thing? (s/o PurdueOWL)

This is a learning exercise for me as much as it is for everyone else. With that in mind, I will almost certainly make mistakes. All of us fall short of the target. That’s why I encourage you to help me correct my mistakes.

File an issue on GitHub referencing the tip in question, or—better yet—make a pull request with the fix. I happily welcome any and all contributions the the project.

If you notice the mistake on Twitter, please respond or direct message to let me know. I will remove the tweet, make the correction, and share the updated information later.

Stronger together

As time goes on, I’m hoping that Accessibility Wednesday grows into a catalog of useful information for developers of all levels to make more accessible applications. We know that there is power in our collective knowledge.

As a wise man once penned, “with great power there must also come—great responsibility!”¹ Let’s use our power for good and make the web more accessible for everyone.

Join the discussion on Twitter or GitHub. I look forward to learning and sharing with you all!