There’s this idea floating around that to make websites accessible you have to compromise their beauty: a website can either be accessible or beautifully designed, but not both.
This is actually rubbish, as plenty of good looking accessible websites out there will bear witness to (I may get around to compiling a list of them one of these days).
However, that doesn’t really matter, because there is a lot more to aesthetics than beauty. Aesthetics is all about sensory and cognitive experience, using all the available senses; not only sight, which we tend to give undue importance to. And pretty much everything can be experienced aesthetically.
Let’s take for example a hot drink. Everyone likes a hot drink on a cold day. There are many things to like about it:
- the warmth of the mug in your hands
- the flavour of the drink
- the sound the liquid makes when you slurp it up
- the memories particular drinks bring you
these are all possible elements of your aesthetic pleasure in drinking a mug of tea or cocoa. None of them are visual or related to beauty in any way, yet they make up a great experience.
But the internet is mostly a visual thing, you say.
This isn’t exactly true either. There are at most three senses we can use to access the net – sight, sound and touch. Most of us use a combination of all these; some of us only use two or even one of them.
Those of us who use all three senses may tend to think sight is the most important, and design as if it were so. But the Internet is not a picture; it’s an interactive network. And if you think about the ways in which we can interact with it, these involve mostly touch and movement, for mousing and keying, and maybe sound if we’re using speech to text software, but not sight. There’s nothing we can really do with sight apart from look at things. So touch and sound may be the really crucial senses here.
There are also other factors in play for an aesthetics of the internet:
- our perception of time, such as when a page takes ages to load (which in reality might only be a couple of seconds, but seems a lot longer)
- our perception of movement in scrolling or tabbing through links
- the overall flow of it: how to get from one part to another and how the content is structured
- the quality of said content
Content! This is what no website can do without. And something I keep hearing about content is that people don’t read on the net. This is a bit funny because if we don’t read, what else are we doing? There are only so many cat videos you can watch in a day.
Reading is still our most important online activity, together with writing, which is related, even if it is only tweets and status updates. So the Internet is all about text. Not only text, but hypertext. Text with links! Links are the whole point of the network. Else we might as well be reading books.
So let’s think about how we can make hypertext really accessible. Or at any rate stop making it really inaccessible, as it tends to be accessible by default.
We now know not to do this:
though probably because it messes with SEO, and not for accessibility reasons. The point here is that this logo, which probably displays the company name, is an image, so it is not machine readable. A quick fix here would be to include the alt attribute inside the image tag, like so:
This is now understandable to any passing search engine crawler, not to mention assistive technologies.
Machine readable text is accessible in so many ways: we can look at it, listen to it, even touch it with a braille display. So we can use any of our three internet-compatible senses to read it.
But maybe you still want to give your sighted users something nice to look at. That’s great! Sighted users can also benefit from accessibility in many ways; there are quite a few things that can be done in this area. Let’s have a look at a few.
Making sure text is zoomable
Because quite a few of us have bad eyesight, or will have in a few years time, this is pretty crucial.
Browsers are already doing a lot of of the work here. Most browsers allow two ways of zooming in: page zoom, which zooms the whole contents of the page (this is what happens when you press
ctrl + or
cmd +), and text zoom, which consists in changing the browser’s default font size (usually 16 pixels). OK, so browsers are dealing with this. Why should we care?
Because this default functionality can easily be broken. There are at least two ways to break it: one is by setting font sizes in pixels or other absolute units; the other is by not making layouts responsive.
Let’s look at the first:
When font-size is declared in pixels, it overrides the browser settings. So if a user has set their browser font size to 20 or 30 pixels, hoping to have nice big text, and we set our base font size to something like 14 pixels, 14 pixels is what they are going to get.
The best way to fix this is to always declare font sizes in relative units:
So if base font size is set to 100%, that will always be 100% of whatever the browser font size currently is. Or, if you really think 14 pixels is the best size for your text, you can set it to 87.5%, and anyone who hasn’t changed the browser default will get a pixel perfect 14 pixels. Those who have changed their default have probably done so for good reason, so why mess with that?
This also applies to any other font sizes we may want to declare such as headings or small text. For these, it’s probably best to use em units. The only conceivable problem with using em is that its calculation is based on the font size of the parent container, so if that is different to base, we can get unexpected results. But if we’re using a sensible number of font sizes, and properly structured HTML and CSS, this can hardly be a problem.
Of course we can also use rem units, as these base their calculation on the root font size, but if we need to support elderly browsers such as IE8 that may be out of the question.
As for the second way to break zoom functionality, why is it important that layouts be responsive? Well, when we zoom in on a page it’s as if we were looking at it in a smaller window – we’re reducing the amount of content that fits in the window at once. So unless the layout in question is a single, flexible width column of text, chances are things aren’t going to look too good.
The best thing to do is throw in some media queries when building even slightly complex layouts, or, better still, make everything mobile first (again, might be tricky if support for older browsers is needed, but there are workarounds).
Here there is also a potential issue with declaring breakpoints in pixels. Most browsers can deal with it on page zoom (Firefox doesn’t seem to for some reason) but with text zoom they will not work anywhere. So it’s a good idea to set breakpoints in em too.
How to do this? The maths is pretty easy. When we decide on a particular breakpoint in pixels, the decision is based on how the layout looks for a given window size, and this is always related to our chosen base font size. Assuming that to be the default 16 pixels, if we want the breakpoint to be at 1024 pixels we just divide 1024 by 16, and that’ll be 64 em. This will keep breakpoints consistent at whatever font size our user chooses to throw at them.
Styling text links properly
The essential thing about text links is that they must be distinguishable from the surrounding text.
For quite a while now the tendency in link styling has been to remove the default underline and change the default colour. This is not a bad thing in itself, but removing the underline means that we are relying on colour only to distinguish the link, so it must be a suitably contrasting colour.
The WCAG 2.0 spec tells us we need to have at least 4.5:1 contrast between text and background, or at least 7:1 if we go for level AAA. In addition to that, if links are not underlined, they must have at least 3:1 contrast with surrounding text plus a “non-colour designator” (typically the underline) on both hover and focus states.
This somewhat limits the range of possible colours for non-underlined links. Still, it’s doable, and if that’s the way you want to go, perhaps you’ll find my colour contrast tool useful. And don’t forget to style hover and focus states too:
Another little thing worth thinking about is the visited state. By default, visited links have a different colour, but that gets overridden when we style the colour of our anchor tags. And then, more often than not, it gets forgotten about. But on websites with lots of content and links, a differently styled visited state can be really handy for navigation (this article goes into it in detail):
Styling the focus state
Keyboard navigability strongly depends on visible focus, and this is pretty easy to break. No one really likes the default browser focus styles, but if we do remove them, we must remember to style our own. There are several ways of doing this:
a) using the outline property (this is what default browser styles use):
you can also optionally use outline-offset to distance the outline slightly from the element:
but outline as a property is not well loved, particularly because it doesn’t always respect the shapes of elements. A classic example of this involves elements using border-radius. Outlines on these elements will always have straight edges, which can look pretty awful.
A possible workaround is to use border instead, but border is already used for other purposes in quite a few focusable elements such as inputs. But say we just have a bunch of anchor elements with rounded corners and want to use border to style their focus state. An essential thing to do is give the unfocused element a transparent border of the same thickness, so it doesn’t jump on focus:
Another usable property that respects border-radius is box-shadow:
Of course it’s a lot simpler to just leave the browser defaults alone. Even so, it’s a good idea to test focus on all focusable elements to make sure everything is displaying correctly. Issues may occur in particular with anchor tags that have block level elements inside them. As anchors are inline elements by default, this may result in incorrectly shaped outlines:
Sometimes changing the display property of the anchor to inline-block will solve the problem, but this doesn’t work for all cases. Another possibility is to move focus styles to the inner element:
Whatever you choose to go with, the important thing is to make sure all focusable elements have some visual indication of focus. It also helps to make sure it’s actually possible to tab to all these elements, as there are a million other ways of breaking keyboard navigability out there. But that’s out of scope for this talk; I may go into it some other time.
Now go forth and make things accessible.