Skip to main content

Making content accessible

This page highlights the different barriers users might face, which will impact on how they can access the service or information they need. We will look at the ways you can design for accessibility, making sure the maximum number of people can access content in the most efficient way possible. 

Accessibility should be embedded within all the work that we’re doing. It should be something that’s considered from the start. It’s not a bolt-on that we add at the end. 

Please watch in YouTube for more accessibility options. - opens in a new tab

About accessibility

Web accessibility is a way of designing websites, tools, and technologies so that everyone, can use them as easily as possible. Make sure that nobody is excluded, if you do not make your websites or apps accessible, you may be breaking the law.

There are a range of different needs to consider when building or enhancing a website’s accessibility:

""

Blindness and impaired vision

""

Deafness or impaired hearing

""

Motor impairments

""

Cognitive and neurological conditions

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

People with cognitive disabilities represent the largest number of internet users with disabilities. Because these types of disabilities contain a wide range of nuanced conditions and an even wider range of severity, it is difficult to present a comprehensive set of accessibility standards. From a web content design perspective, it is better to focus on removing barriers to improve the user experience.

The concept of accessibility does not just apply to people with disabilities - all users will have different needs at different times and in different circumstances, including a temporary disability. Someone’s ability to use a service could be affected by their:

  • location - they could be in a noisy café, sunny park or area with slow wifi
  • health - they may be tired, recovering from a stroke or have a broken arm
  • equipment - they could be on a mobile phone or using an older browser

Some more examples of permanent, temporary, and situational impairments:

Vision    

blind, cataracts, eye irritation 

Hearing

Hearing impairment, ear infection, in a noisy cafe

Motor    

Parkinson’s disease, arm in plaster, on a moving train

Cognitive    

memory issues, medicine side-effects, stressful situations

All of your users may potentially have an accessibility need at one point in their life. Designing content in a way that helps them access it will make sure that nobody is excluded.

Accessibility tools are built into software and products for people that need them. You may not have used them, but knowing they exist is important. These tools can reuse and present information in alternative ways. The user is in control of their settings, which is a key element of digital accessibility.

We have found tools and plugins we could add to our site don't get used (like a read-aloud function). This is because a user will already use what tools and settings they have. They are then able to control, their experience across multiple websites consistently. For example:

  • Operating systems - Microsoft Windows has 'Ease of use' settings. ‘Ease of use’ includes; display, pointers, magnifier, colours, high contrast, narrator (text to speech), speech to text, audio, captioning, keyboard controls, touch controls, language settings.
  • Software - A web browser (Edge, Chrome), a document reader (adobe reader, doc viewer) or Microsoft 365. These include similar options to the operating system ones.
  • Hardware - Some users may have very specific software, hardware or add-ons that meet their needs. For example, Jaws screen reader, eye motion controls, dragon voice command software, Sip and Puff switches, braille translators, pointing wands.

New regulations on accessibility came into force for public sector bodies in 2018. They say you must make your website or mobile app more accessible by making it ‘perceivable, operable, understandable and robust’.

Your website will meet legal requirements if you:

  • meet WCAG 2.1 AA accessibility standard - although there may be valid legal reasons for not meeting accessibility standards
  • publish an accessibility statement that explains how accessible your website or mobile app is

Whether web accessibility has been on your mind for a while or is something completely new to you, there is no doubt that it is no longer a nice-to-have but a must-have.

  • pre-recorded audio and video published before 23 September 2020
    live audio and video
  • heritage collections like scanned manuscripts
  • PDFs or other documents published before 23 September 2018 - unless users need them to use a service, for example a form that lets you request school meal preferences
  • maps - but you’ll need to provide essential information in an accessible format like an address
  • third party content that’s under someone else’s control if you did not pay for it or develop it yourself - for example, social media ‘like’ buttons
  • content on intranets or extranets published before 23 September 2019 (unless you make a major revision after that date)
  • archived websites if they’re not needed for services your organisation provides and they are not updated

You’ll need to explain in the website accessibility statement that you’ve not made things like this accessible because they are exempt.

Web Content Accessibility Guidelines (WCAG)

WCAG is an internationally recognised set of recommendations for improving web accessibility. They explain how to make digital services, websites and apps accessible to everyone. Web Content Accessibility Guidelines (WCAG) 2.1 is based on four design principles. The principles apply to all aspects of digital delivery (including coding, site design, content and interactions).

Below, you will find some specific ideas and suggestions for how you can make sure your page content is perceivable, operable, understandable and robust.

Please watch in YouTube for more accessibility options. - opens in a new tab

To meet WCAG 2.1 Principle 1: Perceivable you need to make sure users can recognise and use your service with the senses that are available to them.

This means you need to do things like:

  • provide text alternatives (‘alt text’) for non-text content
  • provide transcripts for audio and video
  • provide captions for video
  • make sure content is structured logically and can be navigated and read by a screen reader - this also helps if stylesheets are disabled
  • use the proper markup for every feature (for example, forms and data tables), so the relationships between content are defined properly
  • not use colour as the only way to explain or distinguish something
  • use text colours that show up clearly against the background colour
  • make sure every feature can be used when text size is increased by 200% and that content reflows to a single column when it’s increased by 400%
  • not use images of text
  • make sure your service is responsive - for example to the user’s device, page orientation and font size they like to use
  • make sure your service works well with assistive technologies - for example, important messages are marked up in a way that the screen readers knows they’re important

To meet WCAG 2.1 Principle 2: Operable, you have to make sure users can find and use your content, regardless of how they choose to access it (for example, using a keyboard or voice commands).

