By skyforbes 
Getting follow-on work as a consultant is oftentimes quite exciting, and working on Easy Access to System Information (EASi) within the Center for Medicare and Medicaid (CMS) was no different. The Truss design team wrapped up building a system to track governance projects, and we were ready to kick off Discovery and Framing for a service with the 508 Accessibility team.
For those unfamiliar with Discovery and Framing, it’s a phase at the start of a project where we conduct a large exploration into a perceived problem space by speaking to end users and stakeholders to identify and understand their challenges. At the end of Discovery and Framing, teams should have a good idea of what problem they’re solving, who they’re solving it for, and what a solution could look like.
The 508 Accessibility team at CMS is a group of a11y experts who ensure that CMS applications and systems are accessible. This includes conducting tests, offering guidance and advocating for accessibility.
The design team, Sai Mohan and I, were excited to work with the 508 Accessibility team and help CMS manage their 508 testing backlog: our project focused on the challenges the team faces around managing their work. At the start of Kick Off, we met the 508 Accessibility team and learned several folks use screen readers regularly in their day-to-day because they have low or limited vision.
We asked ourselves a question:
How might we design an accessible Discovery and Framing for users with low or limited vision?
As any start to a Discovery, we kicked off with interviews — easy. We spun up a Zoom and had lengthy one-on-one conversations. When it came to group discussions, we learned we had to be mindful of Zoom chat. Why? End users with low or limited vision often use screen readers, which automatically parrot all chatter from Zoom. We learned about our misstep after a quick check-in with one end user, who encouraged us to deviate from our habit of using Zoom chat during collaborative sessions with their team.
After synthesizing our interviews, we built a Service Blueprint in Miro to understand the relationship between an end user submitting their application for 508 testing and the 508 Accessibility team testing said application. Once we finished, we wanted to validate the artifact with the team but it dawned on us that Miro is inaccessible. We took a step back, and decided to reconfigure the Service Blueprint in MS Word, a tool the 508 Accessibility team uses regularly and is familiar with. After having another check-in with an end user, we learned that as long as we used headings and bullets to break down the Service Blueprint, those who use a screen reader could easily parse through it.
After translating the blueprint into a Doc format, we sent it over a few days in advance so that everyone on the call would be prepared to discuss what parts of the journey needed adapting. It also meant everyone could follow along in the document during the meeting itself. It was well received and all of our users were able to effectively collaborate with us on getting the service blueprint right.
We unpacked what we needed from concepting, and decided receiving feedback on a few high level storylines would help us better understand what direction to take our product. Contrary to some storyboards, the images we used were simple icons we found in the Miro icon finder, as our goal with the storyboard was to focus on the storyline itself. For our users with low or limited vision, we read them the story and gauged their reaction to each frame. The results of this concept test helped us validate two potential product directions.
With an overall concept in mind, the design team and an engineer paired to bring the concept to life. We skipped Figma altogether and built an interactive prototype from pen and paper (heck yeah analog!) to code. Thankfully, the US Web Design System (USWDS) makes it a lot easier to build accessibly from the start — most key components are already accessible. Within a week, we were able to spin up a prototype and test it with end users, even those who use a screen reader.
You can check it out if you’d like!
So now you know our story. You might be excited to make your workshops or collaborative sessions more accessible on your team.
Here are a few helpful tips:
- Consider if your users and stakeholders have access needs. Ask as early as you can, even ahead of the kick off meeting. If they do, be cognizant of those needs as you find ways to bring them along on your product or service journey.
- Ask for feedback before and after. It’s a good idea to send your collaboration material in advance so that you can get feedback and make sure that the document is accessible. At the end of a collaborative exercise, check in with the room and see how you can adapt your process to their needs.
- Allow for more time. You may be used to running these research sessions and workshops at a tight schedule. Consider allowing for more time to ensure everyone can participate fully and have the time to give their feedback.
- Use tools your end users are familiar with. Using remote workshopping tools is fun, but don’t make it overly complicated: Docs and Slides can go a long way, especially if your end users are unable or reluctant to use remote workshopping technology.
- And lastly, use your words. Accessible design hinges on effective content design. Invest time to really explain your diagrams, concepts, and use thoughtful content when actually building out prototypes. Death to lorem ipsum!
You have to make your product accessible so that everyone can use them. It’s even better if you make your process accessible so that everyone can participate.
I appreciate what Jack Garfinkel tweeted recently:
“Accessibility is finding out who you are excluding and fixing it. Exclusion is a behaviour, usually embedded into organisations and industries. Technical standards can help, but they are the smaller part.”
Consider your workshopping methods and see how to make those accessible, too. Here’s to a more accessible future!