Digital accessibility standards - Co-op Experience Library

Problem: Screen readers read out the text on a page, usually for people who cannot see the page. People using screen readers often browse only the links on a web page. This means link text can be read out of context. If a link says ‘read more’ or ‘click here’ it will not be clear what the link does or where it takes the user.

Works well: Link text that describes where the link is taking the user. Ideally this will be using the same words as the destination page title, so users know they're in the right place when they get there.

If the link is to an action, for example ‘Book an appointment’, use this as the link text. If it’s to something else, for example a policy or external website then use the title as the link text.

Good example: Accessibility policy

Bad example: Read more

Our interpretation of WCAG:

2.4.4 Link purpose (in context) (Level A)

2.4.9 Link purpose (link only) (Level AAA)

1.2 Use page titles and section headings to explain what the content is about

Problem: People use the headings on a page to determine what content is there and to decide which content will help them achieve what they came to do. Pages with generic headings make it hard to find information.

Works well: Clear and descriptive headings that describe what content is in that section. People can scan the headings to find the information they need.

Good example: Contact details

Bad example: More information

Our interpretation of WCAG:

2.4.2 Page titled (Level A)

2.4.6 Headings and labels (Level AA)

2.4.10 Section headings (Level AAA)

1.3 Do not use images of text, except for logos and product shots

Problem: People sometimes zoom in or make the text bigger on a web page so they can read it. If text is within an image it will become blurry and unreadable when enlarged. This can affect people who have forgotten their glasses or have other visual impairments.

Do not use images with text in them. The exception to this is text contained within logos or product shots.

Works well: Text entered using a content management system or in the HTML of the website.

Good example: Only using text on logo or product shots.

Bad example: Images with text in them.

Our interpretation of WCAG:

1.4.5 Images of text (Level AA)

1.4.9 Images of text (No exceptions) (Level AAA)

1.4 Do not use unusual words and phrases

Problem: English is a wonderful language, but it can be complicated, especially if you’re learning it. Translations are often literal so can be confusing if people have not heard specific terms or phrases before.

Works well: Using plain English. Not using idioms, metaphors, specialist terms or unusual words and phrases.

This helps people who might get confused by metaphors and colloquialisms or take them literally.

Good example: We’ll contact you within 2 days.

Bad example: We’ll be with you in two shakes of a lamb’s tail.

Our interpretation of WCAG:

3.1.3 Unusual words (Level AAA)

1.5 Do not use abbreviations

Problem: Abbreviations or acronyms, and Latin terms (for example “etc..”) are all generally bad for readability.

They usually give the reader more work to do to understand the information. Using them can make people feel alienated or confused.

Works well: Only using abbreviations or acronyms where you must or where they are widely recognised, such as NHS or BBC.

If an acronym is used multiple times, you could spell it out on the first usage and then use the short version. If there are several sections of content, people may not have read all of it and therefore might not have seen the first usage. Use your judgment depending on how much content you have and how many uses of an abbreviation there might be. If in doubt, spell it out.

This helps people with English as a second language or cognitive conditions.

Good example: Enter a postcode, for example M4 4BF, to show stores near you.

Bad example: Enter a postcode, e.g. M4 4BF, to show stores approx near your addr.

Our interpretation of WCAG:

3.1.4 Abbreviations (Level AAA)

1.6 Write to a low literacy level

Problem: Lots of people have difficulty reading. The National Literacy Trust found that 16.4% of adults in England have very low literacy skills.

Works well: Using plain English with short words and sentences. This will help to make the content clear for people with low literacy and help everyone to find what they are looking for.

Good example: Change your address.

Bad example: Update with an adjustment to core primary residence information in the location database.

Our interpretation of WCAG:

3.1.5 Reading level (Level AAA)

1.7 Give help at the point it’s needed

Problem: Sometimes people have difficulty understanding information, completing a task or knowing what they need to do online. This is especially true for forms or other interactions where people have to enter information.

Works well: Giving clear instructions for a task at the point of need. Make questions clear and self-explanatory. Providing examples and guidance on text input fields.

