Introduction
In this blog post, Digital Accessibility Intern David Buik explains what accessibility statements are, what goes into making them, as well as various things he has learned from experience in this domain. He also talks about a tool he has started developing to make the process more beginner-friendly and efficient.
Note: This blog post was originally prepared in August 2025. While the relevant sections have been updated, much of the discussion around “my work” refers to work undertaken in the summer of 2025.
Table of Contents
What is an accessibility statement?
As defined by the UK government:
An accessibility statement is a page of content on your service which:
- shows people how we can be confident our services are accessible
- allows people to contact us if they get stuck
- stops people wasting their time if they won’t be able to use the service
- empowers people to hold us accountable if we are not fulfilling our responsibilities
- helps our services to be legally compliant
UK Department for Work and Pensions – Accessibility Statements
Why is it important to have accessibility statements?
The government’s definition of an accessibility statement provides a good summary of this. However, let’s look closer at some of the points it covers:
The people
At its heart, accessibility is about people. An accessibility statement is a public promise that you care about creating an inclusive experience for everyone.
There are a few reasons why accessibility statements are useful to people:
- Trust: publishing an accessibility statement shows users that you care about them, and that you aren’t afraid to acknowledge your service’s accessibility limitations.
- Time: users who rely on assistive technologies for example, can save a lot of time by reading the accessibility statement before exploring the rest of the site. This helps them manage their expectations as to what will be possible for them to do on the site, which in certain cases might be very little.
- Feedback: multiple sections in an accessibility statement will point the user to places where they can give feedback on the statement itself, or the accessibility of the platform on which the statement has been published.
The law
To make sure that everyone can enjoy the benefits of accessibility statements across as many platforms as possible, the UK government put in place some legislation. This legislation requires public sector bodies (e.g. the government itself or most UK universities) to publish an accessibility statement on any website or platform for which they are responsible, and to update it every year. Note: although this legislation applies equally to websites and applications, I will focus on the example of websites throughout this blog post.
The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018
What an accessibility statement looks like (Screenshot of the Wooclap Participant Interface Accessibility Statement)
What does an accessibility statement look like?
For any UK website, the accessibility statement must closely follow the UK government’s model accessibility statement. Most UK accessibility statements are therefore pretty much identical in terms of structure, although they do of course differ in content.
UK Government’s Model Accessibility Statement
Making a statement
Before you can write an accessibility statement, you need to test your website against a specific set of rules (criteria). This is where the Web Content Accessibility Guidelines (WCAG) come in. Created by the World Wide Web Consortium (W3C), WCAG is the internationally recognised benchmark for web accessibility.
The guidelines are organised into three levels of conformance: A (good), AA (better) and AAA (best). The law in the UK requires public sector bodies to meet the Level AA standard of the most recently published set of criteria, which at the time of writing is version 2.2.
Web Content Accessibility Guidelines (WCAG 2.2)
World Wide Web Consortium (W3C)
The process of creating an accessibility statement involves two main steps:
Step 1 – the web testing report
This document helps the accessibility tester evaluate the website systematically. Web testing reports are conducted in multiple ways across the UK, largely depending on the preferences of the organisation doing the testing.
For example, there exists such a thing as the Website Accessibility Conformance Evaluation Methodology (WCAG-EM). This is the methodology published by the W3C itself to accommodate “anyone who wants a common procedure for auditing websites”. However this methodology’s highly rigorous structure results in an inefficient process for testing websites, as it forces the user to assess each page of their testing sample against each criterion, one by one.
Website Accessibility Conformance Evaluation Methodology (WCAG-EM)
The W3C also maintains the WCAG-EM Report Tool, which takes the user through the process and automatically generates a structured report.
The University’s current methodology
A different methodology is the one which we use at the University of Edinburgh, and this is the one I have been using in my work. This methodology consists of a template where the tester is to replace the relevant placeholder text with their own details, and most importantly, a list of 21 questions which less directly cover all of the relevant WCAG criteria and more. Here is an example of a question from the template as well as each criterion it covers and an example answer:
Accessibility of audio/visual content
- Is there a transcript? [1.2.1 – Audio-only and Video-only (Prerecorded)]
- Are captions automatically enabled on audio/visual content (if not is the method for turning them on accessible?) [1.2.2 – Captions (Prerecorded)]
- Are captions human corrected? [N/A]
- Are there live captions for live time video? [1.2.4 – Captions (Live)]
- Is there an audio description? [1.2.5 – Audio Description (Prerecorded)]
Example answer: There does not appear to be any audio or video content on the site.
This methodology allows the user to perform accessibility tests without in-depth knowledge of the WCAG standard, and also makes testing much quicker and easier. This is even more so the case now, as Goda Katkute, Disability Information Analyst, has recorded web accessibility testing video tutorials – which are available through hyperlinks on the web testing report template mentioned above – to guide users through each stage of testing.
Step 2 – the statement
Using the University of Edinburgh methodology still, we have another template, this time for the accessibility statement. The statement has much more content that has to be included, so this University-specific template will be much more similar to any template other UK organisations might use, which will itself be based on the government template.
It is once you have the final version of the web testing report that you can prepare the accessibility statement. The most time-consuming part of the statement preparation is the lists of all of the general accessibility issues and specific WCAG non-compliances.
The first list
How I proceed with making the first list is by opening up the web testing report at the last section – the areas to improve – and rephrasing the points from the form “Ensure all content can be reached by keyboard only” to “Not all content is reachable through keyboard-only navigation“, for example. This ensures grammatical sense is maintained.
The second list
For the second list, you must provide a description of each error and add a link to the relevant WCAG criteria. Some of the general accessibility violations listed in the previous list might not actually be WCAG violations so you have to be careful with that, while also making sure that you do not miss anything.
A legal document
It is important not to forget that the accessibility statement is a legal document, and there are therefore certain turns of phrase that take some getting used to.
An improvement roadmap
Once you have finished and published the statement, the site owner should put in place basic, as well as complete, solutions to the errors listed in the statement within the deadlines set in the statement.
A tricky but important process
As you may have noticed, this whole process is extremely time consuming – despite the efficiencies provided by having the web testing report and accessibility statement templates – and it is difficult for development teams to stay on top of this workload without a dedicated person handling it full-time.
Accessibility information at the University
While it may seem difficult, it is critical for all people involved in the process of creating content to put accessibility at the centre of their design, as I stressed in my blog post, Diary of an Accessibility Intern (Weeks 1-4). Within the University of Edinburgh, the Disability Information Team provides multiple training sessions to facilitate the creation of accessible content as well as training on accessibility testing and statement writing.
Accessibility Training – Disability Information Team
Diary of an Accessibility Intern (Weeks 1-4) | blogs.ed
Lately, I’ve been experimenting with ways to make the process of preparing and publishing statements faster. Below are a few outcomes and resources resulting from this work:
Doing statements differently?
Using the templates
While I was really glad to see that I wouldn’t have to work with the WCAG-EM, since I had the templates, I still found that there were a few inefficiencies in the current testing report template. Firstly, the most optimal order for tackling the questions is not the exact order in which they are listed. Additionally, there are some sub-questions that would fit within other questions better than where they currently are, not in terms of meaningfulness, but rather in workflow terms.
For example, question 15 asks about tooltips, and one of its sub-questions asks if they are compatible with other assistive technologies. However, these other assistive technologies were covered in questions 13 and 14, which leads to the tester needing to reopen the relevant software for a minor test. These inefficiencies are greatly reduced for someone who has done multiple reports and has a good idea of what is coming, but as a beginner, I spent quite a bit of time just trying to learn what the most optimal way to go through the questions is.
A non-linear process
I have realised that a linear system for going through a website does not accurately reflect what a tester needs to consider when going through a site. For example, at some point, the tester needs to get familiar with and explore the site, but the tester also needs to run automated testing software on each of the pages they will be testing.
It therefore makes sense to do the automated testing while going through the different pages.
However imagine a tester spots a video early on. Now they go through the rest of the site, exploring, and doing the automated testing, and then start going through all of the manual testing questions. They get to question 16, which talks about videos, and suddenly realise that they do not remember where this video is, so they have to go through much of the site again to try and find the page with the video.
An accessibility tester, to work efficiently, must follow reasoning patterns which very closely resemble a flowchart. For example:
- Is there an image on the page?
- If yes, does it have alt text?
- If yes, is it suitable? Also, does this image contain text?
- If yes, does it contain: italics, continuous capitals etc.?
This sequence is not intuitive from the layout of the questions, and I only figured out that this was the kind of way I should think about it after various iterations of reports, and thanks to the feedback of Viki Galt (Head of Disability Information) and Lori Anderson (Disability Information Officer) from the Disability Information Team.
Disability Information Team – University of Edinburgh
Embracing non-linearity
For this reason, I designed a branching scenario in ThingLink which goes through the web testing report process in the way I have found most optimal so far. The image below shows the backend of this scenario, which is effectively a flowchart. You can access the scenario by clicking the link below (University of Edinburgh ThingLink guidance is also linked below):
Accessibility testing workflow branching scenario
Accessing ThingLink within the University
Accessibility Statement for ThingLink | Learning Technology | Information Services
The accessibility audit tool
While I was designing this scenario, I realised that there were still some major hurdles for someone who has never tested a website, let alone written a report: they need to write a lot, they may not know where to include screenshots and they can still face issues like the tooltips I mentioned above.
Knowing about the WCAG-EM tool, I have spent some time trying to create an online tool that has a flowchart workflow baked into the ordering of its questions. This allows the user to systematically click radio buttons or tick checkboxes and easily log elements so they do not forget the locations of elements such as videos. They can then just click a button and get a full report in the exact format of our templates.
Currently, the tool supports almost all of the testing report questions and can export the data as a JSON file, at which point a python backend compiles the JSON into a Word document of the form of our latest template. I am now trying to improve the user prompting and tips around the interface as well as general user experience.
The tool was largely built with my own new pal Claude (referencing Karen Howie’s blog post, My new pal Claude…) – although I have recently managed to get an ELM api key, so most of the development happens locally through ChatGPT Codex.
Here are a few screenshots of what my tool looks like (as of writing):
Screenshot showing current state of the accessibility audit tool header
Screenshot showing the current state of a question in the accessibility audit tool’s guided mode.
Conclusion
Accessiblity statements are legal documents, but they are not just legal documents. Accessibility statements are a way for websites and applications to show their users that they are aware of the different limitations which users themselves may encounter, and that they are attempting to do something about them, to drive change.
The process of creating an accessibility statement is not a simple one, however we, at the University of Edinburgh, are lucky that the Disability Information Team provide so much information on the topic of accessibility, including the training sessions mentioned above. The whole team also helped a great deal with the making of this blog post.
I hope we can keep improving our testing methodology, and always keep humans at the centre, as accessibility is a human problem at its heart. The accessibility audit tool is one direction in which I believe we can improve the flexibility of how we do accessibility testing, and I am happy to receive and answer any questions, feedback or suggestions in regard to that. Feel free to contact me on Teams, or to email me (link below).
Contact Me (opens in a new window)