For the third program in the Coding With collection I chose to focus on Coding with Fairness. I knew in the planning stages of the challenge that I wanted to include this in the series, however trying to think of a way to honor the theme was intimidating. How do you make something fair? Who decides what is fair? How do we know when something is fair? How do you introduce fairness into software? How do you practice fairness while coding?
After three years in a Computer Science degree and a year and a half working in the tech industry, the first time I was ever asked about how I was making my software usable for everyone was when our team brought on our second UX designer. As we were onboarding and telling him what we needed he said, “Sounds good! Which WCAG standard do you follow? 2.0 or 2.1?” What? WCAG? I had no idea what this was, but apparently there are different versions and apparently I should’ve been following these guidelines for years.
Even after becoming aware of such a standard there was no change in development requirements nor a motion to revisit our completed work to code for accessibility. In my few short years in tech, the impression that I got from the industry regarding these kinds of usability implementations was that it was always someone else’s job to consider them. The designers would tell us what we need, but they were always just nice to have and not a priority if we were short on time. (Spoiler, everyone building software everywhere is short on time.)
While I’m thankful for so many things I learned from our team's new designer, being introduced to the WCAG standards has to be one of the most impactful. Not too long after this I began working at Boca Code where not only do we consider accessibility as a primary concern in our development, but also our teaching. We try and make learning and building in our space an equitable experience for everyone. This does not only include referring to WCAG when writing our programs, but also hiring ASL interpreters for our classes, writing captions for all of our video content, and being at the ready to provide any additional accommodations for our community.
This kind of action doesn’t happen in a bubble though. We’ve been extremely fortunate to meet influential accessibility advocates who have advised us along the way including, Saida Florexil, Beth Wagmeister, Claudio Luis Vera, Marcelo Paiva, Mark McGuire, Rojene Russell, Janice Pickron and many more. One of the most important lessons I’ve learned from speaking with this incredible group of people is that accessibility in software is never dev complete. There is always something new to learn, consider, and implement.
When thinking about Coding with Fairness I was mindful of this journey, and about how we have to be open to learning something new every day. Therefore, for this program, I built a small advent calendar that shares a daily WCAG standard. Approaching the documentation all at once can be overwhelming and difficult to internalize, however, if we focus on learning one thing at a time it can become easier to fold into our work habits.
During the development of this project I had the opportunity to read through the WCAG documentation in a way I hadn’t before. It was interesting how combing through line items and adding them to my program actually started to change my code. As I was reading, I was going back and adding ids to my divs, changing the colors to be higher contrast, using san serif fonts for readability, and being mindful of my tag selections to help aid screen readers. The entire project couldn’t be more than a 100 to 150 lines of code, but I put a lot of care into those lines and how they will present themselves to different users.
It’s my hope that a tool like this helps make it easier for developers and software teams to learn how to build with accessibility and fairness in mind. No single person is ever going to know everything, but the important thing is that we start taking steps forward, even if it’s just one little tip per day.