NHS Website Accessibility Audit
We have been working with a clinical commissioning group in the NHS. They approached us because they were aware that their website had some limitations and were concerned about how accessible it was for visitors with accessibility needs. The website was built in WordPress and the template was used by several hospitals that fell under their remit. The idea was that if they were able to improve the accessibility of this website, the template could be rolled out across the other hospitals, allowing each one to benefit.
To complicate matters, the website itself had been built by another agency. The agency we worked with had secured the contract to maintain and improve the existing website. Every web designer tends to have their own particular way of coding and it can be challenging to pick up and develop someone else's code, particularly if there is little or no documentation. When it comes to a website accessibility audit however, we are not concerned with how a website is built or with which coding language. Websites generate code that is displayed in a browser (such as Chrome or Firefox) and it is this generated code that we audit.
Our process always begins with an evaluation of the home page and an overview of the website. We always run the site through the automated metrics to see how it performs. Follow this link if you would like to learn more about automated metrics.
There were 13 accessibility errors on the home page. An example of this was how the Alt Tag was used with an image. An Alt Tag is what is read out by a screen reader and it describes an image for those who cannot see what the image actually is. However, in many cases, the Alt text was the same as the image filename and that conveyed no meaning. There were missing links and parts of the screen where the text was very difficult to distinguish from the background. The description tag was missing from the images, which is problem for search engines, there were coding issues, such as the H1 tag being used more than once and so on.
Issues such as this can be resolved fairly quickly but, when we turned to the manual checking, we discovered that were more severe issues, as is often the case. To list some examples:
- The slideshow contained a montage of badly cropped images, which were obscured by a text banner. There was also a large amount of text on this image that could not be read by a screen reader, as there was no Alt Tag
- An accessibility plugin had been used on the website, which allowed visitors to choose options such as text size and color contrasts. Unfortunately these options were not reachable via a keyboard and it was halfway down the screen and on the left hand side, so it would not have been picked up by someone using a screen magnifier.
- The navigation was duplicated and the skip link, which allows visitors to skip a section on a website, was only available after they have gone through the entire navigation menu on the website
- There was no Text Only version of the website offered
- Frequent use of the C word. "Click here" rather than "Follow this link"
- The Navigation menu failed the Tab Test
- The incoming Twitter feed was very long and impossible for someone using a screen reader to avoid
- Key hospital phone numbers on the web page were not read out by screen readers
- There was an incorrect use of Header tags (H6) to display these phone numbers
- There were no useful skip menus
- There was no site map
The automated metrics could, for the most part, be resolved fairly quickly but the issues raised by the manual checks are going to take much longer. However, this is why the website Accessibility Statement is so important because it is their opportunity to explain to visitors to the website what these issues are and to offer alternative ways of finding out the information, thereby protecting them from litigation.
If you would like to talk to us about how we may be able to assist you with an accessibility audit of your own website, please follow this link to book yourself in for a free 15-minute consultation.