Accessibility statements: our recommendations on how to produce them

What is an accessibility statement?

The first truth of accessibility statements is that if the web were completely accessible we would have no need of them. Until that goal becomes real, however, accessibility statements can be used to provide information on how well a site conforms to accessibility standards and how the conformance was achieved.

An accessibility statement has two basic functions:

1. Present clear information about the target level of web accessibility for the site, based on the Web Content Accessibility Guidelines, version 2.1 (WCAG 2.1), and how the organisation used research, design, development and testing to achieve their target. In here, the owner can also acknowledge any known areas of the site that do not conform to those WCAG standards – including plans to address them.

2. Declare the site’s commitment to those standards. Not only is this declaration a legal requirement, but it will show site visitors (especially those with disabilities) that web accessibility is an important consideration among the organisation’s policies and practices.

An accessibility statement can cover a web app or mobile app as well as a website, and what we say in this post applies to all of these. We often use the term “products” as a shorthand for all digital products and services to which the regulation applies and about which an accessibility statement can be written. Sometimes we talk about a “site”. But everything we say about accessibility statements is relevant to all kinds of digital products and services. The EU web accessibility directive covers the public sector, and you can read about the requirements for UK public sector products, the applicable deadlines and any exemptions in this useful summary of the “Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 “ on the Gov.uk website.

At Nexer, we have always tried to convey that accessibility is a chance for organisations to learn and think about digital inclusion as something more than compliance with checklists. So, we feel this is the perfect opportunity to go beyond the immediate guidelines and address accessibility in the private sector, to include retail, leisure and any organisation seeking to reach the general public and be more inclusive. For now, to help those in the public sector comply with the September 23rd 2020 deadline, we have looked at what makes a good accessibility statement.

Comparing statements

We compared several organisations’ accessibility statements to identify the most important aspects. Then we compared those aspects based not only on the amount of information available and the size of the organisation, but also on the relevance and openness the organisation gives to accessibility — how easy it is, for example, for a user to contact them regarding an accessibility issue?

Many of the statements we examined provided good insights into the organisation’s attitude to web accessibility and where the site fell short. Here are some of our key findings on what makes an effective accessibility statement.

Show commitment to accessibility

Although the primary purpose of an accessibility statement is to provide users with information on the product’s accessibility, it is almost as important — and we cannot stress this enough — for the statement to highlight the organisation’s commitment to accessibility. Make sure your statement describes any good work you are doing on accessibility, at both organisational and digital levels.

The BBC’s statement provides some excellent examples of their commitment to what is commonly called “baking in accessibility”. Their examples include the following:

• An appointed “Accessibility Champion” represents the organisation’s accessibility agenda at the Board level

• The development of new products and services considers accessibility from the very beginning, thus “baking it in”

• All relevant staff receive accessibility training, to ensure that they can integrate accessibility into the creation of future products and services

• The organisation puts accessibility at the heart of the design and procurement of all its products and services

Expand your statement beyond digital products and services

You may have the impression that accessibility statements are intended for digital products and services alone. They should focus on them, yes, but if your organisation addresses accessibility in a broader sense it’s perfectly fine to include other areas in your statement. If, for example, your offices provide an accessible physical environment to staff and visitors, or if you host events with an accessibility focus, highlight that as well.

Additionally, if you have done usability studies involving assistive technologies, emphasise that in your statement. Usability studies that include participants who use assistive technologies- a process called “inclusive usability testing”- offer a fantastic method for getting insights into the intersection of accessibility and usability of a product or service. Conducting and communicating these types of studies illustrates your commitment to accessibility and showcases your expertise in achieving it.

Expanding beyond the digital highlights your commitment to including everyone in multiple ways.

Be an advocate for accessibility

Although it’s great to keep some of your capabilities as a competitive edge, sharing your knowledge with the wider industry can benefit you in the long term. By sharing and highlighting your dedication to accessibility, your understanding of the issues, and your approaches to addressing them, you can demonstrate industry-level leadership and increase your organisation’s reputation for accessibility.

