My Journey with Web Accessibility
Preface
Before we begin, I want to make it clear that this post is not a tutorial on how to make your website accessible. There are plenty of great resources out there that can help you get started and I have a lot of my content planned. Instead, this post is a reflection of my journey with web accessibility.
The Early Days
For most of my career, I thought I was already dotting my I's and crossing my T's when it came to accessibility. I was blissfully unaware of the many nuances and complexities of the field and thought that if I stuck to best practices and used the right tools, I was doing my part to make the web a better place for everyone.
I was wrong.
Don't get me wrong. It was better than it could have been. I was using some semantic HTML, all of my images had alt tags, I made sure to test in Lighthouse before shipping, and I even used a screen reader from time to time. But I was missing the bigger picture. I was missing the point.
First Accessibility Project
My first accessibility project came as an agency developer assisting in the overhaul of two large websites for a pair of hotels in Arizona. We had one team member already on the scene, James, who was not an accessibility engineer by title but was the first engineer I met who was passionate about accessibility. He was the one who brought me on board to help out with the project.
I grabbed Google Lighthouse and went to work. The site as a whole was scoring in the low 40s for accessibility, we had our work cut out for us. So I began to race around fixing the low-hanging fruit, although oblivious to the fact of how long-hanging it was. By the end of the day, I submitted a PR that brought every page up to a score of 90 in Lighthouse. I thought I had saved the day.
A little bit later, James replied:
Did you test this with a screen reader? It sounds like spaghetti
I was confused. I had done everything I was supposed to do. I had followed the best practices. I used the right tools. To make a long story short, James spent the next month and some change mentoring me, teaching me about why semantic HTML is important, how to test with a screen reader, and the vast amount of assistive software and hardware out there.
James, if you are reading this, I appreciate you. Without even realizing it, you changed the entire tide of my career.
First-Hand Accessibility Challenges
The transition from "that guy who does a little bit of accessibility" to "accessibility engineer" began with an unexpected gym injury. In some way or another, I managed to develop cubital tunnel syndrome affecting the ulnar nerve in my elbow. You probably know this nerve by its nickname "the funny bone". The result was that I had to have surgery to relieve the pressure on the nerve and restore sensation to my ring and pinky finger.
If this sounds familiar, it may be because Josh W. Comeau had the same problem and wrote a blog post about how he adapted his workflow to continue coding while recovering. Josh also took the time to give me some pointers on how to remain productive as I navigated how I would continue to work without the use of my left arm for 4-6 weeks. He's a great guy and you should subscribe to his RSS feed.
I was fortunate enough to have a great team and a great manager who were willing to work with me, but I began to quickly realize how difficult it was to navigate the web with only one hand. Not only did the majority of the internet seem to assume I had two completely working hands, but without the muscle memory of typing that was built on having both hands, it was faster to use an on-screen keyboard!
This started to instill a much deeper understanding of the importance of accessibility. I was no longer just making the web a better place for other people, I was making it a better place for myself.
The Journey Continues: Hurricane Ida
On August 29th, 2021, Hurricane Ida made landfall in Louisiana as a Category 4 hurricane. It was the second most destructive storm that had ever made landfall in Louisiana in nearly 120 years of tracking.
We are no strangers to hurricanes here in Louisiana, but we are sometimes guilty of becoming complacent when it comes to preparing for them because most are relatively minor. In 31 years of living here, this was the first time I was displaced from my home. My neighbors and I had to take to the streets with chainsaws and cut our way out to society to evacuate. We were fortunate enough to have a place to go, but this resulted in me utilizing a Verizon hotspot that throttled down to 10-12kbs after 15GB of usage to try to work.
Many of the people who read this article probably weren't alive when the internet was that slow.
While network speed is not typically under the umbrella of accessibility, I found myself in a very upsetting position. I couldn't effectively do my job despite my best efforts and intentions, I had to wait for cellular service to return to my area before I could even check on friends and family, and I couldn't access my bank account or my utility company's outage map to plan my return home.
So while not typically an accessibility concern, it led me to the heartbreaking realization that many people live this way every day. Because they were left out without a seat at the table, the internet at large has become a place that they cannot access and inherently just does not work for them. This is when I decided to go all in on my accessibility studies and do everything I can to help as many of these people as I can.
Learnings and Takeaways
In the two years since that first unofficial project as an accessibility engineer, I've seen a profound amount of success and growth. I've had the opportunity to work with some extremely talented people, help a lot of companies become more inclusive and accessible in their online presence, and even teach a few webinars on accessibility. But it was not without its fair share of failures and setbacks.
My company, Vincit USA, has a culture around failure. We call it 'failing in public' and turn a failure into an opportunity to grow and improve. So rather than simply sharing things that I've learned like new techniques, patterns, or tools, I want to share the things I learned from failing.
Accessibility is a Process, Not a Destination
When starting, it's easy to become obsessed with the idea of being done. You see accessibility as a singular destination and once you get there, you are done.
But the reality is that there is no finish line. The number of diverse and nuanced abilities and disabilities coupled with the sheer vastness of accessibility software and hardware, the potential combinations are effectively infinite. I had to learn to keep channels of communication open, do the best that I can given my experience and constraints at the time, but always have one eye out for improvements and Learning new approaches and patterns.
Nothing is ever 100% accessible, and we must always be on the lookout to hone our edge and improve.
Avoid Assumptions When Possible and Always Question Assumptions When Not
As an able-bodied person, it's easy to make assumptions about how people with disabilities use the web. When getting started, I found myself trying to guess how the experience I was going to build would be received by users. I found that in more cases than not, I was wrong.
To give a single specific example, when I was learning to use a screen reader, the experience was very noisy and disorienting for me. Even now with a good deal more experience, I still sometimes find myself experiencing sensory overload. I assumed this was the case for everyone that uses a screen reader, and I often spent far too much energy trying to 'reduce' the noise.
Aiming to have a good signal-to-noise ratio is good for everyone, but I failed to understand that screen reader users are not only comfortable and used to the experience, but also listened to the feedback from the screen reader several magnitudes faster than I was.
We sometimes have to make an assumption, but always be ready to question that and pivot when necessary.
It's Not Just About the Code
As developers, we tend to focus on the code. We want to write the best code we can, and we want to write it as fast as we can. As a beginner, I was unaware of the cross-discipline lines that accessibility crosses. I was so focused on the code that I failed to realize that I was not the only one responsible for accessibility. More on the team aspect of this soon...
The real mistake was not realizing how much time and effort I needed to dedicate to advocating for the rights of all people who use the web. Helping my co-workers, colleagues, and others not only with the technical specifics of how I do what I do but why I do what I do.
And the sad reality is there will always be people who simply don't care. Or perhaps it's unfair to say they don't care at all but rather that they are more concerned with finances, growth, and KPIs. I had to learn how to approach the conversation from different angles and how to sell different stories depending on my audience.
I don't like re-framing accessibility as a marketing benefit or SEO benefit, as an example, but if it gets me the approval and the budget to make a difference, then I guess that makes my character chaotic good.
Accessibility is a Team Effort
As foreshadowed above, don't let your mindset as a developer distract from the big picture. Accessibility is a team effort where everyone must be involved. In agency work, as I do, sales and marketing must drive the importance of accessibility as both a business benefit and a fundamental human right. Designers, developers, and project owners must collaborate to ensure that everyone has a seat at the table for each user journey being developed. Quality assurance and user acceptance testers must be aware of what to look for and alternative ways to test.
My failure to realize this earlier in my career led to a lot of frustrations and friction that never needed to happen. I was trying to do everything myself, and I was not only burning myself out, but I was also alienating myself from my team. I had to learn to be a better team player and to be more open to collaboration.
Now I make an effort to sit down and talk shop and collaborate with all involved disciplines, and not only am I happier for it, but my work is better and my users reap the benefit.
Disabled People Must Be Involved
And most importantly, disabled people must be involved. I can't stress this enough. I am not disabled, and I may never be disabled. Even if I were to become disabled, that's only one of the countless things someone may be going through in life.
I can do my best to empathize and understand, but I cannot truly know what it's like to be disabled. The only way we can be 100% sure that our efforts are creating the change we want in the world is for disabled people to be involved. They must be involved in the design process, the development process, and the testing process. They must be involved in advocacy and education. They must be involved in the conversation.
As an abled body person, I have a responsibility to use my privilege to help those who are not as fortunate as I am. I have a responsibility to use my voice to amplify the voices of those who are not heard. I have a responsibility to use my skills to help those who need it.
If you don't take anything else away from this article, hopefully, it's this. To truly make a difference, we must make a chair for everyone.
Conclusion
Specializing in accessibility has been one of the most rewarding decisions I've made in my career. But I can honestly say that I would not be where I am today without the help of the people who have helped me along the way. I hope that this post can help someone else along their journey.
To learn more about diving deep into accessibility and how to get started, check out the following resources:
If you want to take things to the next level and have a little bit to invest, I highly recommend the following two courses by prominent figures in the accessibility community.