The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 requires that each platform and its content are accessible, within the timescales. This means you need to list all of your platforms, assess what work might be needed to make sure that the platforms and their contents are accessible, and a plan to fix them and test with assistive technologies.
By auditing we mean reviewing your current content and platforms to check they meet the requirements of the regulations and conformity with WCAG 2.1 AA. Ideally, your service owners and content creators will be designing with accessibility in mind so that auditing process should be more about fine tuning than fundamental overhaul.
Ultimately all of the digital content accessible to your external users (barring a few exemptions) is required to meet the regulations and required to meet WCAG 2.1 AA. Our post on exemptions outlines some areas that are not required to meet the regulations immediately, but our approach is that we should be making all key content accessible as it is the right thing to do, notwithstanding regulatory obligations.
For some public sector bodies this may be a huge undertaking and certainly not something that can be done overnight. This is where your Accessibility Statement will help – outlining what you have already made accessible, what work you still have to do and, crucially, how people can get help with your content where they need it. We think the Accessibility Statement is a great opportunity to help your users to get the best from your site regardless of whether they any particular accessibility requirements.
Nevertheless you will still need to have a clear roadmap and strategy for managing the auditing and remediation of accessibility issues in order that your content is always moving in an accessible direction.
Prioritising your Auditing
A good approach is to prioritise core content by identifying the most likely user journeys that people are likely to take when accessing your digital content (perhaps identified by looking at web page analytics to find the most frequently viewed pages alongside feedback from focus groups and surveys with users). The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 (2014) reinforces this approach by assessing web pages and web page states that are relevant to the entire website. This includes the homepage, login page, and other entry pages, and, where applicable, the sitemap, contacts page, site help, legal information, and similar web pages that are typically linked from all other web pages (usually from the header, footer, or navigation menu of a web page) as a starter for 10.
This is a helpful approach as it takes the onus away from purely considering pages and moves the focus to user journeys. After all, although a bad page is clearly a thing that needs fixing, none of us ever look at one single page. Instead, we have a user need, we start from somewhere, we will probably visit a few pages and then we get what we need (which might be some information or possibly some form of action such as filling in a form and getting a response). Instead of auditing pages in isolation, we therefore recommend that you identify and audit key user journeys.
Based on our existing experience as public sector organisations with large web estates, we made the following prioritisations based on a number of factors including; increased impact on selected groups by online service, resources available, volume of traffic. Our prioritisations are:
- Pages on our main .gov.uk / .ac.uk domains and other services that have been assessed as high risk or having a disproportionate impact on user groups that have a statistically high overlap with users who have additional access needs.
- The remaining areas of our main .gov.uk / .ac.uk domain, receiving greater focus because this is our main channel of communication and as such has higher traffic than any of our other websites.
- Other existing audits and remedial actions. Where we have completed audits already, we want to remove those identified risks as much as possible. When a site is ready to be reassessed we raise the priority, to help us demonstrate progress on resolving identified issues.
- Newly requested audits. Where new audits are added to our plan, either for completely new sites before go live or for existing sites we have not yet assessed, if the are not identified as a high risk area, they are added to the audit forward plan and given a lower priority.
- Audits as part of procurement processes. Where audits are requested to test systems during a procurement process, these will be included into the forward plan on an adhoc basis.
Methods of Auditing
There are many methods of auditing that may be appropriate for your situation. We go into some detail in our Methods of Auditing article. In the article we cover:
- Online tools
- Manual audits
- Comprehensive audits
- User journey testing
- Outsourcing audits
Managing your audits
You may have many websites that require auditing, and as you move through the process with each of them, conduct reaudits and complete remedial actions, you will need a method of monitoring all of that information and being able to feed it back to management.
The Auditing programme log TEMPLATE we have been using to monitor the state of each of our audits has been working successfully for us and we believe that it collects all of the information we need to quickly understand the situation of any given system and for future members of staff to pick up work that has been completed previously without the need for handover.
Remedial Action
Once you have a completed audit and have identified areas that require remedial action you will want to feed this back to two different groups.
The first group is the service owners and management. These recipients will be more interested in the strategic thinking the results feed into, and as such our Managers Audit Report TEMPLATE provides background information, an overview of compliance requirements, disclaimers on the timeliness of the report, an overview of each point of compliance and then high level information on each of the points of failure and remedial action required.
The second group will be those responsible for the digital content from a technical perspective, including staff responsible for content, and either internal or external web developers. Our Technical Audit Report TEMPLATE specifically details the page and url that has the identified issue, what the issue is, the point of compliance it fails against, and what we believe needs to be done to resolve the issue.
We normally provide both reports back to the service owner and expect that they will share the Technical report with their developers or content owners as a specific list of actions to be taken.
Working with suppliers
In many cases your digital systems may be provided by a 3rd party supplier. You will need to work with your suppliers to identify which areas requiring improvement are your responsibility and which are theirs. Our Working with suppliers article goes into more detail.
What to do if you cant make it accessible
There is a possibility that despite best efforts you reach a point in which no amount of effort will improve the accessibility of your current system and you have no recourse to change this situation. What do you do when you reach ‘end of the line’ scenarios? Some things to consider:
- Making a case for disproportionate burden
- Start looking at alternatives and your contract renewal timeline
- If you have to stick with the product, will there be improvements in the next version and how soon can you upgrade?