![](https://drupal.ampere.corrupted.pw/sites/default/files/images/color-pencils.jpg)
Accessible design - avoid the common pitfalls
November 12, 2023 | AccessibilityThere are a lot of accessibility pitfalls when it comes to design. Here are some thoughts and ideas for the most common ones I encounter in my work.
Start the design process in black and white
This is a tip I learned from a course a while back. When you start the design in black and white, you can also make sure your design works without colours.
And when you are done designing in black and white, then you can add the colours. This way you will test the design in black and white automatically. If you start with colours, you need to separately remember to test for black and white.
Aim higher than the minimum requirements for colour contrast
I've seen a lot of designers choose colours that just meet the bare minimum requirements. While this might be necessary with some company brand colours, do always outside of that aim a bit higher. I'm not telling you to always aim to meet the Web Content Accessibility Guidelines (WCAG) AAA requirement of 7:1 but aim a bit higher than just 3:1 or 4.5:1.
Also, always remember to check all your colour choices against all used background colours. In many cases, the same colours won't work with both dark and light backgrounds.
The user should be your main focus
I get that sometimes it is fun to be super creative and create all new and fancy-looking things. But often I unfortunately in these situations notice that the user experience has been completely forgotten. So make sure to design the site/product first and foremost for the users and then add visual nice features on top of that.
User interface design is important. It should come before the visuals because users and their user experience should come first. Don't reinvent common elements, use them as they are expected to be used.
Interactive elements should have clear hover and focus styles
Hover styles aren't required in the Web Content Accessibility Guidelines. Unless you add them, then those need to comply with the rules, e.g. colour contrast. But for many users, hover styles are what confirm that you can interact with the element.
Focus styles on the other hand are required in the Web Content Accessibility Guidelines. The focus style should be visible and clear enough on all backgrounds. You can use the browser defaults, but in their current state, they are less visible than properly designed custom styles. With focus styles, it's also surprisingly easy to meet WCAG AAA-level requirements. Two pixels wide solid outline with a bit of offset from the element itself should be enough.
And don't forget the default state of interactive elements. It should be visually clear if an element can be interacted with. Otherwise, it will be guesswork and you add a lot more cognitive load for the user.
Alternative colour schemes
Dark modes or dark variants have been around for a while now. But it is still quite uncommon on a lot of public sector websites, at least around here in Finland. There are a lot of benefits to darker colour schemes. First of all, allowing your user to choose between a lighter and a darker scheme makes the design more accessible. But also having a darker theme is more environmentally friendly. Darker themes consume less energy than lighter themes on mobile devices, at least that is what I've been told.
Consider if you should also provide your users with high-contrast modes. But often when a user wants these, they have the possibility of using their OS to increase contrast. On Windows machines that option is quite powerful and on Macs it seems to be a bit less that. Browsers do have some plugins for this functionality as well. So it might not be necessary to have these options on the sites, but is good to think about them as well.
Accessibility should never be an afterthought
Patching a finished design with accessibility is harder and more expensive than just having accessibility as a part of the process from the start.
Whenever possible, test the designs with actual assistive technology users and people with disabilities. That way you will get the accessibility feedback from the people who benefit from them the most. A lot of times I've seen multiple user personas created as a part of a design process. And sadly I've yet to see a person with disabilities amongst them. The only place where I've seen some user personas mention disabilities is the persona sets specifically designed with disabilities in mind. Let's try to change that, shall we?