Every day Stark community members from all over the world come together to ask questions, discuss answers, give feedback, and share resources. With this new series, we’re excited to share some of the most helpful wisdom coming out of our growing community in the hopes that it will help inspire your own work.

AO: How do you present accessibility-related work you have completed?

CM: The worst possible answer: It depends.

I just recently finished a light accessibility assessment for a client, and I did a few things. We use BeInclusive App as our tool for logging issues, as it’s explicitly designed for accessibility work and makes the reviews go faster vs. using something like Jira (which we do). The other nice thing about BeInclusive is that it automatically generates a report for us, so that cuts down SO MUCH MANUAL TIME.

Generally speaking, I assume that my audience has little to no exposure to accessibility. Not for malicious reasons, but to make sure I clearly articulate the findings. I don’t want someone to not understand what I’m presenting, so I take care to establish some baseline knowledge before digging into the findings.

I have found that articulating the impact, while showing AND telling what that means for people is what resonates the most in helping teams understand what these issues mean for actual users.

People can de-prioritize a list of issues all day, but when I tell someone how a person will be prevented from using a feature, that typically has more impact. when I can, I also try to do some live demos in addition to the pre-recorded demos.

EB: Here is a zesty answer: I don’t. In my current role, it is an output that is unspoken of the same way I don’t talk about if I used an 8pt or 10pt scale.

If you want to talk about craft, I’ll chat your ear off! otherwise, it’s just something I do. I’m hoping to change that, career-wise, but that’s a different story for a different day.

CM: If it’s design work, I take care to do as much as I can to bake it into the work and call it out, but make it seem like business as usual. I approach accessibility as a facet of documentation in the design system, called out just like any other code or design decision.

If someone asks me about a design decision, I’ll dig a little deeper into the why and articulate the accessibility considerations and impact. I try to make it “accessible is how it is”. Sometimes clients can try to cut things that make a design accessible, so I do have to toe the line of not calling it out too much and making it seem like it’s something that a client can latch onto and cut.

All of that is to say, unless it’s explicitly accessibility work, I include it as part of the overall picture and call it out when appropriate.

Key Takeaways:

1. You can use accessibility tools such as BeInclusive App to log issues and generate reports faster.
2. Assuming your audience has little to no exposure of accessibility can help you clearly articulate your findings.
3. Try to always dig a little deeper into the why and articulate the impact of the work, while showing and telling what that means for people.
4. Incorporate some live or pre-recorded demos into your presentation if possible.
5. Approach accessibility as a facet of documentation in the design system, called out just like any other code or design decision.

---

Want to join a community of other designers, developers, and product managers to share, learn, and talk shop around all things accessibility? Join our Slack community, and follow us on Twitter and Instagram.