Every website is unique and tells a different story. There are common themes, however, and the guidelines below will help you craft an accessibility statement that is transparent and informative for your users.

The Template

Government Digital Services (GDS) have drafted a sample accessibility statement for public sector bodies. If your accessibility statement doesn’t contain this information, your customers are likely to be badgering you since they will need to provide it themselves. We strongly recommend you take this into account when constructing your own. It will be good for customer relations. The template is available at the link below.

Arrow icons - link to GDS accessbility statement template and guidance.

Alistair McNaught was part of a team contributing to this model approach and provides some highlights here for crafting an accessibility statement that is meaningful for your audience (and helps with your ASPIRE score).

In the sections below, we translate the GDS template into something relevant to a supplier context.

The Guidelines

1. Be Discoverable

Ensure accessibility information is central and well signposted.

This seems an obvious point yet, in the ASPIRE project, where auditors were unable to find accessibility information, the suppliers scored zero. Where auditors could not find an appropriate link from the supplier homepage, they used Google to find accessibility statements. This did not not necessarily lead to the most up to date information. Some suppliers had a significant range in their score because different auditors had scored them on the basis of different URLs revealed by a Google search.  Ensure accessibility information is central and well signposted. Identify and remove out of date information.

2. Using the resource (i.e. ‘things that work well’)

You cannot assume all users know how to make best use of an accessible file or interface. This section is a key marketing pitch to tell users what you’ve done for accessibility, what works and how they can benefit from it.

The content covered will vary depending on whether you are responsible for file formats, delivery interfaces or both. Where there are multiple file formats, you can provide guidance on the differences – for example changing background color in an ebook is easier on a PDF viewed in Adobe Reader than an EPUB viewed in Adobe Digital Editions. Where functionality is not specifically available (but your product is compatible with other tools), you might suggest free tools or plugins to make the difference – for example text to speech browser plugins, clipboard readers, color changing tools etc. We can support you with this guidance. 

All the ASPIRE criteria where you have a positive answer should feature in this section. It will probably be your biggest section. It could include information on:

  • magnification and reflow,

  • personalization options such as color / contrast, line spacing, margins etc,

  • availability of image descriptions,

  • navigation options (e.g. tagging for headings and subheadings etc),

  • key-board only navigation/operation,

  • interoperability with assistive technology (this may be influenced by Digital Rights Management (DRM) decisions so clarify this where applicable).

3. How accessible is the product (i.e. ‘are there issues the user should know in advance?’)

How can you save people wasting time trying to do something that you know won’t work?

Inform users about any accessibility issues that have not yet been resolved – for example if images lack descriptions or PDFs are not tagged for reading order or screenreader testing failed on the interface. Letting people know in advance is better customer service than ignoring the issue, letting disabled users waste time finding the problem and then trying to resolve it too late. DRM restrictions can have an impact on the tools the end user can use so mention these where applicable. Examples include:

  • EPUBs being tied to Adobe Reader so losing much of their accessibility,

  • Copying restrictions reducing functionality for text to speech tools that rely on the reading the clipboard.

By being transparent about what doesn’t work you can discuss other options available (see below) and help manage expectations. You may be able to suggest alternatives such as:

  • accessing the content a different way that has more closely matches the reader’s needs for example:

    • download a different format,

    • read it online,

    • read it in a Kindle edition on a phone or tablet.   

  • free tools or plugins to make the difference, for example color overlay tools or high contrast settings can compensate for a lack of color change options in a delivery interface. We can support you with this guidance. 

UK law regards the base level accessibility requirement as meeting the requirements of the EU Accessibility requirements suitable for public procurement of ICT products and services in Europe – this is very closely aligned to Web Content Accessibility Guidelines 2.1 at AA level.

4. What to do if you need better accessibility than currently available (who to contact)

If the options above still don’t meet the needs of a disabled reader, they may need a more accessible option or a DRM free version that their local alternative format team can help with. This is the place to describe your ‘support ecosystem’. For example is there a dedicated email, phone number or internal role responsible for accessibility? Do you have your content distributed through RNIB Bookshare collection or the Access Text Network etc?

This information may already be in place, in which case you might simply add a link from the accessibility statement. This is a useful place for information on:

  • contact details,

  • response times,

  • licensing terms + conditions,

  • typical response times.

5. Embedding accessibility

This is designed to demonstrate both confidence and competence so it covers:

  • when the testing was done and this accessibility statement was updated (your customer’s accessibility statements are expected to be updated at least annually).

  • what the testing involved (which assistive technologies were used),

  • roadmap – this could include:

    • what the testing showed (probably covered in sections above) and whether it showed a need to make improvements. If it did, what’s the plan?

    • how internal workflows and quality assurance processes have incorporated accessibility.

This is not a one off exercise. You are expected to update the statement annually and reduce ‘disproportionate burden’ claims as your expertise and awareness improves.

ASPIRE CRITERIA​

For further information and guidance on the ASPIRE criteria, please visit the ASPIREreview page by clicking the link below.

© textBOX LLC