If an error occurs, giving a clear reason why and instructions on what the user must do to resolve the problem.

Providing ways to get further help and support where it's needed.

This helps people with cognitive conditions and people who do not have a lot of time or are distracted.

Good example: What is your date of birth?

For example, 29 10 2020

Bad example: Enter DOB

Our interpretation of WCAG:

3.3.5 Help (Level AAA)

1.8 Provide text alternatives for non-text content

Problem: Sometimes content is presented in non-text formats that cannot be read by assistive technology such as a screen reader. This means people can miss essential information.

Works well: Providing text alternatives that describe the non-text content. Providing any essential information in text that can be read by assistive technology.

Good example: Essential information that is contained in an image is also provided as alternative text.

Bad example: Essential information is contained only in an image, with no text alternative provided.

Our interpretation of:

1.1.1 Non-text content (Level A)

1.9 Structure content clearly

Problem: Content needs to follow a logical order and make clear its relationship to other content in order to be understood.

If it does not then people have a harder time working out where they need to go or what they need to do.

Works well: Content structured in a relevant order with clear headings that have been identified as headings in the code.

Things like required fields are indicated in text descriptions and not only identified by colour.

Good example: Pages with a clear structure and headings that are identified in the code.

Bad example: Pages that do not follow a logical order and have either no headings or headings that are only identified visually.

Our interpretation of WCAG:

1.3.1 Info and relationships (Level A)

1.3.2 Meaningful sequence (Level A)

1.10 Set the language in the code

Problem: The way screen readers read text and pronounce words is determined by the the language setting in the HTML. If the correct language is not set in the HTML then things may be pronounced in unusual and confusing ways.

If the language is not set then it will be harder for translation software to interpret and translate the content.

Works well: Set the language of each page in the HTML using the language attribute.

Good example:

Bad example: No language set.

Our interpretation of WCAG:

3.1.1 Language of page (Level A)

1.11 Provide status messages to users of assistive technology

Problem: When the content on a page changes, this change may not be seen by users of assistive technology such as screen readers.

For example, a results page might show ‘5 results’ but this text will not be focused on by the screen reader. But, if you include a status message in the HTML it will announce it the message to the user.

Works well: Accompanying all status changes such as searches, errors or updates with clear, relevant status messages.

Good example: If a user enters an incorrect postcode, a message appears above the input reading "Enter a correct postcode". The screen reader announces that there has been an error and reads this message.

Bad example: If a user enters an incorrect postcode, a message appears above the input reading "Enter a correct postcode". There is no status message so the screen reader does not know to announce there has been an error.

Our interpretation of WCAG:

4.1.3 Status messages (Level AA)

1.12 Give different ways to find web pages

Problem: People with different circumstances need different ways to navigate and find web pages.

A screen reader uses might find it easier to use a search than go through a menu. Someone with a cognitive condition might prefer to look at a sitemap that gives an overview of the website.

Works well: Providing a range of ways to find web pages.

Good example: Providing search, sitemap, navigation and lists of links.

Bad example: Only providing a navigation menu with the main pages.

Our interpretation of WCAG:

2.4.5 Multiple ways (Level AA)

1.13 Use menus, buttons and icons consistently

Problem: If menus, navigation, buttons or icons change from page to page, it is harder for people to find what they're looking for and complete tasks.

Works well: Making sure the order of menus and the function of particular buttons and icons remains the same across the website or app.

Good example: Items on a navigation menu are in the same order on all pages.

Bad example: Items on a navigation menu are in a different order on several pages.

Our interpretation of WCAG:

3.2.3 Consistent navigation (Level AA)

3.2.4 Consistent identification (Level AA)

1.14 Do not rely on sensory directions

Problem: People with different needs may not be able to find things or follow the content if only sensory directions are given.

For example, a blind or partially sighted person will find it difficult if content is indicated as above or below other content. Someone who is colour blind may find it hard to “click the red button”.

Works well: Not relying upon sensory directions.

Good example: Fill in the application form.

Bad example: Fill in the form below. Click the orange arrows to move to the next page and the red button to submit your application.

