The Public Sector Bodies (Websites and Mobile Applications) (No.2) Accessibility Regulations 2018 came into force on 23 September 2018. The regulations aim to ensure that all public sector websites and mobile apps are accessible to all users, especially those with disabilities. But while the regulations state that all UK service providers must consider ‘reasonable adjustments’ for disabled people, accessibility should simply be about being inclusive to all users.
At Mixd, we broke new ground in producing a website with a focus on accessibility for NHS Leeds Clinical Commissioning Group (CCG). One of the main goals was to develop a website catering to users with visual and hearing impairments or users with limited mobility.
One of the many challenges we faced was providing descriptive text for icons and defining whether they were decorative or not. Users without visual impairment understand the meaning of a button that has a picture of a magnifying glass on it but for a visually impaired user, their screen-reader software will usually only tell them there is a ‘button’ with no further information. At worst it will skip over it entirely as there is no text to read.
As designers, we often use icons to convey information and make navigation easier. For example, a simple calendar ‘icon’ is often used to distinguish something as an event.
But that’s not always the case as users often find icons confusing and difficult to understand. This issue was highlighted with our work for NHS Leeds CCG, as much of the content we were presenting was created or developed by medical professionals with limited design experience. We found they were looking to make their content visually engaging and would search online for stock graphics and icons. Many of the images and icons used were difficult to interpret. We set about simplifying the content and started to question the use of supporting graphics and images.
The accessibility aspect of icon design, ie the use of meaningful alt tags is also often overlooked simply because they’re such a visual element of the page and, for most users, easy to understand. Ultimately, extensive user testing and prototyping helped us build quickly, test what we had built and iterate our work based on regular feedback. We defined ‘decorative icons’ during the initial development phase and only used them for visual reinforcement. We implemented a simple test by removing the icon and verifying if users could still understand and use the page. If they could, then to a degree the icon would be considered decorative.
All developers should know about ‘image alt tags’, which are used to describe an image to someone who may not be able to see it. However, in the context of icons it isn’t always possible to use ‘alt tags’, so we took further steps to ensure all our users have an equally simple experience.
A good example of this with NHS Leeds CCG is mobile navigation menus. We are accustomed to the ‘hamburger’ menu but that doesn’t provide any description or instructions other than what is implied by the design pattern and is difficult to use if you cannot see it. Put simply, we followed the Web Content Accessibility Guidelines (WCAG) recommendation, using empty alt tags for icons considered decorative and ensuring the primary semantics of elements were not reliant on understanding what an icon means – ie there should always be a text description associated with an icon.
There is a legal requirement to make websites accessible to all and understanding these accessibility requirements is a vital skill for content editors. This is why we dedicate time to educate content editors and administrators on the importance of accessibility.
For example, do your content editors understand how disabled people use computers? The more you understand the types of disabilities that affect web and computer use, the challenges faced by those with them and the types of software and hardware they use, the easier it is to design for them.
We also found that for the majority of our NHS clients, the WCAG are really overwhelming and difficult to follow. It is all too easy to assume that all users can see and use a pointer interface like a mouse. Yet, with clear guidance and support, we can help all users access the content on a site.
Our accessibility audits assess conformance to each of the WCAG guidelines using a heuristic and qualitative review with accessibility and code validation tools to pinpoint specific errors. One of the automated tools we used for the Leeds CCG project is Lighthouse by Google. Lighthouse dictates that, when writing code, it is vital it is clean, lightweight and optimised. In this case, we used Lighthouse as a way of indicating that what we developed was performing to the highest standards. Once we completed our development, tests showed that the scores for Accessibility and Search Engine Optimisation (SEO) were exceptional (100 per cent).
We also use the accessibility checklist created by 18F (the US government’s digital agency) to help test for common accessibility problems, including:
However, a big concern while developing accessible websites is that automated tools only test a small portion of the WCAG specifications, so it’s important you strive to improve in a number of ways. Firstly, it’s worth taking your knowledge of UX and applying it to accessibility; the site may technically be compliant with the latest WCAG guidelines and recommendations but none of that matters if the user experience is poor.
Secondly, always try to include a bigger, more diverse group of users in an initial discovery phase. It sounds obvious but it is crucial that you understand the needs of those users and what common issues they struggle with while browsing the internet. Ultimately, you aren’t doing this to meet some arbitrary government requirements; you’re doing this because information is for everyone and access to that information should be as simple as it can be.