If you answer it twice, make it an article

Most accessibility teams are small and we need to make the most of our available time. Answering questions from designers, developers, PMs, and customer success can be the best use of our time. But it can also be a time waste if we’re constantly answering the same questions.

At Intuit, I’ve had the policy of taking an answer I’ve written, or discussed via Slack, and publishing it as an article. This makes it easier for you to answer then next version of the question. Better yet, by publishing it on our intranet, people have access to the information at their finger tips.

These answers represent the long tail of accessibility. Long tail accessibility questions need a long memory. The answers to niche problems are rarely urgent until suddenly, they are. It may be a complex use case of an ARIA attribute, accommodations for a particular disability, assistive technology use for a customer success agent, and more.

Using AI to summarize slack conversations

Your organization may have an “ask-accessibility” Slack/Teams channel. These are great, as people can get quick answers to their questions. It’s especially useful with our large Accessibility Champion community, as questions are typically answered within 20 minutes.

Some questions are easy to answer, others trigger a long thread exploring the complexity of accessible solutions. We use an AI Slack bot to summarize the discussion, which brings some finality to the conversation. We also use this to create a rough draft of an article and publish it on our Accessibility Hub. A recent example focused on best practices for designing form labels and the article brings more context than our accessibility standards and guidelines document.

These summaries turn ad hoc support into lasting knowledge—and they reduce the time you’ll spend answering the same question again next week.

Test examples FTW

Sometimes, words aren’t enough. That’s where test pages come in.

Let’s say someone’s confused about how to get a screen reader to announce the number of options in a segmented button group. Instead of explaining it every time, you can build a quick demo and publish it: Many of the questions relate to production code, with javascript and CSS. We can answer these questions, but they won’t necessarily be relevant for the next person’s application. It’s important to create stripped down test pages to show how the code is meant to work. I’ve been using an Accessibility Tests directory on my personal server to simplify the sharing.

Where to document?

You’ve got the content, now where do you put it? Remember that many of our tools are not discoverable. You’re going to have limited reach when you publish in Figma, Slack, Google Drive, and potentially Wiki pages. We use the intranet platform for our company, this makes everything we publish available within their search engine. Publish the article and then share the link in your favorite collaborative tool.

Make it happen

Documentation isn’t overhead. It’s a strategy. It’s a way to scale yourself, support your team, and reduce burnout while improving consistency. So the next time you explain something twice—pause. Write it down. Link it. Share it. Because every documented answer is one more thread in a stronger, smarter accessibility community.