Skip to navigation | Skip to main content | Skip to footer
Search the Staffnet siteSearch StaffNet
Search type

Web accessibility guidelines

We want as many people as possible to be able to use our websites – this is not only best practice but also a legal requirement.  The 'Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018' which came into force on September 2018 says that all University websites and mobile apps must:

  • meet accessibility standards (some content is exempt)
  • publish an accessibility statement that explains how accessible a website or mobile app is

Websites are required to comply with the new regulation by 23 September 2020 and mobile apps by 23 September 2021.

Accessibility standards

The best way to meet accessibility standards is to evaluate websites against the Web Content Accessibility Guidelines (WCAG) 2.1 and fix any issues you find. The following is a list of basic considerations to help you meet WCAG requirements (you can also access a more detailed explanation of accessibility principles in WCAG 2.1).

Tips for copy editors

Write text alternatives for images

  • The alt text should be concise: no more than a sentence or two.
  • Where you enter the alt text will depend on the CMS you are using (T4, WordPress, Campus Solutions etc.).
  • Think about whether the image informative, functional or decorative.
  • If the image is giving extra information to the user, put that same information into the alt tag so that it's available to people who aren't able to see the image. An example: "University students and tutors undertaking research in a pharmacy lab."
  • If the image is decorative, include the alt tag but leave it empty. The screen reader will then just skip it. (Note that standard T4 templates do not currently allow for the alt text to be left empty).
  • If the image is functional, then the alt text should describe the function. For example, the image might be used to provide a link to another web page. In this case, the alt text might be: "More information about …".
  • Don’t start your alt text with "The image shows …". The screen reader will automatically announce that it is an image.
  • Don’t use images of text. They can't be read by screen readers and won’t adapt to the user's preferred text settings (font size, colour contrasts). If you use text in a banner image, say, make sure the alt text provides the same information.

Explain infographics, graphs and charts

  • Infographics, graphs and charts often convey a lot of information. You may not be able to describe this in a concise alt text.
  • Use alternative means such as a caption or accompanying text to explain this information. Refer to the caption or text in the alt text.
  • If necessary, add a link to a different page with a longer description.
  • If using charts, include a link to the table of data.
  • In the case of infographics that contain a lot of text, provide a transcript.
  • Make sure you use colours that provide the best contrast.
  • If your graph has several different graph lines, don’t rely on colour to distinguish them. For example, use different symbols (squares, circles) to plot the points on the graph, so that people who are colour blind can still tell the lines apart.

Create transcripts and subtitles for audio and video

  • For audio-only content, such as podcasts, provide a transcript. For audiovisual content, such as marketing videos, provide subtitles. Transcripts and subtitles should also include references to all other sounds present (music, sound effects, etc) and non-spoken information that helps understand the overall content, for example "Two students are talking with their tutor in front of the Chemistry building", and so on. 
  • YouTube and the University portal provide automatic subtitles. These are a good starting point but will need to be edited before publishing.
  • See guidance for adding subtitles and other alternative media to video and audio.

Use headings to structure your content

  • Organise your content into sections with good headings. Avoid turning your web page into a 'wall of text'.
  • Headings must be organised logically. People using screen readers will navigate the page and find the information they want using the headers, and these must describe the topic and purpose of each section.  
  • Make sure your headings are set up properly using the built-in heading levels in your CMS. Remember to use H1 only once (for the main header) and follow with H2 for subsections which each can have nested subsections using H3, H4, etc.

Pay attention to the text styling and formatting

  • If you want to emphasise some text, use bold instead of italic or underline and don’t use heading styles (H1, H2, etc) to highlight important content.
  • Use the built-in list feature in your CMS when you want to create a list. Don’t use hyphens, for example, to suggest the items are part of a list.
  • Don't use tables to create the layout of your page or to position content on the page. Only use tables for showing data.
  • Use a clear sans-serif font, if you have the choice.
  • Use left-justified text instead of fully-justified text.
  • Avoid using ALL CAPS.
  • A font size of 16 point or equivalent is recommended in general, if you have the choice.