Start sharing your accessibility activities and knowledge outside your organisation, and include in your accessibility statement the information about your advocacy.

Be cautious about using accessibility plugins

Plugins offer the potential to provide some of the web accessibility features we want to implement, and it can be tempting to make use of them. However, a number of the accessibility statements we examined said that the organisation did not use these tools, and most of them explained why not. It turns out that plugins can actually present more challenges than they resolve- especially when they’re used alongside other assistive technologies.

WCAG 2.1 does not include accessibility plugins as a success criterion against which compliance is assessed, so we urge you to consider carefully before implementing one. Many organisations appear to be using these plugins instead of doing careful accessibility design and development, as if the tools made those activities unnecessary. If you do use plugins, focus on a best approach to their use and on the benefits they offer the user. We have seen some plugins that use technical jargon for user options (“negative contrast”, for example) and some that fail to cover all accessibility factors (e.g., they let you choose a light background but don’t offer an obvious way to change it back to dark without resetting all of your accessibility choices at once). Some providers do caution that their plugins only make a few simple features quick and easy, and that most accessibility issues must be addressed by designing the content. This is a caveat with which we wholeheartedly agree.

Make sure the statement itself is accessible

What good is having a statement on your commitment to accessibility if the statement is difficult to find or is provided in an inaccessible format? The value of an accessibility statement will be lost if, for example, users can access it only through a Portable Document Format (PDF) file that happens to be inaccessible. The guidelines make some exemptions for legacy PDFs by the way but if you can update some of that content, particularly if it’s part of your service, then you should revisit.

Of course, the simplest way to include an accessibility statement in your site- for both you and your users- is to create a dedicated HTML page and add a link to it in the footer of every page. When you use HTML and make both the code and the content accessible, a large number of users will be able to access and understand your statement and navigate through it successfully.

A site’s accessibility statement page is an HTML content page, so it is subject to the same accessibility criteria as is the rest of the product. In other words, its HTML and its content should themselves be accessible. Automated accessibility tools can give you a start on verifying that your statement is accessible. We used automated tools (WebAIM’s WAVE and SiteImprove’s accessibility checker) to check NHS Digital's accessibility statement, and it passed with flying colours- receiving a report of 0 errors and 0 alerts. Although automated tools are limited as to what they can check- some things require a human assessment — ensuring that your page passes automated checks will help support your statement’s purpose.

Avoid jargon; use plain language

As with industry terminology, web accessibility terminology is very important when you are explaining your product’s accessibility features. Use plain language, and avoid using technical terms that offer the user little context for understanding. It is more effective to describe how an aspect affects user experience than to give technical details of how and why something works in a certain way.

Acknowledge your product’s shortcomings

Mentioning issues in your digital product or service is not a bad thing. By outlining the known issues, you will reassure users that you are aware of those issues and that accessibility is important to your organisation.

If the product contains issues that you plan to address, describe them here. Although users may still find an issue frustrating, if they know you are aware of it and have a plan to fix it, this will go a great deal further to gain their trust (and their custom!) than will ignoring or hiding the issue. Try providing some rough timelines/priorities where possible.

AbilityNet’s accessibility statement provides clear details about accessibility on their site, including the acknowledgement that they don’t always get it right.

Provide access to accessibility contacts

Do you have a member or team dedicated to accessibility? If so, your statement should outline who should be contacted about accessibility and how users can send feedback or questions to them. This is a clever way to keep in touch with your users while also showing accessibility’s importance to you. It also provides assurance that your organisation welcome feedback- which has the added benefit of making users feel more connected to your organisation.

Not only does AbilityNet’s statement have a section dedicated to getting in touch, it also provides users with a “call to action” (CTA)- something that invites a user to take a specific action and provides a clear way of doing so- and it tells users what to expect in the way of a response and what to do if they are not happy with the response. In this way AbilityNet’s statement gives instant assurance that they value feedback from their users.

What should you include in an accessibility statement?

Our findings suggest a few key points we recommend you include in any accessibility statement:

