We build our digital services so anyone can use them when they need to. This includes people:
- with a disability or health condition
- who use assistive technology
- with low literacy
- with English as a second language
- who are not confident using digital channels
Accessibility means no barriers
We believe in removing barriers. No one should be prevented from interacting with us or using our services.
Accessibility means empowerment
We empower. Accessibility means that people can interact with us independently.
The Equality Act 2010
We must not distriminate against people who have a disability or health condition. All information and services that are available to people who have not got a disability, must be available to those who have.
Anticipate the needs of disabled users, as well as reacting to them — monitor and iterate on the accessibility of your service.
Every user is different: what may solve an issue for one person may not solve it for another.
We’re not just building websites, we’re designing services. We should consider every point in the end-to-end journey that Co-op and our customers interact with each other.
If a service does not work for someone with an access need, including in any off-line part of the interaction (for example, not offering letters in alternative formats), do what you can to change it. Sometimes, the business will need to change to be truly accessible.
By regularly carrying out user research with people of various disabilities, you can get evidence to persuade the service that a change is needed.
Consider who’s reading your content
Some people can be sensitive to the language we choose to use: what may be right for some people may not be right for others. Research it with real users, write in a sensitive way, and consider that the people reading it may:
- have accessibility needs
- have little or no knowledge about the subject you’re writing about
- not be confident using a computer or mobile device
- have their own situation, insecurities and struggles
All users deserve our consideration.
There’s guidance on writing clear, understandable, accessible content in our content guidelines.
How to talk about disability
Avoid medical terms for people
You’re not a doctor, do not use a doctors terms or medical jargon.
How to write about deafness
Many deaf people who use British Sign Language as their first language refer to themselves as “Deaf”, with a capital D. That means that they consider themselves part of the Deaf community and have a strong deaf identity.
When writing about deafness, some people use an upper case D to refer to aspects of deaf culture, and a lower case d when speaking about hearing loss. Which one you use will depend on what you are writing and the research you’ve done.
Be sensitive about how you refer to people. For example, use ‘partially sighted’ not ‘visually impaired’. Many users with a health condition or disability do not consider themselves to have an impairment.
Think of mobility aids as just that, rather than someone being “confined to a wheelchair”.
Avoid phrases such as “suffers from”. They have negative connotations which could be offensive.
Use the language that your users do
If you’re unsure which terms to use to write about disability, ask people who have a disability.
Do not let uncertainty draw out your content. Be direct but sensitive.
There is a wide spectrum of eye conditions; from colour blindness and low-vision, to partial sightedness and total blindness.
There are many types of colour blindness with varying degrees of impact on people’s perception of colour.
Users with colour blindness may not need to use any special software. But, insufficient colour contrast between text and background, or use of colours alone to denote status or meaning, will make browsing unnecessarily hard.
Consider including an alternate colour scheme for people who are colour blind (they may use their own browser extension such as Color Enhancer).
You can test how accessible colours are to people who are colour blind using the Color Laboratory app.
Partially sighted users will have extreme forms of short or long-sightedness; a small field of vision or their vision may be unclear in other ways.
Partially sighted people may:
- use high contrast colour schemes when browsing
- adjust the size of text
- magnify the page using assistive technology, such as a screen magnifier or a handheld magnifier
- use a screen reader or a braille display
Blindness has varying degrees and has different legal measures in different countries.
People who are “legally blind” may still have the ability to tell light from dark or have residual vision. Blind people often use either a screen reader or a Braille display.
Hard of hearing and deaf
Many hard of hearing or deaf people use British Sign Language (BSL) as their first or preferred language, making English their second language. And so some content and concepts may be difficult to understand.
All content, in any format, should be clear, simple and to the point. Get advice on how to write for Co-op in our content guidelines.
Include captions, transcripts, subtitles and BSL interpreted videos where applicable.
Someone with a cognitive impairment may have trouble with one or two types of mental processing but be fine in other areas.
There are a huge range of cognitive and learning disabilities with differing needs, but there are some things that can make accessing our services easier for everyone:
- let users decide how they access the service
- use plain English and avoid large blocks of text
- keep lines of text to around 60 characters (90 maximum)
- break up information with logical sub-headings so people can scan information
- use large text (minimum 16pt)
- build in options for customisation (for example, text colour) or alternative output such as Browsealoud
- avoid italics and complex fonts including those that use serifs
- avoid anything moving or flickering on the page — if you must, include an easy way to stop it
- do not use pure white (#fff) page backgrounds
Do not use flashing or strobe effects on your pages. This can cause a seizure.
Websites are getting increasingly complex. They can become inaccessible when assistive technologies do not understand the meaning behind the code — it can make it hard, impossible even, for the user to navigate properly with a screenreader.
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a technical specification that tells you how you can increase the accessibility of your web page. It allows you to associate elements with an WAI-ARIA (or ARIA for short) role and allows you to attach states and properties to support these roles.
HTML5 elements already contain ARIA behaviour, for example nav doesn’t need aria-role=’navigation’ unless supporting an older browser.
See the full list of ARIA roles available from W3.
There are some common patterns we’re using at Co-op:
This role is used to convey an important message to the user. An alert event will be sent to various assistive technologies to allow them to alert the user quickly.
<div role="alert">You need to perform an action to fix something</div>
This role is used when there is no context to an element and the screen reader (or other assistive technology) does not need to ‘talk’ about it. For example, a decorative image.
<img src="decorative-image.jpg" alt="" role="presentation"/>
Use ‘aria-hidden’ to hide content from screen readers. Most screen readers will ignore display:none so use this to hide subfields until a user action. If you do not use this, some screenreaders may still read out these hidden fields which could be confusing to the user.
<p aria-hidden="true">This content is hidden.</p> <p aria-hidden="false">This content is not hidden.</p> <p>This content is also not hidden.</p>
Importance of new content
An ARIA live region is a way of notifying screen readers when content is updated on the page. Screenreader support tends to be inconsisent but it’s getting better. It does work on VoiceOver on macOS and iOS.
A screen reader can only focus on one part of the page at a time. If a new bit of content is updated, such as a validation error outside of the current zone the screenreader is in, the user might miss this update.
ARIA live regions tackle this by utilising 3 states, these are: off, polite and assertive.
<p aria-live="off">aria-live is off, there will be no notification</p> <p aria-live="polite">The screen reader will notify the user of a change when the current task is complete</p> <p aria-live="assertive">The screen reader will interupt the current task to notifiy the user of a change</p>
Only use assertive when absolutely nessesary (for example, form validation which needs the user to act) as it can be disruptive.
There are some common accessibility issue that crop up across the web. Many can be easily fixed:
Text must have a minimum contrast ratio of 1:4.3 at 24px bold and 19px regular. You can test this using WebAims Contrast Checker tool.
You could also use a ‘dropper’ style tool like this colour contrast analyser from the Paciello Group which allows you to select a colour.
For some users low contrast is preferable (for example, for some people with dyslexia). To accommodate different contrast needs, consider:
- letting users add their own style sheets
- letting users customise the web page using in-page controls
- making other aspects of the page more accessible - using larger fonts and non-white backgrounds can make high contrast text easier to read
There is no need to provide description alt/title text on links. Simply create descriptive link text instead. If the link is to a file, include what format the file is in, for example: Annual Report [PDF].
Never use the text “click here”. Not only is this link text not descriptive of the destination, it implies the user needs to click rather than use their keyboard.
Every link must give a clear indication of what it does. Screenreader users or magnification users will find it easier to navigate.
Users can use screen reader functionality to list just the links on a page. And many screen reader users audio skim — they just listen to the start of the link. So, link text like this would be problematic:
- Change your address
- Change your name
- Change your answers for question 1
- Screen reader users might just hear ‘change, change, change’. This is distracting, and potentially annoying.
Front-load links so the important information is at the beginning of the link.
If an image has no context (therefore doesn’t need to be seen by a screen reader) you can set an empty alt attribute and set the role attribute to ‘presentation’.
The role attribute ensures that the screen reader does not read out the filename of the image instead.
This webaim article on alternative text can help you decide if your images should include alt text.
There’s no need to use this. If your code is semantic it will tab just fine.
If you need to alert your user to something urgently — for example to display an error message — use negative integers as your value.
Heading and titles
Use appropriate heading levels. It’s a common misconception from the XHTML/HTML4 days that you can only have one h2 per page. You can have more than one h2 in HTML5 as long as they belong inside a article or section. If you’re writing XHTML/HTML4, follow the correct semantics.
Find out more about headings in HTML5 on the Evanto website.
Always provide hidden labels for visual formats that you might consider obvious (like asking for someone’s date of birth) — the format may only be obvious for sighted people.
The (appropriate) form control must have matching for and id attributes. The id attribute must be unique to the page as per semantics.
A fieldset should be used around logical groupings of form controls, such as a group of radio buttons or checkboxes. These fieldsets must use a legend within them to provide context.
<select> <optgroup label="Favourite fruit"> <option value="banana">Banana</option> <option value="watermelon">Watermelon</option> </optgroup> <optgroup label="Favourite Bread"> <option value="sourdough">Sourdough</option> <option value="pumpernickel">Pumpernickel</option> </optgroup> </select>
Use ‘aria-required’. A screen reader may not pick up the “required asterix” or may not understand what that concept means.
There are many useful ARIA attributes you can use in your forms to enhance the experience for people using a screenreader. A good introduction to ARIA roles in forms is available on the Mozilla Developer Network.
Readability (characters per line)
As close to 66 characters per line as possible is ideal. As long as the range is between 45 and 75 characters, your content will be easier to read by everyone, regardless of any access need.
If a line of text is too wide, the user’s eyes will struggle to focus on the text because it’s hard to see where the line starts and ends. It can also be hard to continue to the next line in the correct place.
If the line of text is too narrow, the eye will have to travel back and forth too often. This is tiring and could be stressful for users, especially if they have dyslexia.
If we all work together, learn and continue to care about accessibility we’ll create Co-op digitals products and services that are truly accessible to all.
There are a number of ways we can design in the open:
Mentor other colleagues
If you’ve learnt something that could be relevant to other services, share it with your colleagues.
Sit with other teams
We have lots of teams working on different things with different challenges, spend time learning what other teams are up to.
Document common issues
Another team could be having the same or similar issues as you. Share your problems, along with any solutions you’ve tried. Another team may well have a solution to something you’re trying to tackle.
Test with users with access needs
This is by far the most important thing you can do. Research your products and services with a variety of people with a range of access needs.