Make link text meaningful

  • Don’t use generic links like 'Click here' or 'Read more'. If a user is using a screen reader and calls up a list of the links on the page, these generic link titles will be of no use to them. An example of how to hyperlink text correctly would be: "Read more about accessibility guidelines"
  • The link and the link text alone should tell the user everything they need to know about where the link is taking them.
  • Make sure the link text is unique on your web page and that it makes sense by itself, without the user having to read the text around it.
  • You don’t necessarily need to say that the link will open in a new tab or window.

Keep content clear and concise

  • Keep your text simple.
  • Aim to use shorter sentences and simpler words with fewer syllables.
  • Be direct and use the active voice (‘We received your letter ...’ ) instead of the passive voice (‘Your letter was received …’).
  • Avoid jargon and abstract ideas.
  • Define any terminology and explain concepts.
  • Use images to break up the text.
  • Avoid writing instructions that rely on sensory information (shape, size, colour, location, sound). The user may not have access to this, or the page may look different to them. For example, don’t write things like: ‘Please pick one of the options on the right…’, ‘Click on the red square…’, ‘See the box below …’.
  • Aim for a reading age of 'lower secondary education', where possible, to make content available to a wider audience (this equates to 11-13 years old in the UK). An exception to this is where you are writing technical or academic text. 

Make sure your documents are accessible

  • Use the built-in features in MS Word. The best way to create accessible documents in MS Word is to use the built-in features whenever you can. This applies especially to headings and styles (Heading 1, Heading 2 etc.), but also to table of contents, bookmarks, page headers and footers, lists (bullets and numbering) and footnotes.
  • Accessibility Checker. When you have finished writing your MS Word document, use the Microsoft Office Accessibility Checker to find and fix any remaining accessibility issues.
  • Is PDF the best format? Before you convert your document to PDF, ask yourself if this is the best way to publish your content on the web. A web page will normally be more accessible than a PDF. A web page will also be mobile-friendly, which benefits all users.
  • Make your PDFs accessible. If you want to create an accessible PDF document, you need to start with an accessible source document, such as an accessible Microsoft Word document.
  • Use ‘Save as PDF’ or ‘Export to PDF’. Once your MS Word document is ready, convert it to PDF format using ‘Save As PDF’ or ‘Export to PDF’. Make sure the conversion options or settings are set to the appropriate values. If you use ‘Print to PDF’, your final PDF document will not be fully accessible.
  • For further details refer to more in-depth guidance provided on this site. Also, use the available guidance from Microsoft.

Content not within the scope of the accessibility regulations

We should endeavour to make content on our websites as accessible as possible. However, you might not need to fix the following types of content which are exempt from the accessibility regulations:

  • Pre-recorded audios and videos published before 23 Sep 2020
  • Live audio/video 
  • Heritage collections  for example, scanned manuscripts
  • PDFs or other documents published before 23 Sep 2018 (unless users need to access a University service)
  • Maps  you should provide essential information in alternative format like an address
  • Third-party content  this includes content you use on your websites that is under someone else’s control, for example social media 'like' buttons. This can also apply to third-party platforms that you use to host your content eg YouTube. In this case, we are responsible for ensuring the accessibility of the content we produce, however, we have no control over the accessibility of these platforms (please note we should be using accessible platforms as best practice).
  • Content on intranets or extranets published before 23 Sep 2019 (unless a major revision is made after that date)
  • Archived websites (if not needed to access a University service and they are not updated)

Accessibility statement

Each University website/mobile app will ideally publish a local statement that explains how accessible it is. Please download the statement template below, customise as needed and publish as HTML page on your website (for example

A link to the webpage with the accessibility statement is often placed in the footer of the website. For mobile apps, make sure the statement is in an accessible format and can be downloaded from the app store or a website.

If a website/mobile app has no local statement, it should still link to the University's general accessibility statement until one is published.

How users can raise an issue

The statement should include information on who to contact in case users need to report an accessibility problem.  If the website/mobile app already has a way to gather feedback from users, this could be used also for accessibility issues if preferred; otherwise, have a dedicated email inbox or add a contact form for this purpose. Example of email accounts can be:

  • (sample)
  • (sample)

Social media guidelines

We are not responsible for the accessibility of third-party platforms but, as best practice, we should make sure that the content we publish in those platforms is accessible. Please follow these guidelines for creating accessible content used in social media .

More information

For information on accessibility guidelines and further guidance please contact your Faculty/department digital team.