Blurriness of Accessible Websites
Why is accessible design important?
One out of five people in the UK report having a disability, and yet 90% of websites are not compliant with even the lowest level of accessibility guidelines. 73% of people in the UK living with disabilities are unable to complete basic transactions on websites they visit, potentially losing out on a part of the $6.9 billion going to competitors with accessible websites.
This involves considering all the possible ways a person may interact with your application. Without thinking about accessibility, you could be forgiven for assuming that a mouse is the primary mode of input for some people without considering people with reduced mobility or dexterity. Similarly, you may assume that most people would always be reading from a screen. It stretches beyond just design, complicated language & jargon can impair usage of your experience for some people. Having an accessible & inclusive mindset means designing and developing your experiences to accommodate everyone, regardless of their needs.
These are all difficult considerations to have after the fact, it is essential that you have accessibility baked into your design & development process from the start to ensure you are offering inclusive and accessible experiences to all. Inclusive experiences are a moral and ethical duty designers and developers have, but in many parts of the world it is a legal necessity. Both Beyoncé and Domino’s Pizza have found themselves on the losing end of lawsuits for providing inaccessible experiences in recent years.
At Nye Health, accessibility & inclusivity is paramount to making the whole world well, whatever their needs. We are at the start of a journey to consolidate all our interface elements into a design system. This gives us a fantastic opportunity to bake accessibility into our application at a component level. Web browsers are already very powerful and expose a lot of accessibility features with little work on the part of a developer, and that makes me wonder about the ways we can harness that to provide a more inclusive experience.
How can you create accessible experiences?
Overview of WCAG
WCAG (Web Content Accessibility Guidelines) are a set of guidelines designed to improve web accessibility. It’s important to bear in mind that the internet is used by a diverse set of people, including those who have different varying mobility abilities and may not use a keyboard & mouse in the traditional sense; or those with different levels of vision and who interpret colours in different ways.
These guidelines range from: images should have descriptive text for those who cannot see the image, to web applications should be accessible from just a keyboard for those who cannot control a mouse, to reducing motion and flashes for those who are photosensitive. The guidelines go out much further and much deeper to encompass a wide range of needs.
Colour Contrast
Colour contrast is a widely known aspect of accessibility, and is often the one with the best compliance because it can be a quick win in the accessibility checkbox. However, it is more complicated than that, in practice. WCAG states that the contrast between the background and foreground colour should be 4.5:1 (or 3:1 when the text is “large”; large being over 18pts or 14pts when bold). However, it isn’t as clear-cut as that. Fonts with thin strokes, such as Raleway, require a higher (unspecific) contrast.
What I believe makes colour contrast so widely known is the ease of tooling around it. Build into most modern browser’s developer tools are easy ways to view if your design is compliant with these guidelines. There are also some automated testing tools, such as AXE, which fail when a design does not meet the WCAG guidelines.
Take this example with black text and a dark background, both as strictly speaking accessible as far as most automated or manual testing would have you believe, but are both equally readable?
I’ve deliberately picked an example to prove the point, however despite both being compliant in the eyes of automated and manual testing, it is clear that the second line is much clearer. You may be able to see both with no issues, but have you considered a person with low vision? This is an emulation of how they may see it.
People with low vision are those whose vision is not corrected by glasses, contact lenses, or surgery. This may range from a person who is unable to receive a treatment, to a short term or situational impairment.
Landmarks
A landmark is a common section of a webpage, such as navigation, or a search box. A landmark improves navigation for screen reader users who typically will navigate using the Tab key, or with their arrow keypad.
On large pages, it can involve a lot of pressing to travel a rather short distance. For example, on the BBC News website, it takes 39 presses of Tab to read the headline story once you break through 3 levels of navigation. But navigation by landmarks means it takes just 9 presses to get to the same headline story.
In typical visual design, there is a push to remove clicks, or to remove friction. Fewer clicks and less friction is a well-known mantra to improve conversion, but do you often consider other methods than clicks?
A landmark can be added to any HTML element with the role attribute with options such as navigation, banner, and main to choose from. However, if you write semantic HTML, you get it for free by using <nav> , <header>, and <main>. You should use landmarks when developing your website, but be cautious that overloading every section as a landmark is overwhelming and counterproductive.
There may be instances where you may have more than 1 of the same landmark, such as different levels of navigation, a perfectly valid pattern for larger sites. In these instances, it’s important to properly label your elements to help a user distinguish the difference between landmarks of the same type. Labelling an element is as straightforward as using the aria-label attribute with a short phrase to describe the purpose. Be careful however, as you cannot always count on a screen reader to speak the label.
How can you get started?
The number one place to start in my opinion is the A11Y Project’s checklist. A11Y is an abbreviation used to describe accessibility, 11 characters between the ‘a’ and the ‘y’. Their checklist follows the WCAG guidelines into a digestible format and can be used as a starting block on making your application more accessible. Each item corresponds to a “success criterion” — a specific and testable rule for your application.
You may wish to bake accessibility into your development process, and I suggest starting in your browser devtools. Many modern browsers surface accessibility information about the rendered elements, such as contrast colour and the computed aria labels, so you can understand what screen readers may pronounce.
I frequently test my code with real screen readers, there’s a bit of a learning curve to them, but I think that gives you a greater understanding on how others may use technology. Windows, MacOS, iOS, and Android all have their own built-in screen readers which are worth testing with when you can. NVDA and JAWS are also two popular Windows based screen readers that may interpret your code different, much in the same way you should test a visual design in different browsers.
I have found that there are limited automated testing options worth exploring. At Nye we use axe-core with our Cypress testing to catch some accessibility issues. Tim Deschryver has a really good article on setting that up. It is very important to stress that these automated tests aren’t foolproof. If you take the colour contrast example from earlier, that would pass a test on colour contrast, but it is clear one option is better than the other in that situation.
Conclusion
Accessibility is a fractal of learning. We are only looking at a small area of a broad specialisation. I would consider myself knowledgeable on the topic, but I know there’s much more I don’t know. Accessibility in your applications is more about having empathy for the people who are trying to use it. It’s creating an individual understanding of unique needs which differ from person to person, and being inclusive to the requirements of a broad range of people.
Building for accessibility is yet another challenge in web application development. Another, but critically important, topic to “master”.
Hello 👋 We’re Nye Health.
We’re a little gang of clinicians, scientists and engineers and we’re doing some big things. We’re starting by working with citizens, the NHS and clinical research teams, to develop products that bring us one step closer to making the world well.
We’re hiring right now! see our open roles at meet.nye.health/careers
