Accessibility

About the Project

With over two million students using the Top Hat platform, it was imperative for us to ensure an accessible experience for all of our users. I wanted to be more inclusive with my designs by better understanding our users' different needs.

Our goal with this project was to make the student experience accessible according to the WCAG 2.1 standard by December 2020. My work involved both product design and process changes.

My Role

User Research, Interaction, Visual Design, Prototyping & Testing

Date

Sept 2019 - March 2020

Understanding the Problem

I began by educating myself about accessibility and compiled everything I was learning into a reference for the design team.

From my research and conversations with the team, we decided to focus our efforts on 2 streams of work:

1. Address existing accessibility issues in the product

2. Prevent new accessibility issues from being added to the product

With 60 developers working on new features at any given time, we knew that without changes to our processes, we would continue to add more accessibility debt to the product.
This work couldn’t be a one time solution, but rather an ongoing part of our process.

Gathering Insights Through Audits

Address Existing Accessibility Issues - Audit Of Product

We determined the sequence of our work by identifying the most used parts of the student platform. From our research we found the most used flows were related to sign up/log in and Top Hat questions.
‍
Our audits consisted of 2 phases:
‍
1. Violation - compliance with WCAG (colour contrast, keyboard interaction, use of proper semantics etc.)
‍
2. Usability - we wanted to ensure a great experience for all of our users regardless of the assistive technology they might be using

Example - Student Signup

Problems

1. Current step is not announced via screen reader (e.g. “This is step 2 of 5 of account registration”).

2. When tabbing through fields, error messages are not triggered.

3. Error message is not announced via screen reader.

4. No focus ring when tabbing through input fields.

5. Buttons are disabled by default so users don’t know they’ve reached the end of the form.

6. Input field line does not meet contrast requirements.

Example - Multiple Choice Question

PROBLEMS

1. Question header is not announced via screen reader. It’s not navigable via tabbing and using screen reader.

2. Question text should not be included in tab order.

3. Question body semantic is incorrect and should be set as a radio input.

4. “Submit” button is disabled by default and user may not know when they’ve reached end of form.

5. On selection, the question options do not meet contrast requirements.

Prevent New Accessibility Issues - Internal Process Audit

We spoke with designers, developers and individuals working in QA to better understand their processes and pain points.

Insights From Audits

Address Existing Accessibility Issues

From our audits of the student flows, we found 2 types of issues:
1. WCAG basic violations that required simple changes (e.g. color contrast, semantics, proper labels etc.)
2. Issues that required changes to components

Prevent New Accessibility Issues

Top Hat had been operating for years without considering accessibility as part of the product development process. From time to time we would have short accessibility initiatives which were not solving the core issues. Accessibility should not be an add on. It should be considered from initial designs, during development and during QA.

From our conversations, we realized the common thread was a lack of knowledge about accessibility practices. We knew this was where we needed to begin and set the following plan in place:

Training with a focus on empathy building
Implement processes and best practices for Design, Development & QA
Training and best practices documentation for all employees

Solution - Product Changes

Student Sign up

Solutions

1. Added checkmark to completed step to improve clarity of progress for all users.

2. Added live-region to ensure current step of process was announced via screen reader.

3. Added logic for helper text and error messages to be associated with input field and to be announced via screen reader.

4. Added outlines and focus states
for input fields and built them
as reusable components to prevent regression.

5. Made buttons active by default and added error messaging on click to inform users what they still needed to complete as part of the form.

Questions

I mapped out all states for our 8 question types and worked closely with the developers during implementation. The question pieces were created as reusable components to ensure consistency across the product and prevent regressions.

Solution - Accessibility Program

We instituted an accessibility program at Top Hat made up of the following measures:

Training for Product & Engineering Department

Weekly Accessibility Office Hours

Feedback During Design Critique

QA & Audit For Implemented Features

Documentation For Designers & Developers

Testing and Feedback

We conducted usability testing with users with disabilities after each implementation. We used that feedback to address remaining issues and improve the usability of the product. By involving users with disabilities in the process we ensured that the work we were doing would allow them to use our product and increase awareness among the designers and developers.

Results

We reached our goal to make the student experience accessible according to the WCAG 2.1 standard by December 2020.

We had an impact on Top Hat's culture and changed the Product & Engineering department's view on accessible product development. In addition to the measures put in place, we created an accessibility champion program in which a developer on each engineering team would be an accessibility advocate.