Our interpretation of:

1.3.3 Sensory characteristics (Level A)

2. Make it readable and usable

2.1 Keep lines of text under 80 characters

Problem: Lines of words containing 80 or more characters can be difficult to read. This is because the eye has a longer distance to skip from the end of one line to the start of the next. Reading on the move, from a distance or when tired can result in people re-reading lines. This can result in people losing motivation and focus. Dyslexia is also often cited as affecting people’s ability to read longer lines of text.

Works well: To help prevent the re-reading of lines of words, use under 80 characters in a line and use short sentences. Doing this has been known to increase reading speed by up to 27%.

Good example: Short lines of words with less than 80 characters.

Bad example: Long lines of words with over 80 characters.

Our interpretation of WCAG:

1.4.8 Visual presentation (Level AAA)

2.2 Do not justify text

Problem: Justified text is when the left and right sides of a word block both have a straight edge. This results in some words that are close together and others that have big gaps. We know people do not fixate on every word but tend to skip words (their eyes take little leaps, called “saccades”) and fill in the rest.

The gaps make it tricky to read naturally. People cannot easily skip from word to word as the differing widths of gaps means the eye has to assess the size of the gap constantly.

Works well: Left align your text for even spacing and an easier reading experience. This way the eye does not need to assess the size of gaps within justified text.

Good example: Left aligned text with even spacing.

Bad example: Justified text with random spacing.

Our interpretation of WCAG:

1.4.8 Visual presentation (Level AAA)

2.3 Use enough line spacing

Problem: Line spacing is the gap between one line of words and the next. People can find it difficult to read paragraphs of words where the lines are close together. When reading, the longest distance the eye must travel is from the end of one line to the start of the next. Reading on the move, from a distance or when tired can cause people to re-read lines. This can result in people losing motivation and focus. Dyslexia is often cited as affecting people’s ability to read words with poor line spacing.

Works well: To help prevent people re-reading lines of words, provide extra space between lines and paragraphs to so people can better track the next line.

Good example: Words with 1.5 to 2 times the font size for line spacing. Letter spacing (tracking) to at least 0.12 times the font size. Word spacing to at least 0.16 times the font size.

Bad example: Line spacing, letter spacing and word spacing below the recommend size.

Our interpretation of WCAG:

1.4.12 Text spacing (Level AA)

1.4.8 Visual presentation (Level AAA)

2.4 Touch target area is large enough

Problem: The touch target area is the size of the thing that people can click, touch or interact with. For example, a button’s touch target area is usually the size of that button. If the touch target area is too small people can struggle to press the button. This can affect people travelling on a wobbly train or who have dexterity conditions.

Works well: To help people click on the thing they want to, make sure the button is sized to the average width of the index finger which is 1.6 to 2 cm for most adults. This converts to 45 to 57 pixels, which is wider than what most mobile guidelines suggest.

Good example: Both the height and the width are between 45 to 57 pixels.

Bad example: Either the height or the width is below 45px.

Our interpretation of WCAG:

2.5.5 Target Size (Level AAA)

2.5 Allow people to resize text without breaking the page

Problem: People cannot always read the standard sizes of text. They may need to make the text bigger if, for example, they’ve forgotten their glasses. Changing the text size can sometimes make it unreadable as it’s hidden behind something or it overlaps the next line.

Works well: Allow people to:

resize the text to at least 200%
change their window size or orientation of their mobile screen
view the content without having to scroll both horizontally and vertically

Good example: Content that proportionally expands to be legible at different screen sizes.

Bad example: Content that is not viewable or overlaps if the orientation or text size changes.

Our interpretation of WCAG:

1.4.10 Reflow (Level AA)

1.4.4 Resize text (Level AA)

1.3.4 Orientation (Level AA)

2.6 Allow people to access content using a keyboard

Problem: Lots of people cannot use a mouse or a trackpad. They rely on the keyboard to access web pages. Using a mouse, you can move the cursor around a page without having to engage with it. A keyboard user often must go through a page one thing at a time. When pages have lots of links it can cause physical pain to access the content they need.

