Let's Talk Accessibility

Designing and coding an accessible digital application is easy, as long as you approach it in the right way. So let’s talk about how. Accessibility has become a bit more of a buzzword lately, and that’s a good thing; this renewed focus on ensuring digital products and services are accessible benefits everyone.

“But isn’t accessibility just for disabled people?” Hell no! If you’re one of the many people who has ever said this to me, you should know that I no longer respect you; your opinion is now as valuable to me as the value of an ironing board to a Dung beetle. Even Wikipedia’s opening line on the subject is that “accessibility refers to the design of products […] for people who experience disabilities”; while true, that’s only part of the story.

Accessibility also benefits people without permanent disabilities; it applies to users with temporary disabilities, poor eyesight, and power users (such as myself) who rely heavily on keyboard-only use. The most overlooked consideration for accessibility is arguably situational limitations, such as having a broken arm, having misplaced your glasses, your wireless mouse running out of battery, being in a room with unusually coloured lighting, etc. In short, accessibility is about making digital products easier to use in general, for everyone.

Approaching Accessibility

The problem with accessibility is ignorance; ignorance in thinking that it’s just for disabled people, or is simply an unimportant ignorable buzzword. The fact is, ensuring a website or application is accessible is extremely easy, as long as you’ve been following best practices in the first place. If you’ve been doing that, then your product/site is probably pretty accessible already. But if you’re unsure, here are the 3 things to look out for:

Convincing your Product Owner that accessibility is important, and applies to everyone

Designing for a good User Experience

Writing appropriate, semantic code

Convincing people that accessibility is important is regularly the biggest hurdle; this may even mean convincing yourself. If you have an already existing product that isn’t meeting accessibility requirements, a Product Owner will simply hear any proposed fixes as additional (and avoidable) cost. But it’s worth remembering that, as the interest in accessibility continues to grow, any product that isn’t accessible will eventually be left behind. Computers have become a fundamental part of almost all career choices now. And as companies, and population in general, have grown in size, so has the number of employees and users with the need for accessible software. A great number of companies now, particularly in the Public Sector (and a growing number in the private sector as well) simply won’t purchase your software if it doesn’t pass basic Web Content Accessibility Guidelines (WCAG).

Designing for a Good User Experience

This should be obvious, because if you aren’t designing for a good User Experience, then who the hell are you designing for? But let’s be honest, it’s far too easy to overlook the obvious sometimes, so it can be helpful to go right back to the basics. In terms of accessible design, it really comes down to just a few points:

1. Use clear, logical layouts

This isn’t rocket science: this is about making sure your primary navigation comes before your content; it’s about making sure the most important parts of your product stand out; it’s about making sure the save button for a form is after the form, etc.

A simple suggestion I like to give is to imagine all of your content as a plain document, unstyled, laid out as if to be read line by line on a piece of paper. Think about the order that you’d want it all to be in. As well as helping to determine the priority of all your content, this is applicable to two very broad accessibility scenarios as well: keyboard-only users, and users of assistive technologies such as screen-readers. These users will have to cycle through either all the actionable elements on the page - the links, form inputs, buttons, panel toggles, etc. - or literally all of the content one by one, so it’s even more important to place things where you’d expect them to be found.

2. Contrast matters

There’s a little more to this than just ensuring that text stands out on a background, and, unlike using logical layouts, this one isn’t always obvious. For instance, a white button should have dark text, but if that white button is then on a light-grey or off-white background, it may not be clear that it’s a button at all to someone who can’t perceive that colour difference.

Contrast matters, not just for making sure that text is clear, but for making sure that the purpose, and state, of an element is also clear. WCAG recommends specific colour contrast ratios for its AA and AAA
standards; those ratios can differ based on the text size, so it’s
always worth checking the contrast of your chosen colours using a tool
like
WebAIM’s contrast checker. A personal favourite resource of mine is accessible-colors, as it makes suggestions based on your original selection.

More than just colour contrast though, important elements need to contrast from each other. This especially extends to interactable elements. Consider links: a user should be able to visually differentiate between essential links and standard text, without relying on colour alone. These should then have clear hover and focus styling (the latter being especially important to keyboard-only users), again without relying on only a colour change. The purpose can often be clear from the context. For instance, you can safely assume that evenly spaced, separated text in a header or footer is for a set of navigation links; or that comma-separated terms at the end of a blog post may be category links. If positioning and context can differentiate some elements from others, that allows for borders, underlines, shadows, background and foreground colour inversion, and many other styling options to highlight other states as well.

3. A picture is not worth a thousand words

In other words, don’t rely on only an image to communicate something important. This simple principle is violated most frequently by interactable icons; that simple thin-lined cog icon to open a settings window might save space and look nice, but to a poorly-sighted user, or a user without sight at all, it’s meaningless.

By all means, use images and icons as much as you need to for your design. But if they’re intended for some form of interaction, then you need to make their purpose clear with text as well. There are arguably some exceptions to this however, for icons and imagery that have fairly universal meanings throughout digital applications, but even in these cases, a screen-reader still won’t be able to interpret an icon alone, so you may need to include hidden text as well (more on that in a bit). But if there’s any possibility of the meaning being ambiguous, include visible text in your design as well to be safe.

