From statement to roadmap: Communicating your plans for improving your Web accessibility

You may have noticed that the GOV.UK sample Accessibility Statement suggests including a link to your website accessibility roadmap, if you have one. Although many organisations don’t have such a roadmap, you might consider providing one. An accessibility roadmap can convey, both to your team and to users and other interested parties, what plans and steps you have for improving accessibility. And if you’ve built your Statement according to the government’s sample, it can make the roadmap straightforward to produce. Here’s how to use your Statement to build a roadmap.

A website accessibility roadmap is a document that sets out your goals for improving a site’s accessibility. It gives the steps you have defined for achieving those goals and the time period in which you will perform those steps. An accessibility roadmap follows the GOV.UK guidance for roadmaps in general, with its content tailored for website accessibility.

The answer is usually simple: You need one roadmap for each Accessibility Statement you have. Some organisations use multiple websites to provide multiple services, and as such they have an Accessibility Statement for each site. These organisations need to provide multiple roadmaps.

If you do have multiple sites with separate roadmaps, you might want to produce an additional roadmap to cover the bigger picture. This would describe your plans for improving the consistency of accessibility of the entire collection. It could explain, for example, the order in which you might address the individual websites. You would need to prepare the individual ones first and then identify how to describe the overview.

The rest of this guide describes how to build one roadmap. You will need to follow this process for every roadmap you build.

An accessibility roadmap begins with an introduction in which you state your goals and time period and provide a high-level overview of the steps. Here is a sample paragraph you could use for this:

The accessibility goal for [domain] by [specific date] is “make [domain]’s services and content more accessible to its users.” During this time we’re going to fix [all/most/some] of the non-compliances we’ve described in our Accessibility Statement, as follows:

The time period should not be a length of time: phrases along the lines of “the next 3 months” require the reader to figure out the start and end dates. It should say “by [specific date]”. Do not be afraid of giving an end date that may turn out to be overly optimistic; if you get partway there and discover that it’s going to take longer than you expected, just change the predicted end date and publish the revised roadmap. People generally understand that things change, but if you start out vague you will lose their confidence. Similarly, give relatively end dates in the relatively near future, if you can, rather than asking users to wait for a year or more to see their experiences improve. This is especially important for issues with a substantial impact on the experience of users of assistive technologies.

With respect to the “[all/most/some]” part of this paragraph, choose the word that best reflects your estimate of how many of the issues you can address in the time period you’ve stated.

As for goals, if you can state them more specifically than just “make [domain] more accessible”, then do so. If, for example, the accessibility issues all relate to videos, say so: “Make [domain]’s videos more accessible”.

Now explain what you’re going to fix and when.

Start by arranging the non-compliances according to the accessibility issues summary that appears in the Statement as bullet points under the heading of “How accessible this website is”. Organising them this way takes advantage of two important characteristics of the bullet points:

• Worded in user-centric language
• Arranged in order of decreasing impact on users of assistive technologies (hopefully)

Both of these characteristics are likely to help people understand the roadmap and find out what you plan to do about issues they care about.

Some of the bullet points may well mention multiple issues. For example, one accessibility statement we wrote for a client included the following bullet point: “Some images are missing alternative text, some of the alt text that exists does not provide equivalent information, and some content appears as images of text.” These three issues appear in the same bullet point because they all involve non-textual information, but two of them relate to alt text and the other is an entirely different technical problem. If you run across a bullet point that includes multiple issues, use your judgment to decide whether to split them up or keep them all together. In the case of this example, you could list all of the issues separately, or you could include the first two in the same line item because they both relate to alt text. (The examples that appear later in this blog post group these first two together.)

If your Statement includes issues that you uncovered through inclusive usability testing, cover these as well. Even though they may not all map to WCAG success criteria, they do affect the experiences of people who use assistive technologies, and your roadmap should convey your plans for addressing them. Slot them in with the others according to the severity of their impact on UX.

The roadmap needs to give users meaningful information about when they can expect to see that a problem has been corrected. This is why the target date must be specific, even if you think you may need to change it later. Do not use “ongoing” as a target date.

Present your list of issues and actions as either a table or paragraphs with headings. The following subsections illustrate both approaches.

Do not use this section to list issues that are out of scope, such as PDF documents that were published before 23 September 2018 and are not essential to using a service. List those in a separate section at the end of the roadmap.

One of the bullet points in the issue summary says:

• Some images are missing alternative text, some of the alt text that exists does not provide equivalent information, and some content appears as images of text.

The next two sections give examples of presenting the plans via a table and via headings.

This sample table groups the above bullet point’s first two issues together because they both relate to alt text and you can accomplish them with one process — inspecting alt text and either adding it (if it’s missing) or editing it (if it’s inadequate), so that it provides equivalent information to what the image depicts. The table lists the third issue separately because it requires a somewhat different process and you may need to decide how you’re going to approach images of text.

List the issues in order of their sequence in the summary bullet points, not in order of date. This will help readers find issues that interest them and then discover when you plan to fix those issues.

Here's an example of how you might use a table to present part of your plans.

Here's an example of how you might use headings to present part of your plans. This example treats alt text and images of text separately.

Accessibility issue: Alt text

Some images are missing alternative text, and some of the alt text that exists does not provide equivalent information.

How we will fix alt text

We will check all alt text for existence and content. Where it is missing, we will add equivalent alt text to informational images and null alt text to images that are purely decorative. Where it is provided but is not equivalent, we will edit it to make it equivalent. We will complete these activities by 31 January 2025.

Accessibility Issue: Images of text

Some content appears as images of text.

How we will fix images of text

We will replace all images of text with screenreader-friendly text by 14 March 2025.

Accessibility Issue: Colour contrast

Some elements have inadequate colour contrast and are hard to make out.

How we will fix colour contrast

We will modify the colour contrast of all non-compliant text and images, so that all elements will satisfy the WCAG success criterion for colour contrast by 14 February 2025.

Use whichever format you think will best meet your needs. Nexer have seen some examples of both, and each has its advantages. The table format makes it easier to see the dates, while the heading format makes it easy to identify the categories of issues. (We do not recommend adding a column for Category to the table.)

In addition to the issues you plan to fix, your audience would benefit from knowing which ones you do not plan to fix. These include older, non-essential PDFs, for example, and issues for which you have claimed undue burden in your Accessibility Statement. Almost certainly some users will have encountered them, and it’s important to list these issues in the roadmap rather than appearing to be hiding or ignoring them.

Consider keeping an appendix that gives a history of corrections, so that your audience can see what you’ve done. You don’t need to go back an extreme amount; probably twice the time period would be enough. For example, if your stated end date is three months after your publication date, then list the corrections you made in the six months before the date of the current version of the roadmap.

Keep the Roadmap (and the Statement) up to date. When you have fixed an issue and have verified that it no longer exists anywhere on your site, remove it from the Roadmap and update the Statement at the same time. Users do not need to be burdened with information about issues that do not exist, although it would be helpful to provide information on issues they may have seen previously. Use a separate section — an appendix — for “recently resolved issues”.

We will update this roadmap by [date], to reflect any plans we may need to establish for fixing the non-compliances that are beyond our ability to address in [the time period stated at the beginning of the roadmap].