Works well: Allow people to:

access all the content on the screen in the order its displayed
navigate around a page freely without getting stuck.
skip passed navigation that is replicated across a website and has over 6 links in it.

Good example: All content can be reached by keyboard users.

Pop-up menus can be closed with the keyboard.

There is a ‘Skip to content’ link when people access a webpage.

Bad example: Large navigation menus on every page that people must tab through every item.

Pop ups that cannot be closed.

Cookie banners after all the content – this means people must tab through the whole site to close them.

Our interpretation of WCAG:

2.4.1 Bypass blocks (Level A)

2.4.3 Focus order (Level A)

2.1.1 Keyboard (Level AA)

2.1.2 No keyboard trap (Level AA)

2.7 Make the focus visible

Problem: Having no focus ring (a ring around content when it’s accessed using a keyboard) is like having no mouse cursor. Some people rely on the focus ring to see where they are on the page. Most assistive technology users have sight and rely on a keyboard. A poor, or no, focus ring can make a website unusable.

Works well: A clearly visible ring around content when accessed using a keyboard. Check it has a strong contrast against all the different background colours that we have on the website.

Good example: A visible focus ring with good colour contrast.

Bad example: No focus ring or one with poor colour contrast.

Our interpretation of WCAG:

2.4.7 Focus visible (Level AA)

3.2.1 On focus (Level AA)

3. Put the user in control

3.1 Allow users to turn off alerts

Problem: People can find it hard to focus on the content they need to if there are updates and alerts distracting them, such as announcements or offers.

Works well: Allowing users to turn off or postpone updates and alerts from your service, can help them focus on the content they need. This can also help some people with cognitive or attention conditions like ADHD (attention deficit hyperactivity disorder).

You do not need to allow users to turn off or postpone emergency messages. Emergencies messages include warning of danger to health, safety, or property, including data loss, loss of connection, and so on.

Good example: Dismiss this message.

Bad example: No way of dismissing or postponing alerts or updates.

Our interpretation of WCAG:

2.2.4 Interruptions (Level AAA)

3.2 Allow people to re-confirm details and continue

Problem: For security reasons, many sites sign people out after certain periods of inactivity or if they sign in on multiple tabs or devices. This sign out can cause problems for some people who may take longer to complete a transaction or form, or who need to take breaks when they’re completing it.

Works well: When users are signed out mid-transaction, give them the chance to re-confirm their details and continue their session without losing any data already entered. Doing this can also help people who need to find information in order to complete the transaction, as well as people with memory, attention or cognitive conditions, such as dementia.

Where this not possible, warn people in advance.

Good example: To continue with this form, re-enter your name and password.

Bad example: We’ve signed you out and deleted the information you entered.

Our interpretation of WCAG:

2.2.5 Re-authenticating (Level AAA)

3.3 Warn of time-outs

Problem: People read, understand and complete transactions at different rates. Some people may take longer to understand what’s being asked of them, or may need to take a break to complete a transaction. If we do not allow for this, some users may not be able to complete their task accurately, if at all.

Works well: Where possible, keep the user’s data for 20 hours. This will allow people enough time to start and finish the transaction with breaks where needed.

If this is not possible:

let the user stop or adjust the time limit within a transaction
warn the user how much time they have to complete before inactivity times them out
explain what information they may need to seek to be able to successfully complete the transaction

This allows the user to decide whether they should start the transaction and prepare any information that will be asked of them in advance. This can also help people with memory, attention or cognitive conditions, such as dementia.

Good example: To use this service you’ll need:

your National Insurance number
a device you use to upload an image of yourself.

If you do not interact with a page for more than 2 hours (for example, if you do not enter any information) we will delete any information you’ve entered so far. We do this to keep people’s information secure.

Bad example: Within 20 hours, and without pre-warning:

You’ve been timed out. We’ve deleted the information you’ve entered so far.

Our interpretation of WCAG:

2.2.3 No timing (Level AAA)

2.2.1 Timing adjustable (Level AA)

3.4 Give alternatives to audio and visual content