Writing Appropriate, Semantic Code

This is another point that should be obvious, but I see developers screw this up all the time, sometimes spectacularly! For simplicity, I’ll break this down into a few simple points as well:

1. Use the right tag for the job

HTML5 introduced a lot of new elements, and you should definitely be using them. Not only are they important for Search Engine Optimisation (SEO), they also come with default styles and functionality to benefit your users, and screen-readers will infer meaning from the elements on the page and communicate this to the user. If you use a heading tag like an <h2> or <h3>, that fact, and its heading level, will be read aloud; a <section> indicates a new section, or block, of content; <header> tags can be expected to contain introductory text and titles, as well as links if relevant; <aside> tags should contain additional, but non-essential information; etc. All of these tags have meaning, but <div> and <span> tags don’t.

This applies beyond the tags that were introduced in HTML5 though. For instance, I regularly see mock buttons with custom click events on websites which, in a lot of cases, are a <div>; if you want a clickable button, then use a <button>, or at least an <a> tag. Screen-readers will state that it’s a button or an anchor, indicating that it’s an interactable element. Buttons and anchors (at least with an href) are also natively focusable elements, so can be accessed by keyboard-only users, whereas a different element would require a tabindex, and a custom event to listen for the enter keypress.

Another good example is forms. I regularly see form inputs that rely on only placeholder attributes to communicate their purpose. Don’t do that! A placeholder is not a label. Placeholders are meant to convey additional information, that’s why they’re natively styled to be less obvious. Not only are they more difficult to see by default, but screen readers almost always ignore them. Use a <label>, properly associated with the relevant <input>. Checkbox and radio button lists complicate things too. Each checkbox needs its own label, but the list needs to be properly described too. This is done by putting the list inside of a <fieldset>, with a <legend> as its first child explaining the list. Building simple habits like these make a world of difference to assistive technologies.

2. Hidden content helps

By hidden content, I mean aspects of your code that a typical end user won’t see. This means using the right attributes, setting the right input types, and sometimes hiding certain content just for screen readers. It can even be helpful sometimes to have specific links, or other interactable elements that are hidden from view, but will be visible when they receive focus from a screen-reader or keyboard-only user. A classic example of this is to have a Skip To Content link as the first focusable element on the page, that can be used to skip navigation links and other repeated content that would usually appear at the top of all pages.

Normally when setting elements to not display (either by setting display to none in your CSS, or using the hidden attribute), screen readers will also ignore it, but you can easily create some helper classes to hide an element, but allow a screen reader to find it.

This can also be very useful to allow for certain design decisions. For example, you may want to include a close icon for a modal window, but not have the word “close” visible, even though it would be useful to a screen reader. This approach for hidden, but screen-reader visible, content can be used in such cases. A common approach previously was to use the title attribute for this purpose but, while useful, screen readers don’t always read the title attribute. An approach like this, or using the aria-label attribute, is far more reliable. That brings me nicely onto my next point:

3. Use roles and ARIA attributes - if you know what you’re doing

Element roles and Accessible Rich Internet Application (ARIA) attributes are both part of the Web Accessibility Initiative (WAI). I won’t go into the details of all the different role values or ARIA attributes - you can look into them more fully yourself when you need to - but I will say that you should use them with caution. They are extremely helpful to screen-readers, but only if used properly. As a blanket rule, if you’re not completely sure what you’re doing with them, then don’t use them.

The point in these attributes is to convery meaning and purpose, and to indicate interactive states, when they’re otherwise unclear. But that also means that mis-using them will make things worse. If I held up an apple to you and earnestly said: “this is a banana”, you’d either be confused, or just think I’m an idiot; the worst case scenario is actually that, if you’d never encountered either an apple or banana before, you might even believe me. Don’t do the same thing to your users. Using the right tags in the right places should convey the necessary meaning on their own.

If you do decide to jump in and use them though, it’s also important to know when not to use them, and when not to use other attributes as well. Consider the following button tag: <button role="button" tabindex="0">; the button tag implies its role (the same applies to all semantic elements), and is natively keyboard focusable, so doesn’t need a tabindex; it also lacks the type attribute which, while not essential, may be assumed to be different things by different assistive technologies: <button type="button"> and <button type="submit"> each indicate different things.

Some roles might also seem obvious, but aren’t. For example, at first glance, it might seem sensible to have a list of links inside a <div role="menu">, but the menu role is actually meant to indicate something like a context or options menu; it also communicates to the user that the focus states will be properly handled, meaning that arrow keys will let them navigate the links, that the escape key will close the menu, etc. So don’t risk communicating the wrong meaning to users that would otherwise rely on it.

Wrap It Up Already

I’ve not gone into too much specific detail here, and while the devil is sometimes in the details, the best way to learn more about the specifics is to actually do it for yourself. This post has been more about how to approach the task of making your work accessible. Hopefully you’ve seen that most of it is obvious; as long as you design for a good user experience, and write your code properly, you’re pretty much done. You may need a few extra tweeks here and there for areas with advanced functionality, but ultimately, if you’re approaching it properly, making your application accessible is the easy part.