If you’re an accessibility lead on a relatively complex digital project (for example, a mobile app, eCommerce site, or web app), you probably understand that 100% conformance with the Web Content Accessibility Guidelines (WCAG) is impractical.
That’s partially by design: WCAG contains a number of criteria that are not applicable to all types of content. The World Wide Web Consortium (W3C) recommends using Level AA conformance as a goal while striving to meet Level AAA criteria wherever possible.
But even if you’re aiming for WCAG Level AA, there are a number of requirements that are open to interpretation. As digital products have become more sophisticated, those requirements have created more challenges for accessibility teams.
Here’s how to take a nuanced approach to the “grey areas" of WCAG conformance — and how to make sure that your product is as accessible as possible for real, human users.
We’re using the term grey areas to refer to Success Criteria (SC) that can be plausibly interpreted in several different ways. These are the issues that can cause arguments, even among seasoned accessibility experts.
Solving a barrier that impacts people with a certain type of disability might make the content less accessible for another group. A common example is “dark modes,” which use high contrast to make text more readable for people with certain vision disabilities. Unfortunately, dark modes may be less readable for folks with dyslexia, astigmatism, and other conditions.
A practical solution is to offer an optional dark mode. But other accessibility concerns may be more difficult to resolve:
This is certainly not a complete list. Even fairly basic requirements — such as the requirement for alternative text (alt text) — are subject to a degree of interpretation.
Remember, WCAG is written to be applicable to current and future technologies, so interpretative differences are inevitable. We need to take a nuanced approach when we encounter these problems.
Accessibility leads and their teams need a structured approach to make informed decisions that prioritize genuine usability. We recommend following these basic steps:
WCAG is fairly simple and straightforward, but the W3C’s Understanding WCAG documentation goes into much, much more detail. You’ll find examples of SC violations, proposals for resolving barriers, and clear definitions of some of the confusing terms in the official WCAG document.
In many cases, you’ll find your exact situation discussed in the Understanding documents — so this should always be your first step.
Critically evaluate how different interpretations would affect individuals with various disabilities.
This requires some empathy, and it’s a key component of an accessible mindset (as opposed to a compliance mindset). Consider the user experience for someone relying on a screen reader, keyboard navigation, screen magnification, or other assistive technologies.
Does one interpretation create a minor inconvenience, while another could be a significant barrier to completing a core task? If so, prioritize core usability over convenience or aesthetics. For more guidance, read: Accessible Web Design: 6 Rules to Help You Build Better Practices.
Whenever possible, conduct targeted usability testing on the specific component or feature in question. Involve users with disabilities, particularly folks who use screen readers and other assistive technologies.
Direct feedback can provide invaluable, real-world insights into which interpretation best supports accessibility and usability, which can cut through debates about theory. Remember, your goal is to help real people use your digital product; real people are your best resource.
If you’re still having trouble interpreting a criterion, don’t guess. Accessibility consultants have experience across diverse projects and an understanding of how WCAG conformance looks in practice — including with technically complex projects.
Needless to say, you should make sure that your accessibility consultant is qualified to answer the question. You might ask about experience with screen readers and certifications such as the Certified Professional in Accessibility Core Competencies (CPACC) credential, but real-world experience with digital products is always the most important consideration.
Once you’ve made a decision on how to interpret and implement a solution for a grey area, it’s a good idea to document your rationale.
Note the following:
Your rationale might include a discussion of user impact and technical feasibility, along with any expert advice or user testing findings that informed the decision.
Documentation is crucial for consistency, particularly if you’re not the only developer or accessibility lead. Just as importantly, it demonstrates your due diligence, which may be beneficial if you receive an accessibility demand letter at some point in the future.
Navigating the nuances of WCAG conformance requires expertise and a commitment to genuine usability. If your organization is working to build truly accessible products, you’re on the right track — but you don’t have to do it alone.
The Bureau of Internet Accessibility (BOIA) has extensive experience helping organizations of all sizes achieve their accessibility goals. Our experts can provide the clarity and strategic guidance you need to move toward meaningful digital inclusion.
Ready to ensure your digital offerings are accessible to everyone? Contact BOIA today for a consultation and learn how we can help.