Teaching Inclusive Practices

Senior Accessibility Designer, 2U Inc, 2020 - 2024

What and Why

Nobody wants to be making accessible experiences. These things come up from lack of awareness (and, at times, lack of funding). Products are rendered inaccessible by chance, from gaps in understand from the entire product pipeline - product managers don’t account for a11y testing or research, designers don’t account for accessibility heuristics in their wireframes and final comps, devs don’t account for the code needs to ensure that a design is working with varied users and technologies.

To any designers reading this: I highly recommend picking up a copy of Mismatch: How Inclusion Shapes Design By Kat Holmes. It’s worth every cent, and was hugely impactful for me getting started in this space. Hell, get your company to buy a few copies for your team! It’ll pay off.

My Role

As a proponent of inclusive design practices (for both accessibility benefits and because it’s just a good process), I work with teams across tech organizations to educate around what accessibility is, how to think about inclusion in a productive and respectful way, and how to begin shifting products towards their accessible future.

I have designed and run accessibility introductions and inclusive design workshops for teams across the product pipeline. These include high level presentations to build in initial empathy, QA/dev focused sessions on understanding how Assistive Technology (AT) interprets the literal code of the web, lessons on how to use screen readers responsibly to confirm a page is working correctly, and how to incorporate accessibility heuristics and inclusive thinking into the UX design process (at both low and high fidelity).

I find that the learning dependency chart is as follows:

  1. Set expectations on language and mindset.
    • I start with the difference between the medical model - in which disability is an individual failure to be “fixed” by medical technology - and the social model - in which disability is a symptom of a society which fails to accommodate all people by operating with rigid expectations.
    • It’s the difference between “I need glasses to see the world around me” and “the world expects me to be able to read small text from far away, so I need glasses.”
    • It’s a subtle difference, but vitally as makers of things (websites, physical spaces, tools), we can’t control what tools or medical devices our users might be able to access, but we CAN influence the expectations we put on those users through our designs.
  2. Build an understanding of the breadth of accessibility technology.
    • Many in the tech scene think only about color deficiencies or fully non-visual users. But when you talk through the way screen magnification can make right-aligned controls harder to notice, or how tactile interfaces become more logical when inputs have decent padding between them, or how voice control can fail when too much text on a page is repeated. these conversations get people excited
    • This helps shift thinking from centering on the barriers of accessibility towards the opportunities we have to remove those barriers.
  3. Depending on the audience, I talk through the specifics of what these opportunities look like in different aspects of web design and development.
    • This might mean exploring browser tools with a group ofd developers, going through design heuristic worksheets with a UX team, or teaching a mixed audience how to explore pages using simple AT like VoiceOver
    • I even built a few tools here (based on exercises from Microsoft’s fantastic Inclusive Toolkit) for running sketching exercises and brainstorming sessions.
  4. And finally, ending on a note about the relative cheapness of the techniques we’ve covered - how teams can easily work these things into their current workflows and begin the process of learning more (and of course offering to do any sort of team/individual follow-up to cover edge cases).

Sample Presentations