Problem: Some people are unable to:

see or understand visual content
hear or understand audio information

Works well: All information, regardless of format, should be available to everyone. By giving text and audio alternatives, people can use assistive technology to read them aloud, present them visually or convert them to braille where needed.

For example, we should provide:

real-time captions of dialogue, who’s speaking and other significant noises, for people who are deaf or hard of hearing
text transcripts of any pre-recorded audio or video, for example speeches or any sounds within a video (for example, if there’s laughter or applause) for people who are unable to hear or understand audio content
an audio description of what’s happening in a video, for example actions, scene changes, expressions or any on-screen text – for people who cannot see the video or understand what’s being shown
captions if we’re using non-vocal music that includes the title, movement, composer, and any information that will help the user understand what’s being played

Good example: Co-op Christmas advert with audio description.

Younger brother: “Can I come?”

Older brother: (sighs)

Describer: older brother looks to bannister with Santa hat on.

Describer: scene cuts to both boys walking fast in the street, older brother is holding a guitar case, younger brother is running to keep up.

Older brother: “Come on!”

Bad example: No subtitles or audio description available on a video clip.

Our interpretation of WCAG:

1.2.1 Audio-only and video only (pre-recorded) (Level A)

1.2.2 Captions (pre-recorded) (Level A)

1.2.3 Audio description or media alternative (Level A)

1.2.4 Captions (Live) (Level AA)

1.2.5 Audio description (pre-recorded) (Level AA)

3.5 Let users control audio, animation and video

Problem: Because people interact at different rates online, it can be distracting and frustrating for some people to interact, watch or listen to something that they cannot control the timing of.

For example, a moving object, animation or a flashing video that:

starts automatically
cannot be paused
cannot be stopped

For some people, flashing images can also cause seizures.

Works well: Allow the user to:

start audio, animation and video themselves, rather than start them automatically
pause, stop or control the time of audio, animation and video media

This can help people who:

are taking notes about the content
need to take breaks during the content
are relaying content to people who are deaf
are using screen readers and need to control audio to be able to navigate the page

The only exception is if we're showing real time events – where it’s happening at the same time it’s being viewed, like a live stream.

Never use images or animations that have repeated flashing – that’s any that flash more than 3 times in 1 second.

Good example: A video with a stop button.

Bad example: An animated banner that loops continuously and flashes three times or more in a second.

Our interpretation of WCAG:

1.4.2 Audio control (Level A)

2.2.2 Pause, stop, hide (Level A)

2.3.1 Three flashes or below (Level A)

2.2.3 No timing (Level AAA)

2.2.4 Interruptions (Level AAA)

2.3.2 Three flashes (Level AAA)

2.3.3 Animation from interactions (Level AAA)

3.6 Be objective, not subjective

Problem: Attaching subjective terms – like easy, quick or simple – or giving a suggested completion time can be frustrating and misleading for people who:

find interacting with digital services difficult
are emotionally triggered by the content
are unable to complete the transaction within the stated time

Works well: Using objective rather than subjective descriptions allows users to experience a service in a way that’s respectful to their circumstances.

Good example: This survey has 5 multiple choice questions.

Bad example: This simple survey will only take you 2 minutes to fill in.

Our interpretation of WCAG:

2.2.3 No timing (Level AAA)

3.7 Allow users to fix mistakes

Problem: Users may not be aware they have made an input error and may be unsure how to recover from a mistake.

Works well: Where possible, design forms so that they allow a user to input information in the way they choose. For example, a postcode input that accepts both a space and no space in the format.

Allow users to review what they’ve entered and correct any mistakes. This could be by:

adding validation to form fields that clearly explains what the user needs to do to fix an error – for example if they’ve not entered information into a field, or have not entered an expected format
including hint text or content in the validation message that helps the user understand the format that’s required
allowing the user to review and edit their answers before they submit the form or complete the transaction
allowing the user to change what they’ve submitted – for example, an order confirmation that includes the cancellation method

This can help anyone who has made a mistake. It can also be helpful for people with:

