Website accessibility

All you need to know about the website accessibility legal requirements.

Background and scope

All the University of Edinburgh websites have to meet the University of Edinburgh’s responsibilities under the Equality Act (2010) and The Equality Act 2010 (Specific Duties) (Scotland) Regulations 2012 and level AA of the W3C recommended version of the Web Content Accessibility Guidelines.

This policy applies to any website using the ed.ac.uk domain (www.ed.ac.uk/something) or any subdomain (www.something.ed.ac.uk).

University of Edinburgh web accessibility policy

What is web accessibility?

Making a website or mobile app accessible means making sure it can be used by as many people as possible.

This includes those with:

  • impaired vision
  • motor difficulties
  • cognitive impairments or learning disabilities
  • deafness or impaired hearing

At least 1 in 5 people in the UK have a long term illness, impairment or disability. Many more have a temporary disability.

Accessibility means making your content and design clear and simple enough so that most people can use it without needing to adapt it while supporting those who do need to adapt things. For example, someone with impaired vision might use a screen reader (software that lets a user navigate a website and ‘read out’ the content), braille display or screen magnifier. Or someone with motor difficulties might use a special mouse, speech recognition software or on-screen keyboard emulator.

Government guidance on web accessibility

What do I need to do?

If you own or are thinking about developing your web presence within the University web estate, you will need to make sure that it complies with the regulations.

This means you will need to:

1. Write an accessibility statement and publish it on your website before 22 September 2020.

2. Test your website for compliance with accessibility regulations.

3. Fix any accessibility issues and errors.

How do I do it?

If you are using University content management system (EdWeb) or the Informatics version of it (InfWeb) then all of the above steps will be either done for you or the Comms Team will help you implement them.

Accessibility Guidance for Infweb Editors and Publishers

If you are using a different CMS you might want to check with your CMS provider how they tackle the accessibility within their code. See below for the WordPress policy and Google sites tips.

WordPress accessibility support

Make your Google site accessible - tips

IS guidance for creating accessible online content for websites, Wikis and blogs

If you are developing your own website, then you will be responsible for implementing the regulations.

If you are not sure which content management system you are using, please get in touch with the Comms Team and we will try to help.

Contact InfComms

Accessibility statement

If you are using EdWeb/InfWeb then the statement has already been provided (see below). If you're using a different CMS, your provider might have a template you can use. If you are developing your own website, you will have to write your own statement.

You can use a template provided by the government (below) or Nomensa Accessibility Statement Generator (also below).

You might also choose to attend the accessibility statement writing workshop provided by the University (register via MyEd).

EdWeb accessibility statement 

InfWeb accessibility statement (in progress)

Public sector website template 

Nomensa accessibility statement generator

POUR (Accessibility principles)

If you write your own code for your website, you have to observe the following principles (POUR):

  1. Perceivability – your website's users need to be able to perceive all the information on the website. That means that you need to, for example, use alt text/subtitles for your image/video content and the right colour contrast
  2. Operability – user interface components and navigation must be operable: that usually means ensuring keyboard-only access, no flashing/scrolling text, no time limits.
  3. Understandabilityusers must be able to understand the information as well as the operation of the user interface so you need to make sure you enabled error notifications and included an option of help (e.g. who to contact if there's an error on the website)
  4. Robustness – your content must be compatible with assistive technologies

Accessibility testing

You can automate the accessibility testing and if your website is included in the Informatics web estate (it needs to use the ed.ac.uk domain) we might be able to help you with that, however manual testing is recommended as available software is not robust enough. 

When you manually test your page, in the first instance pay attention to the following:

  • Make sure the text is clear, readable and consistent, and any technical words/abbreviations are explained
  • Make sure pages are clearly structured and the text is broken up by sub-headings
  • Make sure multimedia has alternative text – videos should have subtitles AND transcript ideally
  • The page title is descriptive
  • Use headings/subheadings in the right order
  • Provide sufficient colour contrast
  • Allow text to be resized (up to 300% typically)
  • Provide visible keyboard focus (so can navigate using tab)
  • Mark up forms, labels and errors
  • Make sure any moving/ flashing/ blinking media is user-controlled NOT automatic
  • Conduct a basic structure check that makes sense

Guidance on doing the basic accessibility check

Useful links

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018

Web Content Accessibility Guidelines (WCAG) 2.1

University guidance on the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations (EASE password required)

EdWeb accessibility statement browser guide (updated every 6 months)

Accessible technology for students and staff

Government guidance - Understanding accessibility requirements for public sector bodies

Public sector website accessibility statements - what you need to know

Reporting an accessibility problem on a public sector website

Case studies of disabled users to consider during testing