A Cautionary Tale…
Go to any McDonald’s restaurant in the world and there’s a good chance you won’t be able to order a milk shake, ice cream cone, or frozen dessert because the machine is broken. According to an article this last week in Wired, that’s because the $18,000 machine that McDonald’s forces its franchisees to purchase is fickle and fragile. Yet, when two clever entrepreneurs came up with a way to make it easier to maintain the machines, McDonald’s legal team came crashing down on them and destroyed their business. Why would McDonald’s want to stop a process that earns their restaurants thousands of dollars a day? Well, it seems, there was even more money to be made in servicing those machines.
I read the story as a cautionary tale about the disruptive effects of innovation. Why try to really solve a problem when you can make more money extending it? I know that’s a cynical statement when applied to my line of work because most accessibility consultants really do want their customers to make their sites accessible. But our customers may feel differently if they have to rely on us to test their sites… then test it again…. and again….
Only Three Models in 20 Years
I’ve been in web accessibility (both as a customer and a consultant) for over 20 years and I’ve noticed that we have surprisingly little innovation. There are three basic models for improving accessibility: automated testing, manual testing, and overlays. Putting aside overlays (which have been justifiably attacked by the accessibility community in recent years), automated and manual testing remain a staple component in any robust, enterprise web accessibility program.
And for good reason. On enormous sites with content that is constantly added, automated testing is the only way to quickly check that new content doesn’t violate basic accessibility requirements. And good manual testing is the only way to really tell if your web page is accessible and fully meets the Web Content Accessibility Guidelines (WCAG) A/AA. For the vast majority of companies, having a consultant perform automated and manual audits on their content is essential to maintaining an accessible website.
While automated and manual testing is critical, there’s a missing component: clear requirements.
A Better Approach
Have you ever wondered why the largest IT companies like IBM, Apple, HP, Amazon or Microsoft aren’t constantly having armies of third-party consultants auditing their web content? They are some of the most diversified companies in the world with hundreds of product teams in different countries. Yet, you don’t hear them complaining that loudly about the difficulty of maintaining web accessibility. Part of the answer is that these companies have their own internal accessibility standards that they use to ensure that everything that they design and build meets global accessibility requirements.
At Converge, we know because, in a former life, our principals helped two of those big companies mentioned above create their standards. Each was an enormous project costing over $150,000 and hundreds of hours of work. Most large companies don’t publicize their accessibility standards. A notable exception is Visa, which makes its Visa Global Accessibility Requirements (VGAR) free for anyone to download and use. VGAR is a fantastic resource (we refer to it frequently) and Visa has done a great service by making this resource freely available for comment or download.
While I love the level of detail that VGAR provides developers, I do have three minor quibbles with it.
- Too Developer-Centric. First, I wish VGAR also provided clearer guidance written specifically for creative teams. After all, so many issues—from alt-text to color contrast—could be nailed down by copy authors and UX designers before a developer has written a single line of code. Trying to wrap good code around bad design is like, to borrow a southern expression, putting lipstick on a pig.
- Too Organization-Specific. A second quibble I have with VGAR is that some of the accessibility requirements seem to be a bit too organization-specific. For instance, VGAR requirement NAV-WEB-001-03 states, “3rd party tools, plugins, and applets should not be used in the web application as it makes accessibility compliance more complicated, and this should be considered before choosing 3rd party technologies.” Within the confines of Visa, this makes perfect sense—but other organizations may find this difficult or impossible to accomplish. I wish that the organization-specific requirements like NAV-WEB-001-03 were collected in a separate section.
- Test Process Too Vague. Finally, I wish that VGAR provided more precise test steps. In many cases, the test process asks a tester to perform a test without identifying tools that assist in performing the test. For instance, VGAR requirement VIS-WEB-001-05-T instructs the tester to use the Text Spacing Bookmarklet—yet the online resources neither provide a link to the bookmarklet nor give instructions on its use.
But these quibbles are minor. In general, VGAR is easily one of the best and most complete examples of a set of web accessibility requirements. Of course, I have my prejudices and I believe that WebAlign does a much more complete job.
So Why Don’t We All Create Better Requirements
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.
Get WebAlign and Simplify Your Requirements
If you’ve come to the realization that developing your own internal set of requirements for web accessibility is the only effective way to be proactive in web accessibility, just know you don’t have to spend hundreds of thousands of dollars to get there. Instead, you could simply get WebAlign and, dare I say, easily clarify requirements from design, through development, and finally to QA/test. Just contact us today to set up an appointment!
And remember, “you don’t know what you don’t know until you know.” I would love to take credit for this sagely piece of advice. Instead, Craig Luigart was the first person I know who uttered this sagely pearl of wisdom. And boy is it true. Most organizations think that they have WCAG covered—until they realize they don’t. If you're in that situation, just remember that we’re here to help.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “Web Accessibility is Broken (Part 3)We Expect New Results from the Same Tools”