I saw this question on one of the accessibility Slack channels I'm in. The person asked essentially why there's so much noise about accessibility when it's mainly an engineering effort.
Yes, implementing accessibility into a product is mainly an engineering effort. To a certain extent, so is testing for it. And perhaps so is making sure the designs are accessible. In all these areas of product development, you could say accessibility is an engineering effort. And you'd be right.
But take a step back now. Think of how it gets to the point of implementing accessibility. Think of why it's important and how you justify that to stakeholders.
Getting to the point where engineering can implement accessibility means you've already:
- Built awareness across teams
- Talked to leadership to understand both the moral and business implications of accessibility
- Created processes for accessibility testing
- Developed documentation and guidelines
- Trained team members on accessibility principles
- Engaged with users who have disabilities to understand their needs
In this broader context, the challenge of building an accessible product is more fundamental than an engineering effort.
This is because:
- Accessibility isn't a feature. I made the argument before that saying that accessibility is a feature also makes it seem like a discrete thing - a ticket in your backlog. Which it most definitely isn't.
- Accessibility isn't a technical problem, but it often times gets treated as such because its implementation is technical work. And maybe that's part of the problem.
- You can't outsource accessibility. If accessibility was an engineering effort, then you could outsource it. But you can't because it's not something you can fix with a once-and-done approach.
Accessibility is a process problem. And process problems require a different mindset than just file a ticket, fix it, test it and move on.