Our Current Web Accessibility Consulting Model is Broken
Jeff and I have been helping companies with web accessibility for over 15 years now, even though our backgrounds in web and digital accessibility extend far beyond that. In most of those years, we've performed hundreds of accessibility audits for companies. And all of our customers have been really grateful for helping them. At that level, we're really no different from any of our competitors/partners who do exactly the same thing-- we all will review a site with the customer, identify accessibility problems on web pages, and help their web development teams fix their sites. If you've hired us or any of our competitors (who may or may not use automated scanning tools), this should all sound familiar.
The problem? It doesn't work.
If you've been through this process with having your site reviewed, the following scenario should sound familiar. You get your accessibility audit and everything makes perfect sense to your development team. They make all of the recommended changes and everything seems good. But six months later, things seem to start falling apart. And a year later, it feels like you're starting from scratch all over again. Some customers unwittingly think that the solution is automated testing so they can catch all of their problems as they arise. While automated testing definitely has its place, that place is not trying to stem the tide of inaccessible content. To understand why, it may help to take a step back and consider the nature of the problem at a higher level.
Accessibility is Mostly a Design Problem
The problem is that, 90% of the time, web accessibility is not a problem with how web pages are coded as much as how they are designed. Let's consider a really simple example: alternative text on images. If a web page includes an image that doesn't have alternative text, we naturally see that as a problem with bad coding. But could the real source of the problem be that the copy author or UX designer never told the developer what the alternative text should be for an image?
Remember: Accessibility is fundamentally different from security, privacy and other areas of web compliance because accessibility is mostly about design whereas security and privacy are mostly about coding.
Let's consider how this plays out in the way that most organizations address an accessibility audit or the way that they use the results of their automated testing procedure. In the following image, we have a typical web development process. First, we have the creative/design teams that include UX designers, copy authors, and graphical artists. They feed their creations to development for coding, which passes their creations to QA/test, which can include outside accessibility consultants or third-party testing tools.
In the typical accessibility model, which is shown in the following diagram, feedback from QA/Testing/Consultants only goes back to developers, who fix the immediate accessibility problems. And they respond to this feedback quickly, which is why there is a short-term increase in accessibility. This model works fine if the design side is ignored.
The problem, of course is that the creative teams are still creating copy, wireframes, and media that doesn't include any of the accessibility changes recommended by the accessibility consultants, QA teams, or automated testing tools. This is represented in the following diagram. So long as inaccessible content continues to be fed into the front end of the development process, the development and QA/Test teams are forever in a cycle of "catching up" with the inaccessible content created by the creative teams.
When you're caught in the "catch up" game, this may seem to be an intractable problem. After all, inaccessibility content creeps into the system and gets coded by the developers. This means that, of course, the problems need to be fixed by the developers. This is also the model that most of us have just accepted as inevitable, just in the same way that we scan code for security violations that crop up as hackers learn to exploit new vulnerabilities. In fact, we know of one major insurance company that was paying over $1 million a year to a major accessibility consultant to stay trapped in this accessibility loop.
A Better Approach
Viewed from a high level, the solution to this problem is obvious-- design needs to also be accountable for inaccessible content. The image below shows the way in which we now provide our audits via our WebAlign tool. A good consultant should not only give your development staff the information it needs to make accessible code, but it also give you the resources your whole team needs to make sure that the same accessibility errors don't repeat themselves.
How Does This Work in Practice?
Our WebAlign tool, which we use in all our accessibility audits, breaks the Web Content Accessibility Guidelines (WCAG) down into terse and very specific requirements at a role-specific level. To take a simple example, anyone in web accessibility can tell you that WCAG 1.3.1 is impossibly vague; it's only 16 words long but to understand it, you need to read through 50 different supporting techniques and 13 different failure techniques. WebAlign breaks WCAG 1.3.1 down into seven requirements-- one of which addresses headers. Specifically, "structure in headers follow a proper hierarchy of header tags." At a role-specific level, this is broken down into:
- Copy Authors: When headings are used in web content, make sure to use header tags. Furthermore, follow a consistent and proper hierarchy starting either with level 1 (only one level 1 heading should exist) or level 2.
- Developers: Ensure that the Document Object Model uses a consistent hierarchy of <H1>, <H2>, … , <H6> tags. If necessary, you can mix and match aria-level attributes (e.g. role="heading" aria-level="7") with <Hn> tags, provided that these levels respect a proper and consistent hierarchy.
- QA/Test: Ensure heading levels follow a consistent hierarchy beginning with an <H1> or <H2> tag, via code inspection or using a scanning tool or browser extension. If <Hn> is not used, make sure headings use aria-level and that these levels respect a consistent and proper hierarchy. If <Hn> and aria-level are used concurrently, ensure that all such heading respect a common, consistent, and proper hierarchy.
WebAlign also includes a documentation tool where each stage of the development process can identify how they met each requirement. This means that, when QA teams identifies an accessibility error with header structure in WCAG 1.3.1, they can easily pinpoint the fix but also whether the error originated as as design problem or a development problem. And, because this process makes it easy to distinguish between design and development errors, it prevents new errors from creeping back in the system.
Why Are You Doing This?
Frankly, there is a LOT MORE MONEY to be made supporting the existing accessibility consulting model. After all, telling customers how to avoid problems in the future is a lot less profitable than telling them over and over again how to fix problems (that are mostly identical to old problems). As a small consulting firm with a lot of experience, we'd prefer to make a big difference and help our customers create a culture of accessibility.
If you want to avoid the trap of the old model of web accessibility and adopt a simpler system for incorporating web accessibility, book a quick call with us now for a walkthrough of the how we can revolutionize web accessibility for you today.
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 1)Most Consultants Don’t Address Design”