This means you need to do things like:

  • make sure everything works for keyboard-only users
  • let people play, pause and stop any moving content
  • not use blinking or flashing content - or let the user disable animations
  • provide a ‘skip to content’ link
  • use descriptive titles for pages and frames
  • make sure users can move through content in a way that makes sense
  • use descriptive links so users know where a link will take them, or what downloadable linked content is
  • use meaningful headings and labels, making sure that any accessible labels match or closely resemble the label you’re using in the interface
  • make it easy for keyboard users to see the item their keyboard or assistive technology is currently focused on - this is known as ‘active focus’
  • only use things like mouse events or dynamic interactions (like swiping or pinching) when they’re strictly necessary - or let the user disable them and interact with the interface in a different way
  • make it easy for users to disable and change shortcut keys

To meet WCAG 2.1 Principle 3: Understandable, you have to make sure people can understand your content and how the service works.

This means you need to do things like:

  • use plain English
  • keep sentences short
  • not use words and phrases that people won’t recognise - or provide an explanation if you can’t avoid it
  • explain all abbreviations and acronyms, unless they are well known and in common use - for example UK, BBC, VAT
  • make it clear what language the content is written in, and indicate if this changes
  • make sure features look consistent and behave in predictable ways
  • make sure all form fields have visible and meaningful labels - and that they’re marked up properly
  • make it easy for people to identify and correct errors in forms

To meet WCAG 2.1 Principle 4: Robust, you must make sure your content can be interpreted reliably by a wide variety of user agents (including reasonably outdated, current and anticipated browsers and assistive technologies).

This means you need to do 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
  • lets the user return to what they were doing after they’ve interacted with the status message or modal input (new window, form, screen layer).

Making website content accessible

Making website content accessible should be a part of the content design and writing process from the start, not something that is thought about afterwards.

Further information about how to make website content accessible is available in the content design and structure and website style guide pages within this playbook.

You also need to ensure downloadable documents are accessible. Information on making documents (downloads/PDF's) accessible.

Social media content

All the principles for accessible digital/online content apply to social media. But as a third party you will rely on the tools of those of the platforms and creating quality content. Any social media platforms should have a help page and accessibility information.

Main tips for social media posts

Whenever possible, use simple language and short sentences. Longer statements can be harder to follow or understand. Use sentence case, not capital letters to make it easier for people with cognitive and learning disabilities.

Users will interact with your post in their own language (set on their system). Plain English will translate well.

Capitalise the first letter of each word when you use hashtags. For example, use #SchoolAdmissions instead of #schooladmissions.

This will enable screen readers, to pronounce hashtags properly.

Avoid creating emoticons using text. In this example, this visual experience of “shruggie” ¯\_(ツ)_/¯ will be read aloud by a screen reader as: “Macron, backslash, underline, katakana, underline, slash, macron.”

Official Emojis displayed on a screen will be described by a screen reader. The 😊 emoji, for example, will be read aloud as “smiling face with smiling eyes.” Please be considerate of screen reader users by using emojis sparingly and by placing spaces between them.

Add a brief text description for images you share, known as alt text. Try not to duplicate alt text with content already in your image captions, or post descriptions.

Avoid image with lots of text within them - where text is used within an image make sure there is high contrast between text and image and include the text in your alt text.

Strong visual patterns, including strobing, flickering, flashing and animation, can cause issues for some users. To avoid this, make sure your Gifs flash no more than three times per second and run for only three seconds before ending.

Include a text transcript with your audio recordings. In addition to people with hearing loss, transcripts are useful to people in a noisy environment. Or if they don't have time to wait for the audio to run through - with a transcript they can scan and pick out the relevant information.

A good transcript includes descriptions of sound effects and other noises, and references who is speaking.

Transcripts are easy to create. they are just a plain text version of what is being spoken in the audio. Youtube will also generate this automatically, but always check for accuracy.

Watch this Youtube video to find out how to change your caption settings.

Further reading and knowledge to ensure accessibility requirements are met

Making a website accessible involves a range of roles from website provider/developer to site owner/s to anyone who edits and creates content. But everyone should have a good understanding of their own role, and those of others in creating accessible content.

Site owners / commissioners should also have a good understanding of the bullets below, audit their site regularly, have a plan to fix issues and update the accessibility statement:

Tools for both site owners and authors

Manually testing a page from a users perspective, is also important in making content accessible.

A way to check your website for accessibility issues is to invite people with a range of disabilities to interact with it while you observe and collect feedback. It is important to keep in mind that feedback from one person with a disability does not apply to all people with disabilities. You should understand the range of disabilities you will be planning and testing for, as you might need assistive technology prepared for your testers.

Commissioning Sure Trust could be an option for user testing.

Please watch in YouTube for more accessibility options. - opens in a new tab

If you have any questions about these guidelines or how the accessibility regulations may affect your service area, or to access Siteimprove software contact the website team.

Email: infoservices@cambridgeshire.gov.uk

Enforcement

The Equality and Human Rights Commission (EHRC) in England, Scotland and Wales and the Equality Commission for Northern Ireland (ECNI) in Northern Ireland will enforce the requirement to make public sector websites and mobile apps accessible (making them perceivable, operable, understandable and robust).

Organisations that do not meet the accessibility requirement or fail to provide a satisfactory response to a request to produce information in an accessible format, will be failing to make reasonable adjustments. This means they will be in breach of the Equality Act 2010 and the Disability Discrimination Act 1995.

The EHRC and ECNI can therefore use their legal powers against offending organisations, including investigations, unlawful act notices, fines and court action.