Building out accessibility research practices

You can also watch my presentation on this topic from an Experts with Fable webinar held in August 2022.

Background and approach

In 2020, when I started collaborating more closely with the Director of Accessibility at EVERFI, I realized we did not have a way to engage with people with disabilities in a meaningful way as a part of our product development process. This case study highlights how I led our team to adopt new methods to support a more inclusive user research and design practice. 

Here’s a quick overview of my personal approach as a designer that will help ground this case study:

  1. We are all designers. You might think you aren’t a designer if it’s not a part of your job title, but I think we are all designing the world around us in some way, all the time. Simply defined, design is the creation of a plan to build an object, system, or human interaction. So, if you are an individual or a part of a team that is creating and building anything, you can think of yourself as a designer!

  2. Technology is not neutral. Since technology is built by people, it reflects back human action and social context, it often tends to reflect and reinforce existing power and status structures, which can be exclusionary.

  3. We have agency (and responsibility) to drive intentional and inclusive (re)design in our work. Some key questions to reflect upon, which are taken directly from a guide written by Project Inkblot:

  • What perspectives or lived experiences might be missing from your team/collaborators/community/participants?

  • Who might you be excluding?

  • How will you engage the people you want to reach within your design process, equitably?

 

Gaps in our accessibility practice

After my own experience of reflecting upon these questions, I identified some clear gaps in our current process that was preventing us from understanding the holistic user experience.

Quality assurance (QA) testing

  • Relying only on QA testing catches the “what” but not the “why”

  • Passing technical a11y requirements, but to what end?

  • Lack of knowledge about how people use different types of assistive technology (AT)

Ad-hoc participant recruitment

  • Ad-hoc recruitment with customers and end-users who reported one-off accessibility issues

  • Reactive approach

  • Does not support a repeatable and scalable practice

 

Opportunities for redesign

I identified areas of opportunity to move towards and a more human-centered and inclusive research and design approach.

User experience (UX) testing

  • Understanding of the actual user experience, not just technical adherence 

  • Can test different layouts and combinations of components or interactions

  • Can measure time on tasks, ease of use, learnability, errors, and other UX metrics

Reliable user engagements and collaboration

  • Adjusting recruitment approach to ensure representation and inclusion of people with disabilities who use a variety of different assistive technology (AT) in their everyday lives

  • Reliable and repeatable process that works within rapid product development cycles

I discovered Fable Engage, a platform that would help us move towards this new approach. I knew I’d have to get buy-in from product leadership to partner with Fable, so I got to work in developing the vision and structure for how exactly we could integrate it into our workflow.

 

Creating a roadmap

I led the development of a six month roadmap to plan how we would work with Fable Engage to evaluate the accessibility of our different products and features. We identified and prioritized high risk and high value work, and asked ourselves questions such as:

  • What are the building blocks of our products?

  • How are known accessibility issues negatively impacting our team/organization (cost, time, customer complaints, etc.)?

 

Snapshot of key items

  • Design system components audit: prioritized based on factors such as newly refactored, known problems, and level of usage

  • Templates: commonly used page layouts and learning experience patterns

  • Navigation: Course menus and other core navigational items

  • Platforms: Entry points for accessing content 

  • JIRA backlog: Address backlog of any WCAG Level A issues

  • Corporate website: Public facing web presence

 

Establishing repeatable process

After developing a our broader roadmap, I started to tackle the tactical day-to-day things that would help support our team in integrating a new tool and approach. I adjusted or created key process artifacts.

  • Project planning templates: Worked with PJMs to establish how this new layer would fit into our sprint cycles and project plans.

  • JIRA ticket templates: Helps team members understand steps involved in the work, provides visibility to accessibility work (Kanban boards, backlogs), and builds shared team member understanding.

  • Shared planning calendar: Supports month to month tracking and prioritization of what is on our broader roadmap.

  • Development environment: Ensured that we had a place where our team could rapidly build functional prototypes that could be tested with most assistive technologies.

 

Facilitating feedback channels

One of the final pieces I set up was communication planning

  • Share findings: Facilitation of monthly research readouts with stakeholders to share summarized observations and insights from sessions, as well as clips and quotes for our users.

  • Form actionable next steps: Before leaving research readouts, we always assign action items and owners that are tied to each key insight.

  • Maintain communication: Managing a chat channel among stakeholders for questions or updates in between regular meetings.

 

Outcomes

By developing a roadmap and success plan, as well as digging into a ton of tactical process pre-work enabled me to demonstrate to my product leadership team not only how we would leverage Fable Engage as a tool, but also illustrate the surrounding ecosystem that would support our accessibility work over time. We moved forward with our plans, and the impacts on our team have been great.

  1. Democratization and shared ownership

    More team members are learning about accessibility and different types of assistive technologies, which helps develop new mindsets. Learning about AT provides an additional UX lens many designers did not previously have — designers are thinking about accessibility from the start at the ideation stage, and our team can recognize designs and layouts that are not accessible and iterate designs before we’re even building.

  2. Shifting accessibility left

    We now have a proactive approach to accessibility which places us much further left in the product development process. Engaging with accessibility research and testing earlier results in less a11y QA, so our team spends less time in a reactive state remediating issues in released products.

  3. Holistic accessibility approach

    Arguably the biggest impact: accessibility is now woven throughout our product development process, which supports a more empathetic and inclusive research and design culture in our organization.