Website Redesign: Accessibility Audit

I made better accessibility of a goal for redesigning this site. I honestly have no idea how the site was before this effort. Well, that’s not true. I once ran the site through a screen reader and gave myself a world-class face palm when as I listened to the gibberish it produced. In other words, things must’ve been bad.

Conventional wisdom says accessibility should be part of your code from the start. That makes total sense. It’s far easier to code things correctly the first time rather than go back and refactor the things that are wrong. One little thing leads to another, which leads to another, which leads to, well, you know.

Unfortunately, I didn’t heed that advice and let my cowboy coding ways get the best of me. It’s all good though, because there’s a happy ending. Here’s that story.

I started with semantic elements

This is a pretty easy thing to do. I mean, at least for me. While there are definitely moments where I find myself wondering whether an element is a section or an article and what really constitutes the main element of a page, I think those instances are generally an either/or sorta thing and most times things are obvious enough.

So yes, I use nav, article, aside, etc. where I (think) I need to. I felt like I had a little beat on things after editing this post on sectioning HTML a little while back.

I made sure color contrasts make content legible

This is another piece of low-hanging fruit. I must say, however, that using orange as my primary color is a challenge. The previous hex I had been using on the old design (#ff9e2c) was far too light to serve as a background for light text and looked awkward with dark text. I went with something darker. In fact, I merely took the hex code from the San Francisco Giants logo and ran with it. Turns out to be quite accessible!

Not that I’m really using orange as a background for anything. Most things are wither a dark gray or a slight off-white. But who knows? I may very well make a San Francisco Giants color theme down the road.

I stayed away from fancy, complicated components

You won’t find any accordions, tabs, tooltips, pop-ups and what have you on this site. It’s a blog. And a way to contact me. Sure, it could also be a way for me to show off my uber awesome superhuman web design powers, but that would probably degrade the overall user experience and is exactly the sort of over-design I’m trying to avoid this time through, My last iteration was over designed and I really want to step things back.

That said, I’m not suggesting fancy creative design and accessibility are mutually exclusive. But if I’m wanting to start with a good accessible baseline for this site, then perhaps starting with complicated requirements with tricky accessibility standards might not be the best idea. I’m simply unconfident with my accessibility skills to go there right out of the gate.

Then came the audit

The only way to know whether I’m succeeding at accessibility is to test my work, right? I already knew I had a Google Lighthouse score of 91 from my performance audit. That’s only one metric, but I figured I’d use it as my baseline for success.

Screenreader results

I turned to screenreader tools for help checking how my content is read and how effective the navigation is.

Screenreaders are great tools, of course. But I’m not an expert using them or anything. I’m trying to mimic a real scenario aided by automated online tools auditing my code. In other words, it’s not exactly a bullet-proof or realistic method.

I started by running the site through VoiceOver on MacOs. That went a lot better than I expected. The voice read the all of the content in the right order. That was rad.

But then I ran things through Chrome Vox. It’s one of a couple voice readers that are listed on the A11Y Project website. The results there were pretty encouraging, but I realized I could do better.

Unlabeled menus

For one, my menus were unlabeled. I was using the correct HTML5 nav tag, but I failed to give them a proper label that would differentiate one from another. There are technically three menus on the site, so it would behoove me to make sure they are announced to the user separately. I referred to MDN’s documentation for the ARIA navigation role to make that happen and now everything reads the way it should.

No discernible labels for links

I turned to WAVE, which is an online accessibility checker that’s also listed on the A11Y Project site. Ugh, that revealed more stuff that needed attention. This time, there were instances where my links apparently had no discernible label. Turns out I have a section on the homepage where I wrap four elements in links that needed ARIA labels. The heading apparently don’t count because they are not directly related to the links. So I added the labels and moved on!

Invalid role attribute usage

WAVE also identified that I was using a “role” attribute on HTML elements that were invalid. I removed those and moved on.

The last thing WAVE told me was that I had duplicate IDs on the page. I couldn’t figure out where those were. Everything seemed correct on that end.

Then I realized what was up: my SVG files! Illustration programs, like Sketch, export assets as SVG but they all have their little opinions that make the output a little different. In my case, I had a bunch of automatically created IDs in each file that overlapped with one another. Simply removing those did the trick.

Final results

With my passing audits, I went back to Google Lighthouse to check on my score. My fingers shook a little before I clicked the audit button, but I had nothing to fear because I scored 100! Phew.

I’m pretty sure the accessibility work also raised my Best Practices score to 100 as well. Making an accessible website is the real goal, but getting an additional score boost makes it a lot sweeter.

It’s worth stating again: this is only one metric. Other tools may not rank the site so well. Or hey, it’s possible someone with a real disability finds the site unusable. That’s the problem with automated tools, aggregate scores, and not seeking personal advice.

I’m calling this work a success with the caveat that I have future work to do. I really would like get some feedback from folks who rely on a screenreader for content and a keyboard for navigating content. Maybe someone reading (or listening to) this will volunteer?