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

Accessibility reports provided by Silktide will identify many issues that need to be resolved by web content editors, but as content editors, we must also follow the house style standards described here.

Headings

Headings must be nested in the correct order. For content editors, this means: 

  • We never use Heading 1 – this is reserved for the page title. 
  • We never use Heading 2 or 3 – these are reserved for navigation elements and content block section headings. 
  • Heading 4, 5 and 6 can and should be used by content authors to create subheadings within content blocks. These must be nested in numerical order; 4 at the top level, 5 within 4, and 6 within 5. 
  • We do not make sub-headings by simply making text bold; bold is used for emphasising text, and is not identified as a heading by accessibility tools.

Images

  • Images must have alternative text. We make this accurate and descriptive.  
  • We do not use acronyms in alt text. 

Image Alt text example

A crowd of people at Glastonbury Tor having picnics on a sunny day.

  • Insufficiently descriptive Alt text: “Glastonbury Tor.”
  • Descriptive Alt text: “A crowd of people at Glastonbury Tor having picnics on a sunny day.”

Further guidance on image use is available here: Images

Language

  • Plain English must be used. We avoid long words, specialist terms and jargon. We use short sentences and break up paragraphs into easily digestible chunks. We aim for a reading comprehension age of 9, and while this cannot always be achieved for some content, we must do what we can to make all content as easy to understand as possible.
  • We eliminate all spelling or grammatical errors. 
  • We make sure information must be up-to-date, factual, and easy to understand. 

Tables

  • Tables are not easily processed by accessibility tools, and therefore should be avoided if possible; we only use them to present data, not for laying out text consider if text content could instead be presented using headings and paragraphs.
  • Where we do use tables, they must have summary text
  • We must define heading rows and columns using the appropriate table settings, not by simply making the cell content bold.  

Acronyms

  • Acronyms must use the acronym tool (which defines the acronym for screen readers) to be accessibility compliant. 
  • To mitigate this issue, we use acronyms as little as possible.  
  • A better and easier approach is to simply not use acronyms at all; we instead write the name of the subject out in full every time. (For example, the Department for Environment, Food and Rural Affairs instead of DEFRA.) As well as being more accessible, this is simply more user-friendly for all readers, most of whom will not recognise or understand the acronym and will not look at the tool’s definition. Acronyms are a carry-over from print publication, where page size and character limits had to be considered – this does not apply to web pages, where no such limitations exist. 
  • We only use acronyms where the acronym itself is the recognised public name of the thing, such as
    ,
    or
    , but even then, the acronym tool
    must be used to define them. A list of acronyms we do use is available to the content team; all acronyms not on this exceptions list should be written out in full instead. 
  • We must not use acronyms in page titles, page descriptions, section headings, or alt text, where the acronym tool cannot be used. 

Summary

While accessibility monitoring software such as Silktide can measure accessibility compliance and estimate the reading comprehension age of our web content, only a manual check by knowledgeable officers will determine if it is up to date, makes sense and is factually correct.

Last reviewed: March 18, 2024 by Daniel

Next review due: September 18, 2024

Back to top