If you're like me, you're probably on Slack and email for the better part of your day. It's an unfortunate, but a necessary part of our work days. You can't build a product without communication.
But let me ask you this.
How often do you see the same conversations about accessibility rehashed in an email thread? How often do you read answers to the same questions about forms and labels in a Slack channel?
Do you see detailed explanations of solutions, with complex problems broken down and people participating and giving thumbs up? You might think that's a good thing.
It's not.
Slack and email are ephemeral. You write it, they read it, you both delete it. Those carefully thought out solutions and meticulously written explanations are lost when the next email comes in or the next Slack @here mention shows up in the channel.
What this means is that current team members as well as new team members don't have a clear path to understanding the accumulated wisdom. They're left to piece together the information through scattered Slack messages and half-forgotten docs. Or, as it usually happens, they ask the questions yet again.
If you've seen this play out before and you're nodding your head, you might have a knowledge sharing problem.
Knowledge sharing isn't just about documentation. Teams that do well with accessibility focus on creating a culture where explaining is just as valued as doing. Where the most respected team members are those who not only solve a problem, but can also explain and document the entire thought process behind the solution.
These people do the "boring" work. They write documentation, they piece together walkthroughs, they write test cases and scenarios. They're the ones who welcome new team members and explain to them why accessibility is important and how they should approach it.
You can think of them as accessibility advocates if you want. And like accessibility advocacy, knowledge sharing as a metric is also hard to quantify. But the signs are there. Look at:
- Accessibility considerations are usually discussed during design
- Accessibility challenges get tackled proactively, not only when problems emerge
- Everyone on the team has a basic understanding of the WCAG
- New hires know where to look to get answers to accessibility questions
- Internal documentation includes accessibility guidelines
- Sprint retrospectives regularly include discussions about accessibility challenges
- Accessibility considerations are part of the definition of "done"
All these say that the team doesn't treat accessibility as a compliance checkbox. They spend time to tackle complex problems before they arise and document the solutions for everyone to see. Crucial insights about accessibility are not lost in scattered documentation and half-remembered conversations.