Like many designers I’ve been awkwardly skirting the boundaries of accessibility for years; always keen to learn more but not really sure where to start. I regularly open the Web Content Accessibility Guidelines (WCAG open_in_new) but find them overwhelming complex. Kind of ironic, given they contain the principles to make products easier to use!
According to SCOPE, there are 13.9 million disabled people in the UK open_in_new. Many more people have a temporary disability like recovering from an injury or an illness. We tend to think of accessibility as helping people with physical impairments who use assistive technology like screen readers but this is not always the case. A person’s ability to use your product might be impaired by old technology or by their situation or environment. For instance, they could have a small baby, be in a noisy cafe or outside in bright sunlight.
Accessibility is about making sure your product can be used by as many people as possible. Make sure that no one is being excluded. As the nerdy kid who was always picked last for the rounders team I like this idea.
As a designer of products that help folks to manage their money, I realised I was doing a lot of customers a huge and frankly discourteous disservice by failing to appreciate their needs. I look back in horror at some of the light grey text and teeny tiny font sizes I subjected people to.
So I set myself a challenge to learn more about accessibility. Step 1: methodically work through WCAG guidelines and create myself a checklist of WCAG criteria which relate to design.
Isn’t accessibility just for developers?
This is laaaaazy designer thinking. By baking accessibility in from the start of a project you can iron out a lot of bumps before the product gets near code. Start by making small, sensible decisions about:
- Page layout and grid: Will text reflow if the screen is resized or if the device orientation is changed?
- Content order: Website content has to follow a semantic structure. Does your design have headings and content in the right order?
- Colours: Do the colours you’re suggesting have enough contrast alongside each other? Will these colours be meaningful for colour blind people?
- Navigation: Is it consistent across all screens?
- Placeholder text: Are you being thoughtful about the labels and error messages you write? Your little snippets of microcopy often carry through to the final product. Above all, it may cause inconsistencies or even embarrassment your team may suffer with for all eternity! ( I speak from experience here 🙂 )
Getting these small bits right in design will ultimately lead to a more accessible end product.
I’ve found the answer to those UI questions no-one ever seems to know the answer to
Working through WCAG guidelines also helped me answer lots of the silly little niggly questions I get asked as a designer that no-one on the team knows the answer to like…
Do disabled buttons need to be accessible?
Technically no (see WCAG 1.4.3 open_in_new) …I mean WTF?! If you are considering using a button with a disabled state read this excellent article on how disabled button suck open_in_new.
Does a focus state need to be different to a mouseover state?
Yes (see WCAG 2.4.7 open_in_new). A focus state needs to be different to the mouse hover state so sighted users can visually see a difference. Take that one, grumpy developer!
Is making a link coloured enough to indicate it’s a link?
Nope (see WCAG 1.4.1 open_in_new). In other words, don’t rely on colour alone to communicate meaning or to distinguish visual elements.
WHAT ABOUT TEXT IN ALL CAPITALS?
Not called out in WCAG 2.1, though guidance looks forthcoming in the Accessibility Requirements for People with Low Vision draft (see 3.3.4 open_in_new) “Text in all capital letters is more difficult to read for most people, with and without disabilities”.
You read right to the end? Congrats on being *almost* as nerdy as me!
My thinking came from these useful sources:
- Web Content Accessibility Guidelines (WCAG) 2.1 open_in_new
- Introduction to Understanding WCAG 2.0 open_in_new
- Understanding WCAG 2.1 open_in_new from the Government Digital Service
- Disabled buttons suck open_in_new by Hampus Sethfors on Axesslab.
- WCAG Accessibility Requirements for People with Low Vision open_in_new – Draft