Often when people talk about accessibility, it appears to be this binary thing. Something either is or isn’t accessible. And that’s true, but it also isn’t.
Is it accessible?
I learned a lot about accessibility with this mindset. I’ve always thought of accessibility as a bridge. You can fix 99% of the bridge, but if one section is missing, people still can’t cross. A bridge with holes isn’t a finished bridge. There’s still work to do!
When you think of accessibility as a subject for business, it’s probably true! Let’s frame it as a user story: As a business I want to comply with WCAG 2.1 AA so I can avoid law suits.
And that’s the thing right? For a lot of people(/businesses) being accessible means being compliant with WCAG (Web Content Accessibility Guidelines) 2.1 AA. And yes, the question “Is this compliant?” can be answered with a hard yes or no.
And that’s where audits come in. An audit is when a specialist inspects your website (or app?). Often they follow the methodology WCAG-EM. Their findings go into a big report that states wether you’re accessible (complying with WCAG 2.1 AA) or not, and what you need to fix.
In a world where goals and targets are decided by those in management, compliance will often be the target. And in such a situation, an audit is very logical.
Is it valuable?
But do I believe that is what accessibility is about? It’s the frame I always had but no, accessibility is a spectrum. Even when you’re not fully accessible (WCAG 2.1 AA compliant), you can still be more accessible than other iterations/the competition.
You might still be excluding people, but that doesn’t mean there are no improvements. I’d still aim for WCAG-compliance. There’s a reason these guidelines end up in regulations all over the world: they’re pretty good. But it also a minimum. It’s the legal requirement in many situations that will avoid getting you sued. It’s not the ideal standard that will ensure everybody will have a great time interacting with your website.
But don’t forget to be proud when you’re making steps -towards- compliance. When your product is audited, and you’ve fixed previous issues... that’s improvement! You’re including -more- people than before. And that’s valuable! Be proud of what you’ve achieved and what you’ve learned!
Concluding
Audits are a great tool for compliance. They’re an external collection of findings. Taking the point of view of somebody building something, it might not be the most valuable feedback. A modern workflow start with components and does not revolve around the delivered pages. So you want your feedback to be shaped like that as well.
If you’re going for something that’s not just compliance, I would advice looking from the ground up. Make accessibility part of the requirements, incorporate it in your foundations (like design systems and component libraries), focus on it during design, make it part of your handovers, consider it while building and double-check it when delivering.
Something as foundational as accessibility can be judged with an audit, but just looking at the end-result won’t fix it. Even when you aim for compliance, it’ll be hard to reach from an audit.
Top comments (0)