Accessibility Auditing My Portfolio Site — Part 6

Final Testing

Automated Tools

In Part 1, I used 6 of the tools Todd used: WAVE browser extension, Firefox’s accessibility dev tools tab, AXE DevTools extension, ARC dev toolkit for chrome dev tools, IBM Equal Access Accessibility checker, and Microsoft Accessibility Insights. So let’s go through that list again and see what we find.

ARC dev toolkit after scanning the blog page on

Manual Testing

The Microsoft Accessibility Insights Assessment is such a great testing resource. Many of the tabs break down exactly what information is returned by the relevant elements on the page and others tell you what to look for when you’re manually testing with a keyboard or screen reader. Some of them have a visual helper toggle that will highlight relevant elements or apply the relevant settings so you can test. It’s a very long list of tests, but luckily there are many tabs I know I can skip because they either don’t apply or I haven’t changed any code related to them since the last time I checked. Ultimately, these tests don’t return anything I didn’t already know about.

:root {
/** sunny side **/
— blue-background: #c2e9f6;
— blue-border: #108DAD;
— blue-color: #96dcee;
— yellow-background: #fffaa8;
— yellow-border: #f5eb71;
/** dark side **/
— indigo-background: #808fc7;
— indigo-border: #808CBC;
— indigo-color: #6b7abb;
— gray-border: #e8e8ea;
— gray-dots: #e8e8ea;
.toggle — checkbox:focus + .toggle — label {
outline: solid 3px var( — button-border);
transition: outline 100ms ease-in;

Multiple Screen readers

There were a couple warnings from tools about multiple labels being used on components. I applied aria-labels liberally based on what I was hearing from the screen reader. Now that the bulk of the work is done, I want to go back through with multiple screen readers and find the optimal balance. Specifically, I want to make sure a screen reader says “dark mode toggle, on” or “dark mode toggle, off” when the toggle is selected and that things like buttons in headings don’t have redundant labels read.

Cross-browser Testing

In the spirit of completing testing I should have done a long time ago, I want to click through my site in multiple browsers and verify nothing’s broken. I try and make sure to check MDN’s browser support table for pretty much everything, but it never hurts to verify in the browser itself.

blog preview component on in Safari with a scroll bar with corners

Final Fix

I wanted to sift through all my blogs to make sure I’m not using words like “above” and “below” where they wouldn’t make sense without visual context. The warnings came from the IBM Equal Access Accessibility checker, so while that’s broken, I’m relegated to using ctrl + F to find “above”, “below”, “left”, and “right.” Lo and behold, I’ve already used “above” a couple times since I fixed the instances of “below” on my main page! This is a hard habit to break.

Things to Revisit

I opened 5 issues on Github over the course of this series. #3, #9, and #11 are easily large enough accessibility projects to deserve standalone blog posts.

Frodo on Mount Doom “It’s done. It’s over now.”

Main Takeaways

Running ARC Toolkit on my blog page now vs when I started is like night and day. I got a huge amount of errors back in Part 1, but now it’s all warnings and two things I’m going to fix in those Github issues. On the flip side, I don’t think IBM Equal Access Accessibility checker’s % of components without issues metric moved during this entire series. I’m pretty sure I saw 93% the whole time.

Final Thoughts

I want to emphasize that if you want to improve your site’s accessibility, an audit and fix process this intense right off the bat is not necessary.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abbey Perini

Abbey Perini

…did someone say animated CSS button?