I received a request for some advice from a newly named Accessibility Lead for a government agency. He said, "I am being asked to provide accessibility guidance on products / software I have never used before; and, in my opinion, this is a rather dangerous venture." I knew exactly what he meant. You feel like you are being asked to wave the magic accessibility wand over any old tech that happens to come along, while knowing that there is no magic.
This is what I told him. If you are in the same position, I hope this helps you, too.
There is no way anybody can be an expert in every aspect of how to implement something accessibly in every technology. I’m sure not! So here are some survival tips.
- Never claim to “know it all” or let others burden you with that.
- Admitting that you don’t know everything gives you a lot more credibility.
- It also leaves room to work cooperatively – let the devs, authors, etc. (“creators”) in on the discovery process and they will be more committed and learn more. This is much preferable to a “dump it over the wall to the accessibility guy” approach, where it makes it look like you are the problem when issues are found.
- The general principals are the same: Perceivable, Operable, Understandable, and Robust. And the guidelines under them in WCAG2 track nicely to just about any technology area. The actual implementation and authoring techniques are where things vary.
- Always look to the technology provider (software vendor, for instance) for implementation guidance. Look for their white papers or developer guides that address accessible implementation/configuration. If it’s not on their website, the creators need to contact the provider to get it (or to let them know that it’s important.)
- Your creators should have found and been using these before they come to you. If they didn’t, send them back to find it, compare the guidance with what they have done, and make needed changes before they return.
- There may not be tools like we have for web-based technologies (accessibility checkers, code inspection tools) so you may end up having to do testing just with AT: screen readers, magnifiers, and speech recognition. It takes longer and you’re more likely (as a human) to miss things.
- QA discipline is your friend here. Identify a matrix of AT, platforms, and browsers (when applicable) that you need to test on to find source errors (versus AT bugs) and write formal test scripts.
- Involve the creators in testing so they can learn how to do at least some of it themselves, and so they understand the actual problem.
- Get Actual Users to do testing, too, as a reality check and to prioritize the severity of any issues found.