I wanted to write a little on my focus on accessibility in 2022, its outcomes, and my next steps. I’ve included links to the resources that helped me the most in this effort.

intro

Last year, 2022, marked ten years of professional development experience starting with my first unpaid internship in the summer before I started college. Even weirder and scarier, it marked twenty years of total experience for me from the time I first started teaching myself HTML and CSS in elementary school.

The web has come a really long way in that time, and it’s hard to know what to focus on learning next. One area I realized I was falling short in was practical web accessibility, and I was fortunate to learn a lot about it last year.

what i learned

tools of the trade

I learned about Firefox’s built-in accessibility inspector, which already provides a fantastic array of tools as a developer. In addition, Deque’s Axe and WebAIM’s Wave extensions are helpful utilities to keep handy. Axe’s Firefox extension is unavailable as of this writing, for reasons unknown. Hopefully it will be available again soon.

I’m not yet fast or fluent, but I learned a little about VoiceOver and how screenreaders work in general. Deque has reference sheets which are great resources that I’ll be keeping around for future reference when testing with screenreaders.

The importance of keyboard accessibility was also something that I reinforced this year, and it goes hand-in-hand with screenreader testing.

As a side note: I don’t see this mentioned often, but since I’m using the tools built into macOS so often, it’s been helpful to enable the menu bar accessibility shortcuts button. This makes it easy to toggle on increased contrast mode with two clicks, instead of searching through the OS settings each time.

Screenshot of macOS Control Center. There’s an arrow pointing towards Accessibility Shortcuts, Show in Menu Bar toggle, which is set to ‘on’.

about colors

When I began focusing on accessibility, it was because I started working on fixes to better support Windows High Contrast Mode themes and macOS increased contrast mode. I wasn’t previously aware of the macOS setting, but I was familiar with HCM in Windows–this was the first time I needed to understand how it worked, though.

Mozilla’s accessibility guidelines article was a fantastic resource in learning about system colors and forced colors, and how to use them effectively. This Polypane article has also been a great reference.

Edit (Jan 6): You can find even more detailed information about colors in Firefox in this article on Firefox Source Docs!¹

Separate from supporting HCM, I reinforced my knowledge of WCAG color contrast rules. This is one of the most basic concepts related to color and accessibility, and it stays at the forefront of my mind for design and front-end development.

resources

I read Design for Real Life in 2021, which provided a foundation for my work in 2022. The book includes real-life case studies that stayed with me, and emphasized centering empathy for your users as a designer and developer.

(I haven’t finished it yet, but I’m also reading Accessibility for Everyone from the same publisher.)

At the end of 2022, I was lucky to get to attend a deep dive accessibility testing workshop, led by Manuel Matuzović. (As an aside: Manuel’s ongoing posts on modern CSS have been another great resource in expanding my CSS knowledge.)

I defined some goals ahead of time for this workshop:

reinforce my a11y knowledge and make accessibility testing a habit via repeat exposure
discover new knowledge gaps
provide a capstone to a year’s effort

This was a very positive online workshop experience for me, and I thought seeing Manuel’s approach to testing real, live websites was valuable. I got a lot out of the W3C’s Web Accessibility Perspectives videos, which were shared during the workshop. It was surprising to learn that per WebAIM’s 2022 report, 96.8% of the top million web pages still had automatically detectable WCAG 2 errors. Of those errors, 96.5% are one in of the following (relatively) easy-to-fix categories:

empty links and buttons
missing alt text, form input labels, or document language
low contrast text

I used these tools to evaluate this site, and found that my current Hugo theme includes text contrast errors, too (as of this writing). I’ll say more about that in a minute.

conclusion

Having the hands-on experience of fixing accessibility bugs has been a great confidence boost. I no longer feel like I have only a vague, theoretical grasp of web accessibility concepts and best practices. There’s still a lot to learn, but web accessibility feels much more approachable now that I have a little work under my belt. If you’re someone who feels overwhelmed by these concepts, as I did: I think just jumping in and making some sort of progress is a good way to make things feel less insurmountable. And more importantly, it benefits the people using the things you make.

Edit (Jan 6): If you’re looking your first accessibility bugs to fix, consider taking a look at some open bugs in Firefox: core accessibility and Firefox front-end. Items tagged good-first-bug in these lists usually have mentors to assist you, and you can get help in Mozilla’s Matrix channels, too–see #accessibility and #fx-desktop-dev, respectively. Outside of Firefox bugs, you might also consider bugs for Mozilla Hubs, Bedrock (mozilla.org), or MDN.² You can find more info on getting involved on Firefox Source Docs.

I’d like to shout out the accessibility team and my front-end colleagues at Mozilla for their work, the resources they’ve created for developers, and the 1-on-1 help getting started on this path when I first began working on high contrast mode bugs.

In 2023, I’m hoping to find ways to do more design-focused work, and I think my reinforced knowledge of these concepts will help me make the right decisions earlier in the design process. There are a couple of side projects I’ve had simmering on the backburner for some time, which I’m hoping to find the time to work on alongside my day job, and I plan to make accessibility a top priority for these projects, as well.

One of those side projects is this blog! I’d like to expand this site to have a little more content, and part of that will involve a redesign. I’ve decided to move from Hugo to Eleventy, and I want to spend the time creating my own template rather than using someone else’s. (Though the Fuji Hugo theme I’ve been using has been great, I can’t resist the urge to start from scratch.) I’ve always struggled to maintain momentum with a personal devblog, but this iteration has felt more successful than prior attempts, and I feel good about sinking some time into making it more my own.

a year of accessibility