Accessibility

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.

RNIB has some useful guidance on compliance with the Equality Act:

http://www.rnib.org.uk/services-we-offer-advice-professionals/equality-act-compliance

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:

http://www.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: http://www.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. 

Accessibility Testing

Your service should be tested for technical accessibility by an accessibility expert. There are lots of agencies out there who can carry out this testing and the project should set aside some budget for this.

W3C provides a range of Accessibility Evaluation Resources that web developers should be able to use: http://www.w3.org/WAI/eval/Overview.html

This tool also highlights some of the more basic accessibility issues: http://wave.webaim.org/

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 as your service is developed.

Don’t leave your accessibility testing to the end of your project. It is much harder to fix accessibility issues once the majority of your development work is completed.

NB: this 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.

Assistive Technologies

Your digital service should be usable by recent versions of these screen readers:

Jaws  http://www.freedomscientific.com/Products/Blindness/JAWS

NVDA http://www.nvaccess.org/

Voiceover for OS X https://www.apple.com/accessibility/osx/voiceover/

Window Eyes http://www.gwmicro.com/Window-Eyes/

Super Nova http://yourdolphin.com/product?id=3

Your service should also be usable by basic operating system screen magnifiers like:

ZoomText http://www.zoomtext.com/products/zoomtext-magnifierreader/

MAGic http://www.freedomscientific.com/Products/LowVIsion/MAGic

Your service should be usable by speech recognition software including Dragon Naturally Speaking http://www.nuance.com/dragon/index.htm and native operating system speech packages.

And text to speech packages such as: ClaroRead or TextHELP

Accessible Formats

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 have some really 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: http://www.arts.ac.uk/style-guide/creating-web-content/writing-for-the-web/