BETA This playbook is in BETA, we think it’s good enough to be useful right now, but there are gaps that need filling – your feedback will help us to improve it.

Introduction

Our web content and services need to be as accessible and as easy to use as possible. We have a legal obligation to make sure people can access the information we produce and publish. This includes users with visual, hearing, cognitive or motor impairments, as well as people with learning difficulties.

This section covers all content, both data-driven and editorial. We try to make sure that data is accurate and clearly presented and that the editorial content is evidence-based.

  • Accuracy – transparent, objective, impartial
  • Accountability – complaints, feedback, editorial process
  • Serving the public – putting user needs first
  • Privacy
  • Standards
  • Training
  • Quality assurance and sign off
  • Research
  • Review of content

Website accessibility

As a public sector organisation, the information we publish is of vital importance to our residents and businesses. So, we need to make sure that the information we publish on our website is as easy to access and understand as possible – for as many people as possible.

This includes people who have

  • Visual impairments – such as blindness, partial sight, or colour blindness
  • Deafness or other hearing impairments
  • Limited motor functionality
  • Cognitive or learning difficulties – GOV.UK aims for a comprehension level, or reading age, of 9 years
  • Limited or no understanding of English (It is important to note that as well as the many Somerset residents and workers for whom English is not their first language, many deaf people consider British Sign Language to be their first language, not English, written or otherwise.)

This is a vital aspect of our inclusivity and equalities obligations and is a legal requirement.

This means our websites, and the documents published on them, need to be

  • Easy to navigate and use
  • Designed with high-contrast, easily distinguishable colours, especially for text, buttons and interactive elements
  • Coded and formatted to work with assistive and adaptive technology, such as screen readers, braille displays, navigation aids
  • Styled to dynamically adapt to different displays and zoom levels, so that no functionality is lost on any device
  • Written avoiding the use of complex terms and obscure jargon. Content must be easy to understand for everyone, whatever their comprehension level
  • Avoid presenting information in exclusively visual styles – for example, diagrams must be explained with text, and videos must have subtitles or transcriptions
  • Machine-readable – for example, no images used as headings with text – and easily translated

The regulations that require us to meet these obligations to our audience are the ‘Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018’. This is an extension of our responsibility to people who have a disability as part of the ‘Equality Act 2010’. We are considered to have met these obligations if our website meets WCAG (Web Content Accessibility Guidelines) 2.1 AA accessibility standards.

How we monitor accessibility issues

Third-party tool(s) should be used to monitor websites for compliance with WCAG accessibility requirements. Examples of this include SiteImprove, SiteMorse and SilkTide. SilkTide is a preferred tool, as this is the tool used by SocITM, which produces the national accessibility report for local authority websites.

These tools will regularly scan the website’s content (including documents) and identify any issues that need to be addressed, breaking them down into lists of actionable issues to be addressed by developers and content editors as appropriate. Resolving issues identified in the reports produced by these tools provide the basis for an ongoing accessibility improvement and maintenance plan.

These reports need to be reviewed constantly, as every new piece of content, functionality, development, or ongoing evolution of a website can and will introduce new accessibility issues to correct. And often correcting one issue will have knock-on effects that will also need to be addressed.

It is therefore recommended that accessibility reports are reviewed monthly as part of Business-as-Usual operations, but they should also run and be responded to on-demand following any major website update – especially where large volumes of information have been added or new functionality has been introduced.

How we resolve website accessibility issues

Website accessibility issues can be divided into three separate areas

  • Code level/templates – resolved by developers
  • Content – resolved by web content editors
  • Documents – resolved by document authors*

*Although it is a document author’s responsibility to make sure that their documents are fit for publication, it is recommended that final documents are vetted by web content editors before being uploaded to the website.

Code level

The most complex accessibility issues are resolved by web developers at a code level. Accessibility reports provided by accessibility monitoring software will give detailed breakdowns of the steps developers need to take to resolve any issues that arise.

Content

Accessibility reports will identify exactly what issues need to be resolved by web content editors, but content authors also need to follow our house style and practices when producing content. See Making content accessible in WordPress for guidance for content authors on correct use of headings, links, images, tables and acronyms.

While accessibility monitoring software can estimate the reading comprehension age of our web content, only a manual check by knowledgeable officers will be able to determine if it is up to date and factually correct.

Documents

Website accessibility requirements also apply to any content accessed through the website. This means that any document that is published on the website also needs to meet website accessibility standards. But it can be difficult and cumbersome to apply accessibility fixes to a document that was not produced with web accessibility in mind after it has been published. Therefore, steps must be taken to make sure that all documents we publish are written with accessibility requirements in mind from the start.

As documents are often produced by officers who are not thinking about website requirements at the time of writing, it is highly recommended that web content editors with accessibility knowledge review documents before they are uploaded to the website.

It is highly recommended that all officers who produce documentation for the Council are trained in producing accessible digital documents regardless of whether those documents are intended for web publication or not – adherence to accessibility standards results in a better reading experience for all users, not just the people who need them.

There is a useful guide on writing accessible documents on the Worcester County Council website

Because of the large amount of work involved in making documents accessible, it should be considered that many documents could instead be web pages. As web pages can easily be monitored and any issues can be addressed by the web content team, this option can mitigate the impact of document authors having to manually assess their documents before they are published on the website.

Last reviewed: March 18, 2024 by Daniel

Next review due: September 18, 2024

Back to top