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
Rejecting documents
If a service requests that a document is added to the website and it does not meet the following criteria, it must be rejected. Explain to the service why the document is not appropriate for use on the website and advise them on how they can make it more user friendly.
- The document must not be a scan.
- Only documents that were created electronically should be published on the website.
- Scans (or photographs!) of letters or maps are not machine readable – while applying Optical Character Recognition can help to make scanned text machine readable, it will not resolve the rest of the accessibility issues that come with scans.
- Images of text must not be used as headers.
- Only properly formatted, plain text headers must be used.
- Headers must be meaningful and used to clearly break up relevant information.
- Images are not information.
- We do not publish infographics or posters – information presented in these should just be part of the text content of the page itself.
- Illustrative images (including photographs) within a document must not be the only source of information – the content of the image must also be described in text in the document. This includes diagrams, graphs and maps!
- The document must be written in plain English.
- Just like our web pages, documents must be written using language that all audiences can understand.
- Jargon and abbreviations should always be avoided.
- Plain, familiar language should be used and irrelevant information should be excluded.
- Acronyms must always be defined.
- This is especially important in a document, where a popup tooltip is not an option if printed out!
- Lists must be formatted
- Bullet points or numerical lists should be used when listing information.
- Somerset Council branding must be used.
- If the document has old legacy council branding, or no branding at all, it must be updated to use our current brand identity. Our officially recognised corporate layouts, fonts and logos must be used.
- Templates are available if needed, and the service should be directed to the Communications team for guidance on any brand identity issues.
- No forms should be documents.
- If a service asks for a form to be added, this should instead be turned into an digital webform.
- Depending on the size and complexity of the form, this may need to be programmed in as a sprint task.
- Only certain file types are acceptable.
- We publish documents as PDFs, and the service must provide their document in this format.
- Raw data can also be published as a CSV.
- Adobe Acrobat’s accessibility checker should be used to pick out any major problems with a PDF. However, please note that this is not completely reliable.
- File size should not exceed 20MB.
- We do not upload FAQs.
- If a service asks for an FAQ to be added, this suggests that the information in the pages themselves is inadequately explained. Recommend that the content is reviewed and information gaps are addressed.
- No documents that could instead be web pages.
- Because of the large amount of work involved in making documents accessible, it should be considered that many documents could instead be web presented as pages. Web pages can more easily be monitored, and any issues can be addressed by the web content team, which can mitigate the impact of document authors having to manually assess their documents before they are published on the website.