Making content accessible

Some 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.

When designing content, you must aim to meet the needs of everyone. This is to ensure that someone who has a disability is not excluded. But what does it mean for you designing content? Look at the examples of accessibility needs below and learn more about how different users access content and what their needs are.

Examples of people with visual impairments

• I am colour blind and cannot perceive the difference between some colours
• I have low vision and need to increase the text size in my browser
• I have low vision and need to use a screen magnifier to make things bigger and cannot read text that has poor contrast
• I am blind and use a screen reader
• I am deafblind and use a braille device

Examples of people with auditory impairments

• I am hard of hearing and struggle to hear most things
• I am deaf; British Sign Language is my first language and I find English hard to read and write

Examples of people with motor impairments

• I have a mild motor impairment so I struggle to use a mouse with fine control
• I have a medium motor impairment so I have to use a keyboard
• I have a severe motor impairment and I am unable to use a mouse or keyboard so I use speech recognition software
• I have a severe motor impairment and speech impairment and I use a switch device

Examples of people with cognitive impairments

• I have dyslexia and struggle to process written text
• I am on the autistic spectrum and have a literal understanding of text
• I have attention deficit hyperactivity disorder (ADHD) and find it hard to concentrate
• I have a learning difficulty and need things to be simple and easy to understand
• My memory is not as good as it used to be and I get easily confused

Example of a person with a speech impairment

• I have a speech impediment and struggle to communicate by speech; I am much more confident and effective when using text-based communication

Example of a person with a seizure disorder

I have epilepsy and my seizures can be triggered by flashing content

The GOV.UK Accessibility blog has a series of interviews with users with a range of accessibility needs. You will find out how the different types of users access websites, what technology they use and what barriers they regularly face.

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.

• 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.

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).