All Topics
Debugging
Going Beyond Compliance

Going Beyond Compliance

Dr. Evil quotes meme: 'Accessibility Compliant'

Accessibility compliance is something organizations strive for out of fear of litigation, market competition, obligation to shareholders, and principle. But I’ve seen it included as a requirement in projects where there’s no culture of accessibility whatsoever. It takes requirements and repeated effort to make something even close to compliant.

Also, just because a site claims to be “compliant with WCAG” doesn't mean it’s necessarily a good user experience. “Compliant” could also possibly be true only for a short time until a site is updated and it needs to be re-tested. Don’t get me started on overlay tools (opens in a new tab) that claim to make a site “accessible” with one line of code.

A better way to think about accessibility and compliance is two-fold:

  1. It needs to be part of the design, its product DNA.
    The earlier, the better.
  2. It's a constant work in progress.

As you learn about issues, fix them. Repeat. Try to anticipate accessibility going forward as a general matter of software design and quality. It’s a culture!

Accessibility Statements

Make it possible to receive user feedback for accessibility with an Accessibility Statement (opens in a new tab). There’s bound to be room for regular improvement, especially when someone tests your site with a workflow or condition you hadn’t yet considered (usability with keyboard? other Assistive Tech? interaction flow on small/zoomed viewports?). You might not be able to fix every issue for every person, but obvious blockers should be prioritized.

Don’t stop at tooling

Tooling is an essential part of accessibility testing, but it can only highlight a subset of issues. We are limited by what can be automated for accessibility and also our own biases when testing.

Even the Web Content Accessibility Guidelines are just a starting point while developing a delightful Accessibility User Experience (AUX).

We can’t rely on tooling or WCAG completely, like “calling it good” after getting a Lighthouse score of 100% or a perfect Axe result. There’s an epic article that highlights this problem from Manuel Matuzovic you should read called Building the Most Inaccessible Site Possible with a Perfect Lighthouse Score (opens in a new tab).

Eric Bailey also wrote a nice piece on the Importance of Manual Accessibility Testing (opens in a new tab) for Smashing Magazine that gets to the heart of it.

Working with people with disabilities is a great way to go beyond the minimum for crafting an accessible user experience. In fact, it’s really essential to gather feedback from the people affected by an inaccessible user interface. Companies like Fable (opens in a new tab) can connect you with a community of disabled testers whom you can pay to provide critical product feedback at any time (though the earlier in a project, the better).