• The WCAG compliance levels that the site aims to meet. In addition to stating your target compliance level for the overall site, this point can also include additional levels for certain types of content. For instance, you may be aiming for level AA on the whole, and you also include sign language in all the video content. Having sign language on all videos puts you at level AAA for that content

• Any inaccessible parts of the site or app. List aspects or parts of the site or app that do not meet accessibility standards, and provide alternative routes for users to follow if they are unable to complete certain actions. It doesn't matter if they aren't required by the directive; it’s helpful to acknowledge what does and doesn’t work and how people might get around it

• Details on how to report any accessibility issues with the site. This could be a single person or a department, depending on the size and roles of the organisation and of the accessibility team

• An escalation procedure for when users are not satisfied. If users are not satisfied with the organisation’s response to the digital standards set by the appropriate governing body, they should have a way to escalate their concern through an unbiased enforcement procedure

Review your statement at least once a year to ensure that you continue to comply with developing technologies and new guidelines. Include in the statement the last review date and the interval between reviews.

The best advice for anyone writing accessibility statements is to be honest. Making vague, grandiose statements on how accessible the site is to all users- especially if those statements are incorrect- can have a negative impact on an organisation’s reputation.

What is an accessibility statement generator?

Seems like a right lot of writing, right? Fortunately, there are several free online resources to help you create these statements in a consistent format. These ‘statement generators’ differ in the way they portray the information, but they all act similarly enough to get the necessary information into your accessibility statement.

We have explored several well-known statement generators to see for ourselves what you can expect from them when creating your own statements. We looked at generators from the World Wide Web Consortium, from Nomensa, and from SiteImprove, with whom we are a Gold Partner. We considered how transparent the generator was, whether the format gave clarity to creating effective statements, and how accessible the generators themselves were. Here are some key findings from our investigation.

They use simple forms

Accessibility statement generators use form-based interaction to provide effective and efficient methods for creating clear accessibility statements. Most of them break up the statement into manageable sections and provide explicit instructions on what each section requires. Where a label on a form field doesn’t adequately convey the requirements for that field, a tooltip often provides for accessing additional help within the process. Some generators, however, appear to expect their own users- the writers of accessibility statements- to be relatively tech savvy and to understand accessibility jargon and how the features work.

Some generators are themselves inaccessible

Ironically, although accessibility statement generators have the purpose of building a statement on how accessible the site is, some of the generators themselves fail on a number of accessibility requirements. Their shortcomings exist in areas ranging from basic information identified by screen readers to keyboard navigation and colour contrast.

Overall, the user journey with accessibility statement generators is relatively straightforward. It is evident, however, that people using keyboards or certain other assistive technologies (e.g., screen readers) would struggle to complete the process and generate a full accessibility statement. Because of the generators’ very purpose, we find it disappointing how far some of them fall below the basic requirements for accessibility.

They provide helpful output

One of the best features of these generators is the ease with which you can take your generated statement and insert it into your site. A simple copy-and-paste provides an easy way to insert components of an accessibility statement to a content page within your content management system (CMS). Some generators also allow the statements to be converted into HTML format before insertion, which keeps the statement’s structure and format (including headings, styles and links) for easy integration into a site.

Some points to remember

We have covered a lot in this post, and we certainly don’t expect you to remember it all! We do hope you will take away a few key points:

• If you are developing digital products and services for the public sector in the UK or the EU, you are required by law to provide an accessibility statement with them

• Your accessibility statement must cover, at a minimum, the WCAG compliance levels that your product aims to meet, any non-compliant parts of the product and what you plan to do about them, a means for users to report accessibility issues, and what users can do if they are not satisfied with your response

• It’s valuable to highlight in the statement your organisation’s advocacy for accessibility, in addition to the required content about the product’s accessibility

• The statement should be written in plain language and provided in an accessible format (preferably HTML)

• An accessibility statement generator can get you started on producing a draft, which you can then enhance to meet your organisation’s goals

If you have any questions about anything we have written here, please let us know.

Here at Nexer, we want everyone to be able to access our products and services. This is why we are committed to taking an inclusive approach to research, design and development. For any further information, please get in touch for a friendly chat.