Accessible Website Auditor
Allowing blind and low-vision individuals to advocate for themselves through website accessibility auditing
Problem: Detroit Disability Power (DDP) provides consulting to businesses and organizations to support their accessibility goals. Many clients seek out DDP to request accessibility audits of their websites. The demand for website audits is more than DDP’s small team can handle. DDP has identified an opportunity to build a paid Task Force program composed of disabled individuals trained in performing online accessibility audits as paid subcontractors. As part of this initiative, DDP would like to create a tool that will train people from DDP’s member community to perform online accessibility audits.
Goal: Design a digital solution to help blind and low-vision individuals to perform accessibility audits of websites. Our team decided to limit our scope to designing a tool to help blind and low vision individuals, as trying to design for individuals of all disabilities would be prohibitively complicated given our timeframe.
Solution Overview: The proposed solution, “Accessible Website Auditor” (or AWA for short) allows users to report accessibility issues for specific screen elements when viewing a website. Issues that the user finds are compiled into a comprehensive report, which is sent to the website owner. Users learn this simple workflow through a step-by-step tutorial in which they perform a practice audit.
Project Duration: 3 months
Team: 3 members
Tools: Figma
Process
Formative Study
User Interviews and Observations
To determine what target users needed in a solution to help them to learn how to audit websites, we interviewed seven blind and low-vision individuals. We also observed them using WAVE- a popular automated auditing tool, as they performed brief accessibility audits. Our research produced the following major findings:
-
Most blind and low-vision users use screen readers to navigate the internet
-
Some websites that are WCAG-compliant are still difficult for blind and low-vision users to use through their screen readers
-
Automated auditing tools are barely accessible by screen reader users. For example, WAVE has a poor HTML hierarchy in its errors results tab, and AXE requires users to use the browser’s developer tools panel, which requires HTML knowledge
-
Some blind and low-vision users had experience in website auditing and felt confident performing manual accessibility audits without the use of automated accessibility auditing tools
Design Criteria
Based on our findings, we decided on several design criteria for our digital solution so that it could help blind and low-vision individuals to easily learn how to perform web accessibility audits:
-
The tool must be screen-reader accessible, smoothly usable, and controllable solely through a keyboard or screen reader interface
-
The auditing process should provide easy workflows to handle frequent screen reader accessibility problems
-
The solution should support manual audits to allow disabled users to leverage their perspective and experience
Ideation
We brainstormed several ideas based on our findings. We then chose the idea that best fit our design criteria, to further develop and refine.
The idea that we chose, allows users to report accessibility issues of screen elements on a website that they are browsing. The tool annotates a copy of the website's HTML, with the user's feedback, and sends it to the website owner. The user would learn this tool’s simple workflow through a step-by-step tutorial.
After selecting the best idea to refine, we also gave it a name- "Accessible Website Auditor".
The wireframe for the idea that was further developed into AWA
Usability Testing
We coded a screen-reader accessible, interactive prototype in HTML, CSS, and JavaScript and performed usability tests with target users.
Usability Test Findings
Several of the most important findings from the user tests included:
-
Screen reader software responds to key commands, which conflict with any key commands that websites or plugins might accept. Digital tools that require key commands to work cannot function properly unless the screen reader is on "forms mode"- in which it does not intercept key commands
-
Users would have liked to review the previous issues they had reported while auditing so that they didn’t have to recall the issues themselves
-
After completing the tutorial, some users were unsure about the capabilities of AWA, such as if it could be used to report multiple issues with a website or what types of issues it would be able to report
Design Changes
Due to these findings, we refined the design of AWA based on the following design criteria:
-
Alternate means of reporting issues, in addition to key commands, are needed
-
Users need to be able to review the issues that they reported as they are auditing
-
The tutorial has to clearly specify AWA's capabilities
A screenshot from a user test session of our screenreader-accessible prototype
Design Concept
We refined the design of AWA, based on the feedback from our user tests. To demonstrate the final design of AWA to our client, we created a high-fidelity interactive prototype. It is difficult to simulate screen reader interactions using existing design tools, so we also created a video demo to show how screenreaders would interact with AWA.
Demo Video
Click here to see the interactive prototype.
Below are descriptions of AWA's key features.
Reporting an Issue
AWA allows users to report accessibility and usability issues they encounter while browsing a website, by pressing a keyboard command. When the keyboard command is pressed, the user can report an issue about the screen element that is currently targeted by the screen reader.
Alternatively, the user can right-click the element with their mouse or screen reader and select the "Report Element" option in the right-click dropdown menu.
The user can type a keyboard command to report an accessibility or usability issue
Alternatively, the user can right-click the element and select the "Report Element" option to report the issue
Sending a Report
AWA’s Report Review and Submission interface can be activated through a key command or through an option in the user's right-click menu. This interface allows the user to browse and edit their list of reported errors. Once the user has reviewed the report, they can export it to the website owner via email. The report, which Accessible Website Auditor compiles automatically, contains the user's written feedback and an annotated copy of the website's HTML with the user's reported issues next to the corresponding HTML elements.
Users can review their report as they are auditing a website, and
then send the report to the website owner once they are done
Tutorial
Users learn the simple workflow of AWA through a brief step-by-step tutorial. The tutorial, which is a webpage itself, walks users through the task of reporting an obvious accessibility error on the page. AWA also provides a quick link during the auditing process that allows users to review the tutorial for reference.
The tutorial walks users through the process of reporting an issue.
Next Steps
AWA's design currently exists as a set of design artifacts and will need to be developed into a functional version with WCAG-compliant code. Our high fidelity prototype, design description, demo video, and presentation video were handed off to DDP so that they could develop the functional version of AWA. Once a functional version of AWA has been created, it can be integrated into DDP’s Task Force program to help blind and low-vision individuals to learn how to perform accessibility audits of clients' websites.