Accessible Reports

In 2016, we were presented with a rare opportunity to completely rebuild our Similarity Reports. Fortunately, many of us worked on the earlier iteration of the product, so we were already familiar with the accessibility challenges we ran into into before.

We were determined to not repeat the same mistakes again.

THE CHALLENGE

Translating a Visual Experience

Working with a small, cross-discipline team including engineering and product, my role was to lead the redesign of our Similarity Reports with special focus on improving screen reader accessibility.

While we had some experience, there were still big questions to answer.

• How do you translate the visual experience into an audio experience?

• How do you make the app skimmable and easy to use while retaining all of the same information?

• How do you communicate dynamic changes in the app?

Early Brainstorming

We had a few ideas.

In earlier testing, we had observed the way screen reader users scan and navigate by lists of headings and regions. To communicate the visual layout and overall organization of the app, we would use headings and regions.

Next, to indicate the similarity matches within a document, we would include announcements inline with the original text.

Finally, we knew from experience that it would be key to get early feedback on our approach. We agreed to develop the smallest thing first and then test iteratively to refine.

Our accessibility consultant tested our static prototype using JAWS and NVDA. She gave us her usual tough love. While she confirmed we were on the right track, she also gave several suggestions about areas that could be improved.

Most notably, the similarity match information was descriptive but overly verbose. It was hard to listen to. In addition, we still didn’t have an answer for communicating dynamic changes in the app.

We revised the similarity match information, distilling it down to its most concise form.

To address dynamic interactions such as reading match details, we wanted to try aria-live for screen reader announcements.

After some tweaking, we were ready to test again. This time we were feeling more confident, so we deployed code to a dev environment for another round of screen reader testing.

We brought in our accessibility consultant again. She felt the similarity match information was easier to listen to and comprehend, however she felt disoriented by our use of aria-live for announcing match details. She explained that she was losing her sense of place within the structure, and she suggested revealing details through use of a toggle which could expose and hide additional information.

We had also implemented optimizations in the code, targeted specifically for screen readers. This was a controversial topic, as we had heard in the past that it’s a no-no to have separate versions for accessibility. We felt that simply respecting semantic structure resulted in fragmented screen reader announcements. Our consultant assured us that the optimizations were indeed an improvement.

SHOWTIME

Fine Tuning the App

At this point, we could feel the momentum in the air.

Over the following weeks, we hardened and refined the app. I sat next to our engineers and fine tuned the interactions with them. Our product manager closed his eyes as he listened to the screen reader announcements.

We felt ready.

We shipped our newly redesigned, accessible Similarity Reports which were met with enthusiasm and praise. It was a major victory. Our lead engineer, James Chao, presented our approach at Accessibility Camp Bay Area to share our findings with others and seek additional ideas.