97 When web accessibility felt restrictive

There are a few things in life against which we simply cannot argue. Accessibility is one of them. Yet many people—including myself of course—paid little heed to accessibility on the web a decade ago. There is no point beating around the bush: I never gave it a second thought because I never gave it any thought. I never thought about how someone colour blind would view my site let alone how someone blind might view it, or someone with a supportive keyboard or mouse, or someone who relies entirely on vocal instructions. It was neither inclusive nor welcoming on my part but just how do you work on something you have—gratefully enough—never even had the chance to consider?

Once I did come across it I set out immediately to fix my website. To me, having now known that such a thing called accessibility exists, my once-proper website was suddenly incomplete. Just as bad semantic code left me feeling uncomfortable, now so did improper accessibility. It was like peeling away a layer of my website to expose its undercooked insides. But where does one start? Think of this as the journey of someone who rarely gave a second thought to making things accessible, discovering accessibility and attempting to do their best to make things work for everyone. A journey that is still underway.

To start, I looked up some fundamental steps I could take to make my website more accessible. Colour contrast, proper semantic code of course, screen reader prompts and aria-label values etc. I saw a myriad new rules that threatened to govern my website in ways they saw fit and, worse still, in ways that stripped control from me.

Colour contrast

During the time about which I am speaking, this website looked vastly different from how it is now. It is worth keeping that in mind as you read on because some descriptions may not make sense if you think about this website as it is right now.

I started with what seemed like the simplest of the lot: ensuring colour contrast. I was working with a pale grey, dark grey, and two other shades of grey in-between, besides an accent and highlight colour. I still use these variations on a theme today but not the same specific shades, hues and tints. I used the WebAIM colour contrast checker to feed in my hex codes and see what it had to say. My aim was at least AA-level accessibility for “normal-sized” text—which I assume to be of the size you are now reading.

To my surprise, it failed the test. Of course I could read it; why else would I have settled for those shades of grey? And it looked great to my design sensibilities; why else would I have chosen those colours? And yet this webpage was telling me there were people who would have a hard time reading text with as much contrast as I had put in. This was my first lesson: never assume accessibility.

I ended up redoing the colours but whatever it turned out to be no longer appealed to me from a designer’s lens. Even as I tried a number of combinations of hex codes it dawned on me that the possibilities were extremely limited. But it forced me to confront a more fundamental question: what is the point of this website? I write quite a bit, and I hope quite a few people read it and find it thoughtful and meaningful. Was my specific shade of grey worth sacrificing a portion of my readership?

Lighthouse for an overview

I use Chrome only when I need to use Lighthouse. I used to use GTMetrix before they closed down shop for free users. Lighthouse is just as comprehensive and, barring some quirks where it tells me to do a ridiculous amount of bending over backwards to save a whopping 0.1kb, its scores seemed good enough. I hit a nice 89 on accessibility which I thought, like other sections, would need some weirdness to hit 100.

It turns out that was absolutely not the case. While a 0.1kb excess CSS will drag your Lighthouse score down by 15 points, not having screen-reader support or buttons large enough for clicking will together just hurt you about 11 points.

This seemed absurd. Perhaps Lighthouse has changed since then but it felt like failing accessibility checks penalised your lesser than reducing HTTP calls or not having fixed dimensions for images.

This and several other reasons pushed me to redesign this website with a simpler approach and turn it into what you see now. Part of my intention included simplifying things to make space for other things that I gave much less attention to before—accessibility was one of those new things. Now with this design, Lighthouse hit 100 on all counts, which felt great:

Despite this I was weary. I had had enough experience with accessibility to know you could never check enough. Especially when you do not have those needs yourself, it becomes much harder to even consider what unique needs others may have. And for that of course we rely on some formalised testing system. I turned to Skilltide, a free Chrome extension that runs a bunch of tests on websites and helpfully highlights and points to areas of improvements.

Simulating accessibility

With Skilltide, the 100 score for accessibility on Lighthouse turned out to be questionable. It discovered an ID repetition—a blasphemous error in web development if there ever was one—because of a piece of code I was re-using in two places on the same page. It also offered a handy keyboard navigation simulator that allowed me to “see” where keyboard navigation on my website would take a user. And then it offered to read me a page on my website they way a screen-reader might.

Of course I could have done each of these things separately by flipping on switches that activated such accessibility features on my devices. But that right there was the problem all along: not only did accessibility initially feel more restrictive, accessing accessibility features themselves felt alien and cumbersome. Having a one-stop solution encouraged me to discover more about accessibility; and having explicit guidelines made the process of going from partially accessible to fully accessible a frictionless experience.

My takeaways were many, but here is the silliest one: Aria labels made sense but only if you knew what I was talking about already. Lighthouse only checks that a label exists, not what it says or whether that makes sense. Actually simulating a screen-reader quickly exposed the uselessness of my aria-label values. But there were still false-negatives e.g. consider this set-up:

<div class="parent">
	<div class="child">
    	...
    </div>
</div>

If this contained an input as the “child” element, accessibility would naturally dictate that I gave it a border or something of the sort that would set it apart from its surroundings. For my own reasons (design) I had a border around the parent instead which, visually, did not look confusing but Skilltide nevertheless flagged.

Skilltide also insisted that a div with a bunch of links (like my links to the web ring-3 or my many RSS feeds) be a ul with li tags instead. It made no sense but I complied because I knew by now that such things would matter to screen-readers and keyboard navigators. Moreover, these are hardly inconveniences in the grand scheme of things when you are looking to make what you build more accessible.

What accessibility did for me

Once I was done—and had the website you see now—my accessibility score remained 100 but meant little. Skilltide flagged nothing but one false-negative. And other tests agreed. The W3C maintains a full list of their recommended accessibility evaluation tools which I used to find new ways of testing my website. I plan to replicate my efforts on my other websites as well over time.

Besides all it did to make this website more accessible, this exercise prompted me to think about three things during the course of my tinkering, which turned my perspective from restriction to orientation. If you agree that accessibility should be non-negotiable, the many rules it places on design and code are no different from the several others that already exist—some of which have barely any justification for existing besides that they are part of a standardisation.

So it would help to think of such standardisation when accessibility restricts what shade of red you can use or whether you can blissfully type outline: none; and get rid of that annoying box around that div which for someone else is a critical aspect of web usage. Style it instead. Pick another shade of grey or blue or green or red or whatever else. Our design sensibilities do not end at #ffffff surely.

Working with accessibility made me rethink what simplicity means. I find that the simple is often more accessible than the intricate, but the simple is also tougher to get right when you are designing something. Working with accessibility made me rethink design itself and come up with ways to do something I might otherwise not have. It reminded me of the many photo walks I have been on with self-imposed restrictions. It can start out feeling restrictive but it ends with a feeling of freedom and accomplishment and the joy of having done something positive and meaningful. And finally it forced me to rethink my priorities: did I want a certain look or was it worth putting in some extra effort to get a comparable look while also ensuring my readers could actually see and read what I wrote with the same pleasure that I had writing it?

Another resource I consult for web accessibility is the gov.uk pages which are some of the most wonderfully and thoughtfully designed government webpages I have seen. There are others too no doubt and there are generally a lot more guidelines than I have even stumbled upon until now. And further there are definitely many of us on the “small web” who are not web developers by profession or otherwise exposed to web accessibility standards on a daily basis, so it can seem more cumbersome than novel at first. But in the end, it can have more benefits to your readers and you alike, and that is a proposition that is hard to argue with.