Accessibility audit overview
The Public Sector (Websites and Mobile Apps) Accessibility Regulations of 2018 require public sector organisations to make sure their websites, intranets and apps meet Level AA of the Web Content Accessibility Guidelines (WCAG) 2.1.
Key dates for meeting the regulations
|New public sector websites (published on or after 23 September 2018)||by 23 September 2019|
|All other public sector websites||by 23 September 2020|
|Public sector mobile applications||by 23 June 2021|
Typically an assessment or audit is used to find out whether the standard has been met (or not), but what is an audit and what does it include?
An accessibility audit is an assessment of your website or app against a set of recognised guidelines, in this case WCAG 2.1 Level AA. The purpose of an audit is to verify that your website or app conforms to the guidelines or to tell you what you need to do if it does not.
WCAG 2.1 is divided into principles and guidelines and each guideline has a number of requirements known as Success Criteria (or SC for short). Each SC is assigned a different level: Level A, Level AA, or Level AAA. There are 30 Level A and 20 Level AA SC in WCAG 2.1. The basic premis of an audit is that your website or app is checked against all 50 of them, but there is an obvious problem with this – in most cases it would take too long and/or cost too much to do.
The recommended approach is to audit a sample of pages or screens instead. The idea is that the sample is representative of the whole; in other words it should include at least one example of each page or screen layout, each different type of content, and each different type of functionality.
Procurement tip: look for services that include a test plan so you know exactly what will be included in the audit and what won’t.
If the sample is chosen well it should contain at least one example of most (if not all) possible accessibility issues. Once one instance of an issue has been identified within the sample, the same solution can then be applied to all other instances of the same issue throughout the website or app.
Procurement tip: look for services that offer detailed solutions for each issue and ask to see examples so you know the level of detail provided is what you need to be successful.
An audit is essentially a manual process but tools help make the process more efficient. The important thing is to know when to use a tool and when to do something yourself.
There are tools that can help with checking for things like colour contrast, line height and spacing, or for mistakes in HTML that cause accessibility problems. Developer tools in Firefox, Chrome, Edge and Safari all have features for inspecting the accessibility properties of web page code, and there are tools for scanning and inspecting native apps on both Android and iOS.
Automated tools are useful for quickly testing a lot of pages, but they cannot test for all accessibility issues. Estimates vary, but it is generally thought that automated tools can identify around 30% of possible WCAG 2.1 issues. Those issues are worth monitoring and fixing of course, and the number of issues detected by an automated tool is often a good indication of how well the website is doing overall, so automated testing is certainly a worthwhile part of the process too.
Procurement tip: look for automated testing platforms that are open about what can and cannot be tested automatically.
Assistive tech testing
An audit should include testing with different assistive technologies and alternate input devices, but there is an important distinction to draw between expert testing and proper usability testing: expert testing is carried out by people who do it professionally, usability testing is carried out with people from your target audience (who tend not to be professional testers).
There is a time and a place for both expert testing and usability testing because they both deliver valuable insights. Like consulting with a Doctor and asking someone who completed a first aid course for their opinion, you’ll get two very different but nonetheless valuable responses.
Expert testing is typically included in an audit, whereas usability testing is a separate but complementary service that includes participant recruitment, professionally led test sessions, and results analysis and reporting.
Procurement tip: look for services that are clear about the differences between expert testing and usability testing.
Depending on whether the audit was carried out internaly or by a third party, the results will probably be presented in different ways.
The format isn’t really important though, what is important is that the information is presented in a way that is appropriate to the team who need to use it, that it’s apparent how well the website or app did in the audit, and that there is a clear path for fixing issues and ultimately to meeting the expected standard of accessibility.
There is one final step to an audit and that is making sure that all issues have been addressed, and that no new accessibility issues were introduced along the way. Like all updates, changes and fixes to a website or apps, regression testing for accessibility should be done before considering the task complete.
An audit is generally a single event. Although it’s possible to carry out iterative audits throughout the production lifecycle, it isn’t a good way to avoid accessibility issues in the first place.
Empowering teams with the knowledge and skills they need to design and develop accessible websites and apps, and QA testers with the ability to test for accessibility, is by far the best investment you can make. That said, when legislation like the Public Sector Accessibility Regulations require that a particular standard of accessibility must be met, an accessibility audit is a robust and reliable way to find out whether your website or app succeeds or not.
We're here to help
We are passionate about supporting organisations to create a great experience for 100% of users. Invotra Consulting offers both accessibility reviews and accessibility audits.