Accessibility Audits And Remediation

Acronyms

PWD - People With Disabilities 

WCAG 2.1 - Web Content Accessibility Guidelines 2.1

 

Impact 

• Made 20+ websites, and 500+ pages of documents accessible to PWD. 

• Mentored peers and encouraged a holistic understanding of accessibility. 

• Trained product teams in best practices for a more sustained approach to accessibility. 

​

Overview of Approach

​

Project Planning 

In this phase, the focus is on becoming familiar with the contents of the web pages and documents and answering the following questions:

• What is the scope of the project?

• What is the project timeline? 

• Who is in the team and how are we distributing efforts?

• What do we need to get started? This could include login credentials, IP whitelisting, use cases, and dummy data for the use cases

• Do we need a subject matter expert to help us with the use cases? 

​

Accessibility Evaluation 

Step 1: Test the website using automated accessibility testing tools like Lighthouse/WAVE to flag problem areas.

Step 2: Evaluate the website manually using keyboard-only navigation tests, color contrast checks, and assistive technologies like:

• Screen readers (JAWS and VoiceOver) 

• Speech recognition software (Dragon Naturally Speaking)

• Screen magnification software (ZoomText)

Step 3: Test the web pages/documents with PWD and gather feedback.

Step 4: For every issue identified, describe the experiences of PWD, cite the appropriate WCAG 2.1 standards, and include screenshots.

Step 5: Provide multiple recommendations for each issue logged, so that developers can compare options and choose from multiple solutions.

Step 6: Assign a severity rating to each issue so that developers can prioritize the remediation work. 

• ​​High Severity: Likely to prevent PWD from completing a critical task.

• Medium Severity: Likely to prevent PWD from completing a non-critical task OR likely to cause confusion or frustration and have a significantly negative impact on, but not prevent, PWD from completing a critical task.

• Low Severity: Potential to cause minor confusion or frustration and negatively affect (e.g., slow down), but not prevent, PWD from completing a task.

​

Report 

Details of the project and a summary of all the positive findings and issues are combined in a PDF document as one of the deliverables.

 

Findings Presentation and Collaboration

• Give stakeholders about a week or as much time as they need to go through the spreadsheet and the report before we present our findings. 

• Ensure that the developers feel ready to start the remediation.

  • Present our findings

  • Answer questions

  • Discuss severity ratings and prioritize remediation of issues identified

  • Discuss alternative solutions and their impact on PWD

​

Training Product Teams

• List all the positive findings and encourage stakeholders to continue these practices

• List issues and their impact on PWD 

• Share best practices in web accessibility with demonstrations

• Emphasize “no-excuses” practices that can be easily implemented 

• Suggest methods to integrate more complex practices into the product development lifecycle  

• Answer questions and invite stakeholders to continue these conversations