Last summer I taught an accessibility tutorial at OSCON with Denise Paolucci. After the tutorial (which has training materials on GitHub), I was speaking with attendees about what else they wanted from accessibility training, and I had an epiphany. An OSCON epiphany.
To maintain accessibility, we need more people choosing to become the accessibility owner for a product. So I challenge you, the accessibility advocate or coder looking for a home, to become the accessibility advocate for your product at !DayJob, or to pick an open source project you use and become its accessibility hero. If you have an open source tool or platform you use all the time, I bet you dollars to boston creme donuts they either don’t have a contributor dedicated to accessibility, or their existing accessibility people want resources. And they likely would love an accessibility manager — especially if you volunteer to write the patches!
What you can contribute depends, obviously, on your skill set. But you don’t need to be a developer or a designer to be the Accessibility Hero at your organization.
You’re a coder, and you care about accessibility, but you don’t know much about it
Now is a great time to start! Start reading on the WebAIM mailing list and website until you have a handle on the interaction between theory and practice. Once you’re comfortable, work with the project leads to focus on what you and they agree are some nice, high-value low hanging fruit. You don’t have to start with the tougher stuff: visualizations, mapping, animated games. Pick something straightforward to begin with (adding alt text to the product logo?), and build up from there.
You’re an accessibility advocate, but don’t know much about coding
You will be a huge asset to an project by becoming the accessibility wrangler. Create and garden the accessibility section of the bug tracker. Find devs to fix those bugs, and put them in touch with the best documentation or with potential testers. Write documentation explaining why and how. Create project best practices. Learn how to test for accessibility yourself (it’s harder to test for than it is to code for), and become a QA tester. Seek out users with disabilities and convince them to become programmers, QA testers, and active bug reporters. I can’t overstate the importance of having someone like that on your project team. 
- Pick a project you care about! One you use all the time — an IRC client, an editor, a social media tool, a learning management systems, an IDE — will make each of your fixes more rewarding for you. I promise you there is not a single software product out there (including the platform where I co-lead the Accessibility Team, Dreamwidth) with perfect accessibility.
- Don’t just appear out of nowhere and start pestering existing contributors about accessibility. You want buy-in from the existing team, so approach the contributors in their forum of choice and tell them you’re ready to start committing accessibility patches or testing existing code, and you want to know if they have anywhere in particular they’d like you to begin. If this is for a project at !DayJob, speak with project managers and team leads and make sure you have their support.
- Seek out users with disabilities who have expressed the kind of interest that makes it seem possible they might be willing to be testers, coders, or bug reporters. They might already be there and organized, in which case, hooray! Your job is that much easier.
- Make a forum where developers, designers, and users can talk exclusively about accessibility issues. The type of forum doesn’t matter. IRC, mailing list, twitter, or a blogging platform are all fine, as long as your users with disabilities can access the platform.
- If users with disabilities report something that sounds like it’s not a bug to you, listen anyway. They might be mistaken, but trust that you don’t have their experience. Using computers with adaptive tech can be exhausting, and the tiniest roadblocks become major.
- Remember to code for keypress, keyup, keydown, and focus events when you are looking at hover, mouseclick, etc events.
- If you create fake links or other HTML elements using spans or divs plus JS, make them accessible by adding a tabindex attribute, a role attribute, and coding for keyboard access as in point the first. But default to native HTML wherever possible.
 Try WebAIM and their great mailing list, as a good starting point. If you spend some time on the #accessibility and #a11y hashtags on twitter you’ll see some great conversations, as well. Learn what WAI-ARIA can and can’t do for you. Start there and branch out to the resources most useful to you. Understanding the Web Content Accessibility Guidelines (WCAG) and other standards is important for experts, but if you begin by reading standards, you’ll get overwhelmed, bogged down in details, and be distracted from the balance between following standards and creating usable, accessible sites.[Back]
 Well, I can overstate it. Having an accessibility wrangler won’t help you defeat giant lizards attacking the Pacific Coast or defend your Death Star from those pesky rebels. But it will make coding for accessibility a pleasure and delight. [Back]