Web accessibility allows everyone, including people with disabilities, to perceive, understand, navigate and interact with our content.
Our aim, as an inclusive institution, is to achieve and maintain a minimum of AA compliance with the Web Content Accessibility Guidelines, known as WCAG 2.1. These guidelines are an internationally recognised set of recommendations that explain how to make digital services, websites and apps accessible to everyone.
There are 14.1mil disabled people in the UK.
Impairments we should consider as content creators:
Includes those that are severely sight impaired (blind), sight impaired (partially sighted) or colour-blind people.
Also consider situational barriers – if I am outside using a mobile device I may have a problem viewing content on my screen. Audio communications can help here.
Includes people who are deaf or hard of hearing.
Also consider situational barriers – if I am on a train without my headphones, it’s unlikely I can consume video content. Written alternatives can help here.
Includes those who find it difficult to use a mouse or keyboard.
Thinking and understanding
Includes people with dyslexia, autism or learning difficulties.
Accessibility guidelines in action
By focusing on principles – not technology – we emphasise the need to think about the different ways in which our diverse audiences interact with content. So, the guidelines on this page are based on our four design principles for ultimate accessibility:
- Perceivable – We need to make sure users can recognise and use our website with the senses available to them
- Operable – We must make sure users can find, navigate and use our content, regardless of how they choose to access it
- Understandable – We must make sure people can understand our content and how we work
- Robust – We must make sure our content can be interpreted reliably by a wide variety of user agents (including reasonably outdated, current and anticipated browsers and assistive technologies)
In this section
- Working with images
- Titles, headers and page structure
- Working with video and audio
- Colour and contrast
Working with images
Images are inherently inaccessible to people who are unable to see them. To make sure all of our users can consume our visual content we must provide a text alternative.
For each image, determine which of the following categories best describes your image:
- My image conveys simple information (e.g. a photograph, icon or logo)
- My image conveys complex information (e.g. a chart or graph)
Avoid images with text in them
As images are inaccessible to some users, they’re unable to consume any copy within your image. Flat images cannot be accessed by screen readers so this copy must be housed within the page itself. Avoid using images of text unless it is absolutely necessary, for example a logo or brand.
- Note: Search engines will crawl your content in much the same way as assistive technologies and key information won’t be picked up in a page crawl if it is within an image
My image conveys simple information
Images that convey simple information must be described with alternative text, or ‘alt tag’. An alt tag is a short description of the content of the image, added in a way that is typically invisible to people who can see the image, but is exposed to people who are using assistive technologies, such as screen readers or Braille displays. Browsers also display alt tags visibly if an image fails to load.
The description should convey the content of the image as concisely as possible to provide access to the content of the image without burdening users with unnecessary details.
My image conveys complex information
Complex images, such as graphs, charts or diagrams, can contain too much information to be effectively described using an alt tag. Instead, you must provide the user with a plain text alternative or long description.
A long description is a more detailed description that provides equivalent access to the information in the image.
- Question: What information is this image intended to communicate? That same information must be provided to people who are unable to see the image
- Question: Is a visual representation of your information necessary to communicate your content, or will the long description serve all audiences?
A long description can include any structure necessary to communicate the content of the image, including headings, lists and data tables. This must be accessible to all audiences.
Titles, headers and page structure
Make it easy for users to source the information they need by presenting your content in digestible chunks. Breaking up content using meaningful headers makes it easy for users to scan a page to find the information they are looking for; this is particularly helpful for audiences with cognitive or learning disabilities.
Providing an informative title
Web pages and documents should have titles that describe their purpose or ‘promise’. This is helpful for all users, but is especially helpful for blind users, as the title is typically announced by screen readers as soon as a new web page is loaded in the web browser or a new document is loaded in the reading application.
Remember that users may land directly on our web pages and it will not always be clear what section of our site they are in. Page titles such as ‘Welcome’ or ‘Contact us’ may not be helpful without additional context.
Using meaningful headers
Just as page titles do, section headers should also describe their purpose or ‘promise’. Make sure to be clear to a user what to expect from that section as headers are also key indicators for those using a screen reader. Section headers such as ‘How to find us on campus’ or ‘Information about fees and funding’ are helpful here.
Structuring content using headings
Headings are ordered <h1> to <h6>. Use headings hierarchically, with the <h1> representing the most important idea on the page, and subsections organised with <h2> level headings. Those subsections can then be divided with <h3> level headings, and so on.
It is best to plan out a heading structure before composing a page. Doing this will help you both select appropriate heading levels and keep your content organised overall.
All pages should at least have a <h1> level heading giving the title of the page. We have built our web components to adopt the right kinds of headers in your web pages but you may want to think about which headers you use in other materials you are responsible for.
I am a h1 page title - i tell you what this page is about
I am a H2 header - i help to section off the page so you can easily find the information you need
I am a H3 sub header - I help you navigate within page sections
Note: Users will adopt an F-shaped pattern for reading web content and skim much of the content in your page. Whatever page it is and whatever the page is offering, the first few sentences are always the least skimmed. Make sure to be clear about your offer here.
Working with video and audio
Video captions and transcripts
Users with hearing impairments will need to have an alternative way of consuming video content so we must provide captions and transcripts if possible.
YouTube will automatically add captions to videos but you must review these for accuracy as they are not always perfect.
If you are using audio content such as podcasts to communicate information, it is essential that you provide a transcript of your recording for users who are unable to hear.
colour and contrast
Some users have difficulty perceiving text if there is too little contrast between foreground and background. To make our content perceivable for all audiences, specific contrast ratios must be met.
Our website has an embedded design system which has been tested to meet these requirements. Please do not use alternative colour in text or images on the website without authorisation from our university’s digital or creative team.
The importance of colour contrast applies across all of our digital and printed collateral so you will need to apply this in your content. You may find the WebAIM online colour and contrast checker helpful.
In this section
- Navigation and page structure
- Call to actions - links and buttons
Navigation and page structure
We should always provide ways for our users to navigate our content with ease. For some users, page navigation is done through the use of a keyboard or assistive technologies. Thinking about page structure and using the appropriate headers can help our users jump from one section to another.
See ‘Titles, headers and page structure’ under ‘Perceivable’ for more information about structuring your content effectively.
Using page anchor navigation
Structuring our content using headered sections will also allow us to add anchor navigations or ‘jump to’ links to our pages, helping our users to easily and quickly find the information they are looking for. This is particularly helpful on pages with lots of information to convey, which can be overwhelming for some people.
Call to actions - Links and buttons
Link text should be unique within a page, concise, should be meaningful when read out of context, and should help users to know something about their destination if they click on it.
Link text such as 'Click here' and 'Read more' fail to meet accessibility criteria.
This is particularly important to those using assistive technologies:
- Screen reader users can generate a list of links and navigate them alphabetically - ambiguous link text such as 'More' is not helpful in this context
- Users of speech recognition technology can select a link with a voice command like 'click' followed by the link text. So it is also helpful to use unique link text that is short and easy to say
- For more information on using meaningful link text click here - Is not correct
- For more information on using meaningful link text visit our anchor text guide - Is correct
In this section
- Keeping it simple
- Scentences and paragraphs
- Acronyms and abbreviations
Keeping it simple
Use plain English
Never use a long word when a short one will do – using plain English isn’t about ‘dumbing down’, it’s about ‘opening up’ – it’s not always that your users need simpler language, it just makes the journey from eye to comprehension shorter.
Copy should be as transparent and simple as possible. This is particularly important with microcopy – labels, opt-out messages, etc.
No jargon, slang or internal terms.
SENTENCES AND PARAGRAPHS
Simple sentence structure – lots of ‘if’, ‘and’, ‘but’, ‘because’, ‘as’ in your sentence means too many concepts in that sentence.
Aim for 20 words max. per sentence – the user’s eye will bounce over words to get an overview of the sentence’s meaning. Keep sentences short so your readers understand the sentence quickly and easily before moving on. Sentence length should still be varied to add interest.
4 sentences max. per paragraph – for online content, large blocks of copy make users jump ahead – they avoid reading your copy unless they absolutely have to in order to achieve their goal – keep to the point.
1 idea per paragraph – it helps your user’s scanning, bouncing eye to quickly grasp the overall meaning of each paragraph so they can build up an understanding of the page.
4 paragraphs max. per subheading – the same principle as above – by simply scanning your subheadings alone, a user should be able to get an idea of what you’re saying.
ACRONYMS AND ABBREVIATIONS
Unfortunately there is no one solution for users using screen readers when it comes to acronyms and abbreviations. Different screen readers may interpret words differently and users will apply their own settings on each device. Best practice is to write good content for all audiences.
- Avoid using abbreviations
- Spell any acronyms out in full at first reference. If it’s repeated later in the text, add the acronym in brackets, for example, The Arts and Humanities Research Council (AHRC)
- Make sure to use capital letters for acronyms as screen readers will spell this out. For example ‘UK’ will be spoken as in person but if we use ‘uk’ then it will say something like ‘uck’
Easy to interpret
We must make sure our content can be interpreted reliably by a wide variety of user agents. This means doing things like:
- Use valid HTML so user agents, including assistive technologies, can accurately interpret and parse content
- Make sure your code lets assistive technologies know what every user interface component is for, what state it’s currently in and if it changes
- Make sure important status messages or modal dialogs are marked up in a way that informs user of their presence and purpose, and lets them interact with them using their assistive technology
- Let the user return to what they were doing after they’ve interacted with the status message or modal input
This principle is only relevant to our university's central digital team’s work.
If you can't find what you're looking for or need some extra advice, we're happy to help.