Cheat Codes for Framing Accessibility Discussions
Recently I've been working with a colleague giving a big talking head presentation on the intersection of design and development pertaining to accessibility within our company. She's giving a talk to a room full of lay folks with no deep understanding of the topic and was interested in ways to frame the conversation to maximize impact. This is something I've spent an inordinate amount of time thinking about actually. My previous role was as an accessibility advocate on a component library team and centering discussions about feature work, developer experience and user experience around disabled users was common, but I came to realize that just referring to this large unknowable monolith "USERS WITH A DISABILITY" wasn't quite getting the job done--or at least it wasn't resulting in the outcomes and enthusiasm I was looking for (generating enthusiasm is a big part of an advocacy role!).
The conversations especially had a hard time gaining productive traction with non-technical users. Visual designers with print backgrounds without explicit training understandably had a difficult time conceptualizing the extent of the damage they were causing with seemingly innocuous and common patterns in their screens. There is a smart tendency when teaching a big technical topic to a non-technical user to make the ideas as small as possible. But with accessibility--making unspecific stern proclaimations, hand waving away details and briefly hinting at a vast ocean of difficulty beneath the calm surface waters actually hurts more than it helps. It minimizes the blast radius of seemingly "small UI tweaks". It makes boxing up a set of users and setting their use cases and experiences aside for later in a "fast follow" ticket seemingly not too outrageous!
Something I encourage advocates to do is to elaborate on the details. Describe the particular user's experience and walk people through each individual pain point created and demonstrate the friction and barriers they now must overcome (if they can at all). Citing a random string of numbers from the WCAG isn't enough because alone those things have no value to someone who doesn't know what they are or represent!
When a visual designer is plotting out an interaction they're ideally thinking about the user's path through it. This click leads to that dialogue which then prompts this interaction etc. They're not thinking about standards and practices citations from the Apple Human Interface Guidelines. Those guidelines may inform the work their doing, but in practice lots of this is experience resulting in muscle memory. 'Requiring this action from the user necessitates that element or component'. So always always always center these conversations on a particular user. Illustrate how a parent with an arm full of groceries, but missing some critical item might be using a non dominant hand to open a drawer component in your UI and make a quick order for pickup. This user is experiencing a temporary disability--a very relatable one--and would probably greatly appreciate not having to jump through hoops to complete their task.
That's not to say that relatability should be the only factor of course. The important thing here is that the folks in the room with you are able to understand the user's experience enough to motivate them to solution and maybe most importantly keep that user persona in mind next time they ideating, wireframing or prototyping. Create advocates!