Introduction to auditing

To test the accessibility of a website, an audit is required. Audits across an organisation’s web estate should be part of a clear audit framework and plan. An audit requires a number of accessible user journeys to be taken, with difficulties completing these journeys often translating into accessibility issues.

Web Content Accessibility Guidelines (WCAG)

WCAG is the industry standard set of web accessibility guidelines that a website must conform to under the Regulations. It requires that digital content meets its four key principles:

  • Perceivable
  • Operable
  • Understandable
  • Robust 

Each of its guidelines are given a conformance level with the success criteria based on the impact they have on design or visual presentation of the web pages. Under the regulations, websites must meet all Level A and AA criteria: 

  • Level A – Success criteria are those which will have a high impact on a broad array of user populations. In other words, they (usually) do not focus on one type of disability alone. They will also have the lowest impact on the presentation logic and business logic of the site.
  • Level AA – Success criteria will also have a high impact for users. Sometimes only specific user populations will be impacted, but the impact is important. Adherence to these success criteria may impose changes to a system’s presentation logic or business logic.

WCAG is a subjective and comprehensive set of guidelines so many organisations choose to use an interpreter to simplify and build their audit process around, such as WebAim’s WCAG 2.1 AA Checklist. 

Audit Tools

The following tools are important when completing a detailed audit: 

Screen Reader – NVDA, VoiceOver/TalkBack (mobile)

Magnifier – Windows Magnifier/ZoomText/OS X Magnifier

Automated Tools – Microsoft Accessibility Insights & Axe 

Other Tools – W3 Validator, WebAim Contrast Checker

Automated vs Manual Checks

Automated tools are readily available to help test accessibility but commonly only pick up 20-30% of issues present and therefore do not make a satisfactory alternative to testing performed by humans. 

For example, an automated tool may identify that an image does not have an alt tag, but it cannot determine if an alt tag is a suitable description of the image. 

Comprehensive audits of all digital content utilising both manual auditing and online tools is the most reliable way to pick up accessibility issues and give detailed direction towards compliance. This is also the most time consuming and resource heavy method of auditing.

To make use of this method you will need a dedicated auditing team which should be sized based on your organisation and expected workload. If you struggle with resourcing accessibility auditing this method will cause a significant backlog to complete audits.

Audit Scope

An organisation may host many web-based systems that need to be made accessible under the Regulations. Due to the resource that an audit takes, it is important to identify the highest priority sites. The following questions can be asked of each system to help prioritise: 

  • Is the website public facing?
  • Does the website host a statutory process?
  • Does the website have a high amount of traffic?
  • Does a high proportion of the website’s traffic come from users with additional access needs?
  • Has the website had queries regarding accessibility?
  • Have high risks already been identified in a previous audit (re-audits)?

When an audit has been confirmed for a system, the scope of the audit must be decided. Ideally, all web pages and user journeys would be checked but this is often too resource-intensive. Many pages on a website share the same components and markup (and therefore the same accessibility issues), so the workload can be decreased by performing a ‘dip-test’ to pick a representative set of pages/components to audit. A standard example of a dip test could include:

  • Home page
  • All primary navigation pages including search functionality
  • All primary footer pages
  • Pages more likely to be accessed by users with additional access needs
  • Pages that are mostly text based
  • A selection of pages with images, video and audio content
  • A selection of pages with interactive tools and transactions (e.g. forms)
  • Pages including login functionality
  • A selection of documents and PDFs
  • Dynamic content (e.g. pop-up windows)
  • All pages containing information about accessibility, how to contact you, how to use your site, legal information and any settings/preferences pages.

Audit Process Example

Pre Audit

  • Identify system to audit 
  • Speak with system owner to arrange access and agree scope

Audit

  • Takes approximately one week
  • Completed by specialist auditor
  • External auditors charge ~£800 per day (based on G-Cloud prices)
  • A management-level report and a fault log detailing specific issues is produced

Post Audit

  • Results fed back to system owner 
  • A remedial action plan is produced
  • Once issues are resolved, a re-audit is scheduled
  • If issues cannot be fixed (e.g. no control over the product), a disproportionate burden assessment could be carried out