Writing accessible and inclusive content

People access our website(s) using a variety of different devices, from desktop computers, mobile phones, laptops, tablets to screen readers. This could also include people who use assistive technology instead of the standard mouse, keyboard and monitor setup. It is important that we create content that is accessible to the widest possible audience especially people with disabilities.

A disability might affect vision, manual dexterity, cognition or reading. It might be permanent, but anyone can be temporarily or situationally disabled (for example, the user accessing your website on their phone in bright sunlight, while holding a baby in their other hand has a very different experience from doing the same task relaxed at home on their laptop).

It's important that we don't discriminate against people being able to consume only some of our content. Being inclusive creates a good reputation and shows that we have high standards in business ethics. There are also legal obligations to provide an inclusive education under UK law including the Equality Act 2010 and the recent regulations for public sector websites.

The web team have built the structure of the website with accessibility in mind by creating templates using an inclusive design and user centred design process. Writing accessible content can also improve the experience for every user. It is the responsibility of content editors to create and maintain content that is accessible and inclusive to all users.

Headings and structure


Headings are the most important part of the page. Screen readers allow users to navigate between headings to find what they are looking for. Users rarely read a web page from top to bottom, but rather they scan headings to find the section they need.

Headings should be structured correctly. If this article was a web page, the heading hierarchy would look something like this:

  • H1 - Writing accessible and inclusive content
    • H2 - Headings and structure
      • H3 - Headings
      • H3 - Text
    • H2 - Language
      • H3 - Plain English
      • H3 - Directional language
    • H2 - Link text
    • ...

There should only be one h1 on a page. If you create a page in Ektron or Kentico, the h1 will usually be the same as the page title. This will be added to the page and wrapped in an h1. The highest heading you would add into content would be an h2. Remember:

  • Use headings levels to break up content and make it more scannable.
  • Keep headings short but concise.
  • Do not skip a heading level, for example, an h2 followed by an h4.
  • A good heading describes the content that follows.
  • Do not make a fake heading by bolding paragraph text.When writing your text, remember:


When writing text, remember:

  • put the more important information at the beginning of the content,
  • write short, clear sentences and paragraphs,
  • avoid using jargon or slang unless you a writing for a specialist audience, for example, medical research,
  • abbreviations can be confusing out of context, spell out the whole word, for example, instead of Jan, write January,
  • expand acronyms on first use, for example, Research Excellence Framework (REF),
  • provide a glossary of terms of users might not know,
  • use bold (strong) and italic (em) to emphasise strong importance to a part of a sentence, do not use an underline.


Use list formatting correctly. For example, choose an unordered or numbered list from the editor, and don’t create bullet points and paragraphs with breaks.

  • Bulleted lists (<ul>) inform screen reader users how many items are in the bulleted list.
  • Numbered lists (<ol>) inform the screen reader user how many items are in the numbered list and read the number for each item.


When creating a data table use headers for rows and columns to show the relationship to related cells. For more complicated data tables, related table headers should use the scope attribute to identify their relationship. Table captions can also be used to give screen readers a summary of the table contents. For simple data, use an unordered list instead.

<caption>Monthly budget</caption>
<th scope="col">Month</th>
<th scope="col">Amount paid</th>
<th scope="row">January</th>
<th scope="row">February</th>

Example of table headers with column and row scope


Plain English

Web content should be written in a simple and concise way, avoiding any jargon or slang. Use plain English if possible, unless you are writing for a specialist audience, for example scientific research. 

Group sentences into short sections. Sentences should be around 20 words at most.

Use tools like Hemingway Editor to measure the readability of your text. To meet WCAG standards, aim for a readability level of grade 8 and lower.

See the Oxford Brookes writing style guide for guidance on writing on style, spelling and grammar for the Oxford Brookes website and print communications.

Visual and directional language

Avoid directional and visual instructions that requires the user being able to see the page layout. For example, do not use ‘See blue box on the right’. This may also affect sighted users who are viewing a mobile layout.


Avoid unnecessary use of capitals. Text in all capital letters is more difficult to read for most people, with and without disabilities. Some screen readers read out uppercase text letter by letter, as if it were an acronym.

Link text

Link text should describe its purpose and destination. Avoid using ‘click here’ or ‘read more’. For example, instead of ‘book here’, use ‘visit our Open Day’. Also:

  • Do not use web addresses or URLs as link text. The screen reader may read out every word.
  • If a link leads to a new type of document not a web page, explain this in the link text. For example, ‘Student Protection Plan PDF’.
  • Do not open links in a new window. This may be confusing for people using screen readers. Tell your users when you are opening a new window. For example, ‘Campus addresses (opens in new window)’.
  • Avoid using the word ‘link’ in the link text, screen readers say ‘link’ before each link.

Images and other media


Alternative text

Alternative text, also known as ‘alt text’ benefits people who use screen readers as the text is read out for the image. This also benefits users when images fail to load and users who turn images off as the text is displayed instead. When writing alt text, remember:

  • the text should provide an informative description of the image,
  • only use an image if it supports the message in your text,
  • in an image that contains text, that text should be replicated in the alt text,
  • if the image is used as a link, the text should describe the destination instead,
  • if the image is purely decorative, the alternative text can be left empty (alt=””),
  • if a caption is used after the image, an alternative text may not be needed,
  • avoid using the phrases ‘image of…’ or ‘picture of …’


Infographics (diagrams, graphs, charts and other complex images) also require a text alternative. The text alternative should immediately follow the infographic.

Text in images

Text in images should only be used as a last resort. The text in the image should be replicated in the alternative text.

PDFs and Word

Avoid using Portable Document Format (PDFs) if possible, most PDFs are unlikely to be accessible and the process to make them accessible is difficult and time consuming. Try to include the content of PDFs as HTML (Hypertext Markup Language) as real text will also be picked up by search engines. If you still need to provide a PDF, for example if the document is for printing, the PDF must still be accessible. 

Here are some guides for creating accessible PDFs:

Microsoft Word documents are fairly accessible and can be read by screen readers and other assistive technologies. For Word documents to be fully accessible, follow these guidelines:

  • identify the document language,
  • use headings,
  • use lists,
  • use meaningful link text,
  • use alternative text for images.

Here are some guides for creating accessible Word documents:

Video and audio

Transcripts or captions should be provided for all video. YouTube does provide automated captions but you may have to edit these to correct errors. For audio-only provide a transcript. Add a link to the transcription or add the text below the video or audio. Do not autoplay a video or audio.

Captions also improve the experience for other users because:

  • anyone working in a noisy environment can read captions,
  • non-native language speakers can read captions in their own language,
  • students learning to read can follow along with the speaker,
  • students can see the spelling of terms that will be on a test.