Web Accessibility is Broken (Part 3)We Expect New Results from the Same Tools

If your organization has been through the traditional web accessibility consulting model, you’ll likely appreciate the importance of creating an internal set of web accessibility requirements like VGAR. There are four common myths that I hear all the time—both from experienced accessibility professionals and novices—that push back against the idea of creating rigorous requirements.

• Myth #1: Web Accessibility Is Easy. Plenty of experts in web accessibility will tell you that web accessibility is easy. And many will offer you a short list of basic best practices that essentially cover all of WCAG. While that makes a great introduction to web accessibility and may even prevent your organization from getting sued in the short term, I’m here to tell you that web accessibility isn’t that easy. I fully understand why we sometimes need to make people believe that WCAG is easy—if we don’t, many developers won’t even lift a finger to make a website accessible. The reality is that the guidance provided by WCAG is often vague, very technical, and fragmented. As a result, much of WCAG is not fully understood and misapplied. Let’s face it: really getting WCAG right is actually quite hard for someone who doesn’t already know web accessibility and even for many who think they know accessibility.
• Myth #2: WCAG is Already a Set of Requirements. WCAG refers to itself alternatingly as a set of “standards”, “guidelines”, and “requirements” despite the fact that it is named the Web Content Accessibility Guidelines. In the built-environment world, we note that there is a big difference between these words. For instance, the ADA Accessibility Guidelines (ADAAG) developed by the Access Board didn’t have the same force of law until they were adopted by the U.S. Department of Justice—and became the ADA Standards for Accessible Design. Regardless of how you define each of these terms, WCAG isn’t precise enough to form a set of requirements. A perfect example is WCAG 1.3.1 and ARIA landmarks (“main”, “contentinfo”, “banner”, etc.) along with their associated HTML regions elements (<main>, <footer>, <header>, etc.). WCAG 1.3.1 doesn’t say that landmarks and regions are required; instead, it only gives wishy-washy advice that implementing landmarks and regions aids in meeting WCAG 1.3.1. At best, this makes landmarks and regions into just a best practice.
• Myth #3: Web Accessibility is Just Good Design. I’ve noticed that, when UX Designers are first introduced to WCAG, many will trivialize WCAG and say that it’s “obvious” and “just reflects good design principles”. Yet they will then go on to remove the underlining on links on a page, hide the visual indicator of focus, or create tab or accordion controls without thinking about the “state” of that control (e.g. expanded or collapsed) for their audience. Good requirements need to focus on the creative side of web production just as much—if not more—than the developer side of the house.
• Myth #4: Web Accessibility is Like Security or Privacy. We talked about this problem in our first installment. At it’s core, accessibility is a design problem and not a code problem. The reason is that breaches in security and privacy violations tend to revolve around vulnerabilities in the code that are likely not known ahead of time. By contrast, accessibility problems start and end with UI issues that are easy to predict. One obvious conclusion of this difference is that creative teams need to be involved in accessibility issues far more than for security and privacy issues. Another consequence of this difference is the type of solution needed for the problem. In the case of security and privacy, lots and lots of vulnerability testing after the fact is needed. While these same solutions are useful with accessibility, organizations also need a stronger focus on proactively including known accessibility solutions from design through development and ultimately to QA.