Accessibility statements: From technical findings to user-centred document

Clients often ask us to write an accessibility statement for their website. As we said in a previous blog post, an accessibility statement is intended “to provide information on how well a site conforms to accessibility standards”. Basically, it tells the site’s users what they can expect in the way of accessibility.

An accessibility statement also contains some background and administrative information, but creating that content is straightforward and this article doesn’t address that.

The World Wide Web Consortium (W3C) offers some guidance for the content of accessibility statements. These statements exist mainly for the site’s users, the guidance points out, and should be written in simple language rather than technical jargon. This presents a challenge for writing the statement, because the document that describes the site’s accessibility problems — the accessibility audit findings document — is written in technical language so that the delivery team (the folks who will make the corrections) can understand the problems and fix them. Not only would we not dream of using these terms when we explain things to users — but we user researchers may not even understand them ourselves. We have to gain enough understanding of the problems to enable us to rewrite the descriptions in user-centred language — descriptions that are correct as well as clear.

Writing the first accessibility statement for a website requires six steps:

1. Create an outline accessibility statement
2. Review the accessibility audit findings
3. Construct the items of non-compliance
4. Discuss the non-compliances with the site’s auditors and revise them as needed
5. Write the summary of non-compliances
6. Finalise the statement

Note that I referred to writing a site’s first accessibility statement. In a forthcoming article I’ll cover updating an existing statement — which is not as straightforward as you might think!

Step 1: Create an outline accessibility statement

An accessibility statement includes a certain amount of background content, such as a declaration of the organisation’s commitment to accessibility and a description of what they are doing to achieve accessibility. This material is quite straightforward to create, and I don’t cover it here. Both the World Wide Web Consortium (W3C) and the UK government offer resources for producing the basic structure and some of the boilerplate material, with blanks for filling in the more technical content. The W3C provides a statement generator tool for those who want a fairly simple starting point, or for a more complex one you could begin with the UK Government’s template for public-sector websites (which we at Nexer have found useful in the private and non-profit sectors as well).

Step 2: Review the accessibility audit findings

Before we can write an accessibility statement, we need to know what the problems are. To do this we study the site’s most recent audit findings document, which summarises what the audit team looked at and lists all of the issues they found. The audit findings document tells the delivery team what’s wrong on what parts of the site, so that they can correct the problems. In most cases, a member of our own development team will have conducted the audit.

An accessibility audit findings document identifies places where the site fails to meet the Web Content Accessibility Guidelines (WCAG) “success criteria” — the features a product must have if it is to be considered accessible. The WCAG standard classifies the criteria into three levels, which we can think of as essential/basic (level A), important (level AA), and advanced (level AAA). Nexer’s audits generally inspect for conformance at levels A and AA.

Step 3: Construct the items of non-compliance

Most of the statements we produce use the template for public-sector websites that are not part of gov.uk. We have become familiar with this template because Nexer Digital do a lot of work in the public sector — and we have found it useful for commercial and non-profit websites as well. This template has two key sections that depend on the audit findings: “How accessible this website is” and “Non-compliance with the accessibility regulations”. We write these two sections in reverse order, because the first is a kind of executive summary of the second, and I cover them in reverse order here.

The bulk of the accessibility statement, and the most work to write, is the list of non-compliances. Two of the fields in the audit findings document determine which issues go into the statement:

• Severity of the issue in terms of its impact on users (critical/ serious/ minor)
• List of relevant WCAG success criteria for the issue, including the level (A/ AA/ AAA) of each criterion

We include all issues associated with at least one level A criterion and all critical and serious issues at level AA.

Each item of non-compliance has three parts:

1. The description of the problem. Using plain language, this sentence describes the problem from the users’ perspective. We put this in bold, to help make the list of non-compliances easier to scan.
2. The WCAG success criterion or criteria that the issue fails to satisfy. Each one includes the WCAG version, criterion number, name, and level.
3. What the organisation plans to do to address the problem, and by what date they anticipate solving it.

The description is the part that needs to be translated from developer-speak to user-speak. Some translations are easy, some are slightly more complex, and some are a bear and require discussions with the person who conducted the audit.

Easy translations

Some descriptions require little work to translate. Easy ones I’ve seen include “missing alt text” and “inadequate text/background contrast” and “skip links cannot be accessed via keyboard” and “skipped heading level” — and even “link text used for multiple different destinations”. To me it’s clear what those mean and how to adapt them to users’ language; in fact, some need almost no rewording. Here are two examples from a recent accessibility audit:

Issue Description:

• Link identified by colour alone

WCAG 2.2 reference:

• Level A: 1.4.1 - Use of Colour

Issue Description:

• Hard-to-read text contrast

WCAG 2.2 reference:

• Level AA: 1.4.11 - Contrast (Minimum)

For each one, I reworded the description into user language, added the relevant success criterion, and suggested what the client might do about it   — and voilà! they became the following items of non-compliance in the statement:

• Some parts of the website use colour as the only means of conveying information. This fails the following WCAG 2.2 success criterion: 1.4.1 (Use of Colour, Level A). We plan to ensure that, by [date], all parts of the site that use colour to convey information will use at least one other means as well.
• In some places the colour contrast of text or images is too low. This fails the following WCAG 2.2 success criterion: 1.4.3 (Contrast (Minimum), Level AA). We plan to bring the colour contrast of all text and images into compliance by [date].

We leave the date blank because it is for the client to fill in.

Medium-difficulty translations

Other accessibility issues may be slightly more complex to turn into an item of non-compliance. This is often because they involve more than one success criterion. Here’s an example:

Issue Description:

• Broken skip link

WCAG 2.2 reference:

