I was in a meeting the other day and I caught myself saying how we need to ensure "WCAG 2.2 AA compliance by implementing ARIA labels and semantic HTML."
I saw people's eyes glaze over.
It's always better to use clear, non-technical language when discussing web accessibility. Especially in a room with non-technical stakeholders.
Not everyone speaks "tech." Nor should they. Because not everyone speaks business either.
Designers, executives and even developers need to understand accessibility in terms that speak to them.
So in that meeting, after I said all that gobbledygook, I added that "what I want to say is that we need to add descriptions to buttons so screen readers can explain them and we need to use what already exists in the browser to structure the website so it’s easier for assistive tools to navigate."
You might say it's not the same thing. Or that developers need to know what semantic HTML means. I disagree. I'm a self-taught developer and didn't know what semantic HTML meant, even if I was using it. There's also the language barrier to consider and "semantic" is not an easy word.
Analogies can also help. I've heard others compare web accessibility to building a ramp alongside stairs. That it’s about creating multiple ways for everyone to access the same place. Or, explaining colour contrast requirements by saying, "Imagine trying to read light grey text on a white background in sunlight. It’s frustrating, right? That’s why we need high-contrast designs."
What I found most helpful are before-and-after examples or simple diagrams.
The goal is to make accessibility relatable and actionable, not overwhelming.
The best way to do this is by speaking the language of the people in the room. Their common language. If you're not sure what that is, use plain language. This way you make sure everyone, regardless of their technical expertise, can follow along and understands the importance of accessibility.