What should be included in a digital accessibility audit report?
What is a digital accessibility audit?
An accessibility audit is a set of activities designed to assess the level of accessibility of a digital web, mobile or desktop application. This assessment is made on the basis of tests conducted on a representative sample, usually the entire application or site is not tested, but the tests are limited to a reasonable range, such as a dozen or so sub-pages or screens. The final result of the audit is a report containing information on the current state of application accessibility, as well as errors found and recommendations for their improvement. Based on the documents created during the audit, the ordering party should be able to understand what are the problem areas in the application and how they can be fixed. The audit should be conducted in accordance with an established methodology, e.g. WCAG-EM, and should involve both a technical tester (WCAG specialist) and a real user with a disability.
What is the purpose of a digital accessibility audit?
The primary purpose for which an audit is conducted is to provide objective information on the accessibility of a selected website, web application or mobile application.
An accessibility audit is conducted for two reasons. The first is to determine to what extent the application complies with the formal requirements of, for example, a law or WCAG of a particular level (for example, A). To accomplish this, a technical tester conducts a series of tests to detect digital accessibility issues in the tested elements of the application or site. This part of the audit results in reports of the problems found, including a detailed description and recommendations for improvement. The second reason for conducting an audit is to determine how well the end user with a disability is able to use the application easily and intuitively. To do this, a tester or testers with various disabilities, such as vision, hearing or limited mobility problems, test different scenarios or simply explore the app by going through each screen. During these tests, they evaluate whether particular tasks such as creating an account, filling out and submitting a contact form or finding a phone number on the site are feasible and can be improved in some way. All the insights and recommendations of the testers with disabilities are also enriched by the more technical perspective of the technical tester.
This two-way approach ensures that the information presented in the final audit report is complete. Limiting the audit to only one perspective, i.e., checking only the technical requirements of the WCAG or limiting oneself only to testing with a user with a disability, carries a high risk of omitting important information.
What does an accessibility audit report include?
A typical accessibility audit conducted by our company is finalized with sending the customer a package consisting of four parts:
The main report, summarizing the entire audit - answering the questions: who, what, when, how and with what result? From this document you can find out what was the purpose and scope of the tests, the configuration of the test environments, a description of the method used during accessibility testing. The most important part of this summary is the results of the tests: the number of WCAG criteria met and not met, and the number of problems found, broken down by severity. This is a document addressed primarily to the project sponsor, managers responsible for improving accessibility and those ordering the audit.
Checklist for application compliance with WCAG guidelines - this checklist shows which WCAG success criteria are met, not met, or were not tested in the application because they are not applicable. For each of the unfulfilled criteria, at least one problem is assigned. Each accessibility defect is described in detail, has an assigned severity and a screenshot showing the problematic element. Recommendations for fixes are added to all problems, often enriched with sample solution code. This document is most interesting for frontend and mobile app developers, UI designers implementing fixes and testers responsible for subsequent retesting of the corrected version.
List of problems and suggestions found by a user with a disability - depending on the requirements of the project, a different number of users with different types of disabilities may test as part of the audit. Depending on this, there may be more or fewer reports, but they are all similar in structure. They contain elements that are problematic from the user's point of view and suggestions for improvement. Each problem is described, and recommendations are consulted with the tester responsible for technical testing (WCAG). Part of this list overlaps with problems detected during technical testing, and they are marked accordingly in the disabled user report.
Compressed file with screenshots - this is a collection of screenshots that are associated with the corresponding report requests. In the individual screenshots, elements that cause a problem from the point of view of a particular report are marked accordingly.
What problems are detected during the accessibility audit?
An example of a problem detected in a digital accessibility audit and recommendations for fixing it:
Issue ID: 1
WCAG success criterion: 4.1.2
Summary: The “X” button for closing the modal window “Add purchasing profile” has the wrong name.
Description: The button marked in screenshot 1 for closing the modal window has the name “Add purchasing profile” in the “aria-label” attribute. This name is not correct and may mislead the user.
Recommendation: It is recommended to change the name of the button in the “aria-label” attribute to “Close dialog box”. The correct code for the button should look as follows:
<button type="button" aria-label="Close dialog box">
<img src="/static/media/image.png " alt="">
</button>
Location: Home page
Severity: Blocking
Accessibility audit completed, what's next?
The accessibility audit report is not the end of the job, but the beginning. What happens after the website accessibility testing is completed? Is sending the report files the total end of such a project?
Most often they don't. We realize that just finding bugs and pointing out recommendations is not always enough for a client to start improving application accessibility right away. And because we care a lot about making the world more accessible, we also offer as additional services to the audit:
Consulting on the audit conducted. Consultation can be used by:
UX and UI designers as, for example, system design consultations or new accessible application mockups in Figma or similar tool,
testers to, for example, discuss test scenarios, expected behavior of components, and databases containing examples of accessible components,
developers to, for example, discuss examples of working and non-working code, libraries of good examples or standards such as ARIA
managers responsible for ensuring accessibility, to discuss strategies for approaching the process of ensuring and improving accessibility in the long term.
If more is needed after the audit during the consultation, we always offer the option of buying additional time, or if it is more efficient, to conduct a team training or workshop addressing a specific need..
Retests of fixes made. Retesting is performed to verify that corrected issues, both WCAG-related and those discovered during user testing, have been fixed correctly and that corrected elements behave in accordance with accessibility requirements. During retests, we only check previous submissions by assigning them a status of “ Fixed” or “ Not Fixed” and adding a comment or recommendation for further improvement.
Accessibility reaudit after all corrections have been made. During a reaudit, in addition to re-testing fixes to see if they have been eliminated we also recheck all other elements in the application tested during the first audit. This allows us to make sure that no new bugs have been introduced into the site and that, after the corrections, the site complies with WCAG requirements and is usable by people with disabilities. In an optimistic scenario, the final report from this audit shows no unfulfilled WCAG criteria.
Maintaining accessibility over the long term is a complex topic. Implementing accessibility in an organization is a project involving the creation and modification of processes for developing, implementing and maintaining software, selecting, implementing and configuring tools, automation, monitoring the production environment.... But this is a topic for a separate article. You should certainly consider implementing proactive accessibility monitoring. It can be done in-house or outsourced, the important thing is that it takes place regularly and results in real actions (fixes). One possible solution is a accessibility as a service package tailored to specific needs.
Practical information
Accessibility debt, or a large number of accessibility defects, is one part of the so-called technical debt. In our experience, companies or organizations ordering an accessibility audit of their websites or applications are often surprised by the number of problems we detect. It's worth preparing for the fact that there will be dozens or even hundreds of them, and scheduling time in advance to correct them. Digital accessibility training for UX designers, developers, testers and managers can also be useful.
The cost of a mobile or web application accessibility audit depends on many factors. It is worth taking them into account even before deciding to order such a service. We described most of them in a separate article, read if you want to know what impacts the price of a digital accessibility audit.
Discussing the accessibility audit report is definitely a good practice. It can be organized in the form of an online meeting. It is worth inviting all the people who will be involved in planning the work, correcting and testing the detected problems. It is usually enough to allocate 60-90 minutes for such a presentation. Technical details, such as how to correct specific problems, are not discussed at this stage. The goal is primarily to communicate the completion of the work, the results and preliminary plans for the next steps.
Kacper Mikocki
Co-founder of Accens, responsible for the area of testing and training
Specialises in technical aspects of digital accessibility, has completed several dozen accessibility testing projects and WCAG audits. Leads accessibility courses and develops additional training materials. Software tester, webmaster and digital accessibility consultant. Certified IAAP Web Accessibility Specialist (WAS).
Are you considering an accessibility audit of your website or mobile app? Want to check its current WCAG compliance? Check out our accessibility testing or WCAG audit offer. We also provide digital accessibility training, where you will gain the knowledge you need to address the actions resulting from the audit.