• Level A: 2.1.1 – Keyboard
• Level A: 2.4.1 – Bypass Blocks

I simply included both success criteria in the non-compliance item (in numerical order). Here’s what I ended up with:

• Some of the skip links do not work. This fails the following WCAG 2.2 success criteria: 2.1.1 (Keyboard, Level A); 2.4.1 (Bypass Blocks, Level A). We plan to ensure that all skip links work properly by [date].

“Broken skip link” became “Some of the skip links do not work” — “some”, because this issue appeared multiple times in the audit and we don’t repeat an issue just because it turned up more than once.

Tricky translations

Sometimes the issue described in the audit will be difficult to understand, let alone to translate into users’ language. Here are two examples of this:

Issue Description:

• 3 X Empty button

WCAG 2.2 reference:

• Level A: 1.1.1 - Non-text content
• Level A: 2.4.4 - Link Purpose (In Context)

Issue Description:

• Mobile - Search - identifies as “capital L"

WCAG 2.2 reference:

• Level A: 1.1.1 - Non-text content
• Level A: 2.4.4 - Link Purpose (In Context)

I didn’t understand these descriptions well enough to write them for users. (I did have an idea of what an “empty button” might be, but I wasn’t sure how it would affect the users’ experience.) So I put them aside to be addressed in a discussion with my colleague who had audited the site (see Step 4).

Although I had an inkling of what “empty button” might mean, “identifies as capital L” was a mystery. Fortunately, the accessibility auditor was able to explain them. It also turned out that they related to the same problem from the user’s perspective, so I combined them into one item of non-compliance:

• Some links fail to indicate their purpose, usually because either they contain no link text or they are image links with missing or inadequate alt text. This fails the following WCAG 2.2 success criteria: 1.1.1 (Non-text Content, Level A); 2.4.4 (Link Purpose (in Context), Level A). We plan to update all links so that they indicate their purpose by [date].

A beauty of the audit findings documents my Nexer colleagues do is that the issues list appears in an Excel worksheet — which allows us to sort the issues in numerical order of the WCAG criteria that apply to them. We arrange the statement’s list of non-compliances in the same order, so that we can check the statement against the audit to make sure we’ve covered all the relevant issues.

Step 4: Discuss the non-compliances with the site’s auditors, and revise them as needed

Your draft will almost certainly include issues for which you haven’t quite captured the user’s perspective — and if you’re like me, there will be some you don’t understand at all. Most of mine involve a technical aspect that’s outside my knowledge, which means I am unable to identify how the finding’s description relates to users’ experiences. Technical descriptions that have stymied me include “main landmark must contain all of the page's primary content” and “non-accessible content anchor link - updates user visually but not tab navigation”.

Other times I halfway understand a technical description, just not well enough to be sure I’ve translated it correctly. Examples include “missing modal trap” and “cookie preference modal - radio options missing focus states”. I like to think that after doing a number of accessibility statements I’ve developed a bit of a clue about what these kinds of things mean. But I still find that I always need to run several issues by the auditor — once to make sure I understand them, and a second time to confirm that I’ve described them correctly from the users’ perspective.

This process may take two or three iterations to be sure you’ve got them all.

Step 5: Write the summary of non-compliances

The detailed items of non-compliance constitute a formal list of the website’s accessibility issues and what the site owner plans to do about them. In addition to this, users need a simple summary so that they can get an idea of what to expect without having to wade through the gory details. We write the simpler part in a section called “How accessible this website is”, which I like to call “Hatwi". Before we can write this, though, we need to make sure we’ve got the non-compliances right — which means that we produce the summary section last. We can think of this section as a kind of executive summary.

Here's how I build the summary: First, I copy all of the non-compliance paragraphs into the blank “Hatwi” section. Then I bulletise them and delete everything from each bullet point except its first sentence. The four issues I described in Step 3, above, left me with these points:

• Some parts of the website use colour as the only means of conveying information.
• In some places the colour contrast of text or images is too low.
• Some of the skip links do not work.
• Some links fail to indicate their purpose, usually because either they contain no link text or they are image links with missing or inadequate alt text.

The first two are about colour, so I combined them. I merged the one about skip links with other non-compliances relating to keyboard navigation. And the one about links not indicating their purpose stood on its own.

Step 6: Finalise the statement

Finally, we can fill in the background/administrative information such as the user journeys used in the audit and the date when the statement was last updated. That is pretty straightforward, and you can find information on it in the W3C’s guidance for the content of accessibility statements and in the UK Government’s template for public-sector websites.

Next steps

OK, so you’ve finished preparing an accessibility statement. But the work doesn’t end there. An accessibility statement is a living document, you see — site development will continue and the issues will change, and the statement needs to be kept current so that it always gives users up-to-date information on what they can expect to experience. Naturally, the delivery team will correct issues that this audit surfaced. But some issues will take longer to correct than others will, and ongoing development may also (inadvertently, of course) produce new issues. Also, the next audit will almost certainly cover parts of the site that this audit did not explore. We need to make sure we keep the findings from this audit, so that we have a starting point for keeping track of issues and corrections for the long term. We need to keep records that will allow us to keep the accessibility statement up to date.

A systematic approach

As I have shown, the Web offers some pretty good resources to get us started with accessibility statements, but those resources don’t provide a way of transforming the audit findings into a user-centred accessibility statement — and that is the biggest challenge in doing this work. Translating the problem descriptions from one audience to another involves collaboration between people who understand one audience (the delivery team) and people who understand the other (the users). What I’ve described in this blog post is a systematic approach that can help us do that. It can enable us to make sure the statement covers all the issues found, that we address everything we don’t understand, and that we organise the content to facilitate updating the statement as issues are resolved and new issues are found.