The services we provide digitally are for the benefit of a wide range of users both in the UK and globally. We aim to provide accessible digital services for disabled users in compliance with the Equality Act 2010.
The Royal National Institute Of Blind People (RNIB) has some useful guidance on compliance with the Equality Act: rnib.org.uk/services-we-offer-advice-professionals/equality-act-compliance
For an easy to understand statement about what is meant by web/digital accessibility go to: https://en.wikipedia.org/wiki/Web_accessibility
Historically accessible websites and browser based services provide a better user experience for all users.
User testing company Nomensa has a great blog entry on myths behind accessibility: nomensa.com/blog/2012/7-web-accessibility-myths-2
WCAG 2.0 compliance
As a starting point, all of our browser based services (both internal and external) should aim to meet Level ‘AA’ of the Web Content Accessibility Guidelines (WCAG 2.0) from the World Wide Web Consortium (W3C).
All developers/agencies should be aware of these guidelines: w3.org/WAI/intro/wcag.php
As a minimum, it must meet Level ‘A’ of the WCAG guidelines.
Any supplier creating a browser based service or website for you, must confirm in writing the level of accessibility of the output of their product.
If they cannot meet Level ‘A’ compliance you should not be purchasing their services/product.
Wherever possible you should be aiming for level ‘AA’ compliance of the WCAG guidelines.
Your service should be tested for technical accessibility by an accessibility expert. There are many agencies who can carry out this testing and projects should budget for this work.
There are also a number of tools available to identify basic accessibility issues in individual web pages:
- WAVE wave.webaim.org/
- AChecker achecker.ca/
- WCAG Accessibility Audit Chrome browser extension
- Contrast checker contrastchecker.com/
- WCAG Luminosity Contrast Ratio Analyzer Chrome browser extension
W3C provides a range of accessibility evaluation resources for web developers: w3.org/WAI/eval/Overview.html.
User based accessibility testing
You should seek to test your service with a range of disabled people and assistive technology users. You should aim to do this at least once during the development of your service.
Don’t leave accessibility testing until the end of your project. It is much harder to fix accessibility issues once the majority of your development work is completed.
Accessibility testing should be carried out alongside wider user testing. See ‘User Testing’ Guidance for details on how to carry out user testing.
Accessibility statements and policies
We need to work harder to make our websites and services as accessible and usable as we can for everyone who needs to use them. Following Government Digital Services (GDS) lead we do not have an accessibility statement for the website, as like them, we don’t want to create a statement that draws a distinction between accessibility and any other aspect of best practice.
Your digital service should be usable by recent versions of these screen readers:
- Jaws freedomscientific.com/Products/Blindness/JAWS
- NVDA nvaccess.org/
- Voiceover for OS X apple.com/accessibility/osx/voiceover/
- Window Eyes gwmicro.com/Window-Eyes/
- Super Nova yourdolphin.com/product?id=3
- Your service should also be usable by basic operating system screen magnifiers like:
- ZoomText zoomtext.com/products/zoomtext-magnifierreader/
- MAGic freedomscientific.com/Products/LowVIsion/MAGic
Your service should be usable by speech recognition software, including Dragon Naturally Speaking nuance.com/dragon/index.htm, native operating system speech packages and text to speech packages, such as: ClaroRead or TextHELP.
HTML is quicker, easier and more widely usable and accessible than PDF format. However, when there is no other option, guidance for creating PDFs should be followed. Government Digital Services provide useful information on this: https://www.gov.uk/service-manual/user-centred-design/resources/creating-accessible-PDFs.html
Accessibility is more than checking the boxes of standards compliance. When writing content, consider what information would be useful to people with access needs.
For instance, in a ‘find my nearest’ service, consider user needs like:
- Is there disabled parking?
- How far is it from the entrance?
- What’s the terrain like – uphill/downhill?
- Will I have to cross any roads?
You should also make sure that your text is as easy as possible for everyone to understand. Ensure that your copy is not too text heavy, it’s clear, concise and reduce specialist vocabulary and acronyms wherever possible. This is particularly helpful for people with specific learning differences (spLD).
The Digital Team’s style guide also offers tips on how best to write web copy to make it accessible to all: arts.ac.uk/style-guide/creating-web-content/writing-for-the-web/