Slack is a collaboration tool designed for teams to be able to communicate with each other in real time in order to get stuff done. It integrates really nicely with other project management & productivity apps which makes it one of those really neat programs that can make work processes a lot more efficient for companies. One of the cool things about this app is that it creates a really awesome place for building communities among like-minded professionals, even if they aren’t in the same company.

Using Slack for Accessibility

Earlier this year, I learned that Angular JS programmer guru Marcy Sutton had started using Slack to build a community for people making accessible apps, websites, etcetera called A11y Slackers. You can read more about Marcy’s discussion group over at her Accessibility Wins blog. Apparently it was getting way too big for it’s britches so Steve Faulkner set up another site through Gitter, a really cool way to collaborate on Github stuff. These are awesome places to go to in order to figure out how to implement accessibility into a design or program.

A Need for Policy Discussion

This got me thinking about another area of accessibility that doesn’t seem to get a lot of focus, but is equally (if not more so) important as implementing it at a technical level: Accessibility Policy.

Sure, there’s lots of places to go to in order to learn about specific interpretations of a specification, but even everything is so technology-specific. For example, if you wanted to find out about what the specifications for PDF were, you could reach out to the PDF Association, or even check out the various community groups on LinkedIn devoted to each individual specification related to your needs. But if you also wanted to understand what some WCAG recommendation was referring to, you’d have to go to a separate place for that. You might try WebAIM, or even sign up for WebAIM’s amaze balls mailing list, but pretty soon no matter what you’re looking for you’re bound to encounter the second issue surrounding policy.

Accessibility Policy is written intentionally vague in order to be applied to the broadest context. It’s entirely left to interpretation of administrators, legal professionals, executive management, and subject matter experts. In other words, most of the implementations out there are based on someone’s opinions. It can be really confusing for people seeking help to get conflicting opinions from professionals who are intimately involved in each specification.

My Suggested Approach

Therefore, I thought it would be super cool to have a place people who have an excessive interest in minor details of accessibility policy to go and shoot the proverbial shit. I’m not thinking of replacing any of these other resources, but rather create the concept of a technology-agnostic water cooler, where accessibility policy geeks can share ideas and perhaps go so far as figuring out common best practices when sharing interpretations of things. This would complement those other awesome places created by Steve and Marcy, because accessibility noobs and veterans who wanted some detailed help understanding some esoteric specification and how it might apply to their required legislation.

In order to get around the fact that Slack is built for teams, I needed to get Marcy Sutton’s suggestion of  to work right. Unfortunately, I’m absolutely useless when it comes to programming, so I reached out to  to lend me a hand. Since this man dreams in ones and zeros, he did it while we were chatting about shoes (long story).

So come on out and join the conversation at Accessibility Policy Social Hour. You’ll need an invite, so head on over to a special page set up by my programming genius Sina Bahram over at Prime Access Consulting. Since I’m absolutely useless when it comes to programming, I reached out to Sina to lend me a hand to use Ryan Florence’s Slackin app.

Join Accessibility Policy Social Hour!