some conditions such as arthritis, Parkinson’s disease or other motor disabilities, that may make hitting keys by mistakes more likely
dyslexia who may be more likely to swap numbers and letters around

Good example: Check your answers summary page before submission.

Bad example: Non-specific ‘fix the error’, or no form field validation on a field that required a specific format.

Our interpretation of WCAG:

3.3.1 Error identification (Level A)

3.3.3 Error suggestion (Level AA)

3.3.4 Error prevention (Legal, financial, data) (Level AA)

3.3.6 Error prevention (Level AAA)

4. Design and build forms accessibly

4.1 Consider forms carefully

Problem: Forms can be intimidating and frustrating.

People can be unclear about what’s needed, unsure about how to move through the form, worried about their spelling or grammar, emotionally triggered by the information that’s being asked of them, scared about the implications of submitting incorrect information.

It can be especially hard if you:

cannot see what’s on the screen
have a certain part of the screen magnified
are relying on text to speech software
have English as a second language
are dyslexic
are in crisis
have been recently bereaved
have a poor internet connection

Works well: Too much information or instruction can be just as harmful as too little. Give enough information for the user to complete what they came to do without confusion. Make it clear what information’s required from a user, why it’s required and make it easy for them to complete.

This includes:

using labels (they tell users the purpose of the field) and instructions to help people understand what information, or format of information, is required in a form field
allowing a user to autocomplete fields such as address – this can be especially useful for people with motor disabilities, memory conditions, dyslexia and English as a second language (because the autocomplete is independent of language)
making sure any standard or custom built components (in code or script), work with assistive technologies so that users know, for example, whether a control has focus, or whether a checkbox has been selected
matching the visible label of a component with the accessible name (also known as a programmatic name) – doing this can help users of speech recognition and text to speech software to navigate, as what they say or hear matches what’s on the screen
making any change of context clear, for example, a validation message that appears at the top of the page when a page reloads – this can lessen confusion for users who do not easily see the change, are unsure why the page has reloaded (for example, screen reader users) or are easily distracted by changes that are unexpected

Good example: Form guidance in the Elements section of the Co-op Experience Library

Bad example: A 'Tell us more' free text box - it’s not clear what we need to know or why we need to know it.

Our interpretation of WCAG:

2.5.3 Label in name (Level A)

3.2.2 On input (Level A)

3.3.2 Labels or instructions (Level A)

4.1.2 Name, role, value (Level A)

1.3.5 Identify input purpose (Level AA)

4.2 Do not give information using colour only

Problem: People with low vision, or who are colour-blind, can have difficulty reading text or seeing elements of a page that give information using colour only.

Works well: If you use colour to give information, include another way for users who cannot see colour can still understand the information

Good example: An error state that uses both colour and text to indicate the problem.

Bad example: Using only colour to give information, for example a button that is red to suggest something has been entered incorrectly.

Our interpretation of WCAG:

1.4.1 Use of colour (Level A)

4.3 Check the colour contrast

Problem: People with low vision, or who are colour-blind, can have difficulty reading text or seeing elements of a page that do not contrast with their background. Text that does not have a high colour contrast can also be hard to read when the sun is shining on a screen and on screens with low brightness.

Works well: A high colour contrast ratio can make content easier to read.

This means a contrast ratio of at least 4.5:1, between text (and images of text) and its adjacent colour.

A contrast ratio of at least 3:1 for:

text that’s at least 18 point or 14 point bold
controls of an interface, for example a button
any visual information necessary to indicate state, for example if a component’s selected or focused
any graphics or images that are needed to understand content.

It is not essential to check the colour contrast for:

text, or images of text, that are just decorative
part of an inactive component or element
part of a picture that contains significant other visual content
text that is part of a logo or brand name

Check the contrast using a colour contrast checker like, Web AIM’s contrast checker or Color Oracle (free colour blindness simulator).

Good example: The colour palette in the Co-op Experience Library.

Bad example: Light grey text on a white background.

Our interpretation of WCAG:

1.4.3 Contrast (minimum) (Level AA)

1.4.11 Non-text contrast (Level AA)