I cannot pinpoint the source of this misconception, it could have been a vendor, or long-lost blog post, or one of the many webinars I attended in my early days as a program lead. Regardless of the source, I operated under the wild misconception that all I needed to do was train my teams to do accessibility. Developers, QAs, designers, all they needed was training!
[…]This model does not work. Especially for an organization with multiple products, multiple platforms, and multiple development teams.
Accessibility is so much more complicated than can be summarised in a mere training. It requires experts, capable programmers, users who actually require said accessbility, and so much more. It’s also an ongoing process – it’s not a static “train once, use everywhere” kind of deal.
I’m not sure that having a cohort of actual users with specific needs is required, per se, but there’s definitely a level of understanding required that goes beyond “they’re blind” which is where most accessibility work is focussed.
I know this isn’t REALLY related to the topic but I was so exciting when I learned about this recently…
In the video game “Grounded”, one of the common enemies is very large (larger than the player character), very real looking spiders. The developers understood that many people have a very big problem with spiders, so in the settings under “Accessibility” they put a “Spider Slider” where the player can decrease the realism of the spider enemies. They can go from a realistic spider all they way down to looking like a cartoon circle with no legs and two dots for eyes, all while having no affect on gameplay. I thought that was really clever. 🙂