The web is a strange medium. One of its founding principles turns out to be an impossible paradox. So even in theory it is probably not possible to create a web that is truly for everyone. When we take a close look at the practice of the web
Take the default styling that different browsers use for their focus states. In some browsers they look like a dotted border, in others they look like a blue glowing border. Many designers think these states look ugly. So they want them removed. Focus styles were added to browser so people could browse websites using their keyboard. The practice of removing focus states is so widely spread that nowadays it’s impossible to navigate the web using a keyboard alone.
But even if the focus states are not touched their default behaviour is not very well implemented. Here’s a video of someone trying to tab through a list of links using the Firefox web browser.
As you may see, when they reach the bottom of the screen the text of the link disappears behind the so called status bar. This is just one example of the broken state of default focus behaviour. There are many more. It shows that keyboard navigation is neglected by the people who build browsers as well.
When I asked Marijn Meijles why he never uses his tab key to navigate interactive elements, he explained that in part it’s details like these that make keyboard focus too unreliable to depend on. Marijn taught himself a different way to control his computer.
I’ve always assumed that adding detailed structural semantics to an HTML document is a good idea. I started to doubt if this is such a good idea when I observed casual computer users who depend on a screen reader. All elements that have some relevant semantic value, like heading levels, navigation items, links and forms get this meaning attached to it, which is spoken out loud. So this page would’t simply start with the title spoken out, but it would sound like heading level one, The defaults suck. When a page consist of many elements, things can become very annoying.
My impulsive reaction was to create websites without any structural semantics in them. Bram Duvigneau pointed out that, while this might indeed help some casual screen reader users, it would very much cripple the experience for experienced users.1
So simply ignoring all semantics is not the solution. This problem is much more complicated. It is both a design issue2, and an issue with screen readers themselves3.
Then there’s an issue with the way many companies approach accessibility: not as one of the starting points of the design process, but as a checklist that’s being ticked off after the product is released.
You could argue that this is still better than ignoring accessibility completely. But I prefer Kat Holmes’s conclusion on this attitude:4
Treating accessibility and inclusion as an afterthought, or only meeting the minimum legal criteria, is an exclusion habit
She argues that ticking off lists is a problem that we should try to solve. And I agree. Our ambitions should be much higher when it comes to designing for an accessible web.
This thesis is not going to solve these issues. There is not a copy-pasteable solution for the issues with tabbing in it. There is no practical fix for the issues with screen readers. And I am not going to present you the definitive solution for the exclusive habit of ticking off a checklist. But this thesis may give individual designers, or design teams a few tools and insights to work with. And in that case, this thesis may help a little bit in creating a more inclusive web.
So the web is weird, and our design practice doesn’t help either. In the next chapter I will explain how I found my Exclusive Design Principles, the principles I used to create tailor made accessible interfaces throughout my research. The Exclusive Design Principles that gave the name to this thesis.