A Continuing Problem...
Last week, I talked about the elephant in the room of web accessibility consulting-- the current model is broken. Jeff and I knew this when we started Converge Accessibility and we're trying to do things differently. Sure, we want to help companies make their websites accessible-- but we also wanted to give them real tools to help them stay that way.
Again, let's start with the current accessibility model that dozens of consultants use. First, the consultant reviews your web site and identifies pages for manual testing. Second, they perform careful manual testing on those pages-- and may or may not augment that manual testing with automated testing of your site. Then, they come back with a detailed audit report that explains the problems and gives your web development team strategies for fixing that content. It's a model that has been used for over 20 years in this industry... and it's barely moved the needle at all to promote web accessibility. Invariably, after six months to a year, the process has to start all over again.
Organizations can spend a small fortune stuck in this trap. We know of one major insurance company that was spending over $1 million a year to a web accessibility consultancy to make their websites accessible. This is absurd because web accessibility isn't that hard.
Again, it helps to stand back and look at the problem at a more abstract level. Why can't your web development teams learn from an accessibility audit and become proactive in web accessibility? Last week, we discussed one reason-- it's because the lessons from your audit never reached back to the creative teams and so all of your work fixing the problem was overridden by the next set of wireframes or copy.
But there's another problem that we'll focus on this week: a regular accessibility audit provides absolutely no transfer of knowledge.
If You Can't Solve the Problem, There's a Lot of Money to be Made Extending It
For our major competitors, the last thing in the world that they want is for you to really understand web accessibility. There's a cynical saying in the world of consulting: "if you can't solve the problem, there's a lot of money to be made extending it." Sadly, most major web consulting firms follow this model closely.
- Training Programs. Sure, some companies offer "XYZ University" (substitute your favorite web consultancy name for "XYZ") programs that give your designers and developers tips on how to create accessible content. But learning simple lessons that are far removed from the day-to-day practice of actually making accessible designs and code won't accomplish anything, especially when most training programs are ineffective and just waste time and money. Further, there is rarely any sense of accountability to apply lessons learned. At best, this makes accessibility into a set of optional best practices that is rarely, if ever, applied.
- Embedded Consultants. It is not uncommon to see larger organizations hire consultants to provide experts or testers in-house to help with the accessibility efforts of a particular project. The expert is there to answer questions and provide guidance as issues arise and the accessibility testers are there to review the product during the development process. While this can result in the final product supporting accessibility, it almost never results in a knowledge transfer. The focus is on the project at hand and once that project is complete, the accessibility expert and testers are off to another assignment at another organization and the accessibility expertise has gone with them.
- "Capability Maturity Models." If there is one issue that bugs me more than others, it's how digital accessibility has corrupted the term "capability maturity model" from what the term actually means. The Capability Maturity Model (CMM) was developed by the Software Engineering Institute at Carnegie Mellon University. The software CMM (SW-CMM) included five levels (initial, repeatable, defined, managed, and optimizing) that focused on how well-defined processes are within an organization. The SW-CMM is all about high-level strategy. In this sense, the SW-CMM could be overlaid as-is on top of any web development process. Instead, in web and other contexts, companies have seized upon the CMM as a set of tactical steps that they assert builds towards a higher level of accessibility. Worse yet, most company's CMMs don't follow the five-step program of the SW-CMM and instead follow randomly-named steps. But what is it really, really bugs me about how their "CMM" models work? They typically fold in an increasing level of dependence on their products and services. Remember that $1 million insurance company contract? They were quite high up in their consultant's maturity model until they decided to pull the ripcord and develop their own program thereby reducing their dependence on the consultant. If you want to follow the SW-CMM, that's absolutely great; just stick to the original version that focuses on actual process improvement.
An Example of the Problem of Lack of Knowledge Transfer
Most web accessibility consultancies offer similar approaches to their customers. This includes an initial website accessibility audit that may or may not include an automated testing solution. Some omit the manual testing entirely and only provide a review using an automated testing solution! Using only an automated scanning tool can catch some critical issues but ultimately provides only a false sense of security. This is because these tools can accurately scan only a small part of what really needs to be tested. The rest must be reviewed manually to accurately assess the accessibility of a website. Manual testing is critical to accessibility success.
Whether manual testing is performed or not, the audit results are provided back to the dev team who then enter the issues into the organization's bug tracking system (e.g., Jira) to track the progress of addressing those issues. Once the issue is fixed, it is marked as complete and then archived into the bug tracking system.
What is wrong with this model? The information provided on these accessibility issues almost never find their way back into the design, development, and QA process. The web team still has no idea how to ensure that its websites are created accessible and remain accessible because there is no knowledge transfer.
A Better Approach
At Converge Accessibility, we run a nimble practice. We don't want scores of testers working on mammoth projects. We want to give our customers the solutions that they need so they can be truly proactive. And part of that is good knowledge transfer. We do this by incorporating two facets missing in our competitor's offerings.
Clear Examples and Code Samples
First, when we perform an audit, we provide screenshots and very clear code samples-- plus recommended changes to that code in order for it to make sense to your developers and designers. For instance, the screenshot below is a typical example of our report format. First, we identify the WCAG provision (in this case Success Criteria 1.3.1) and then describe the problem (in this case, the visual label is not programmatically associated with the control). Then we provide a screenshot from the web page that illustrates the visual label and the associated control. Below that is the code snippet taken directly from the web page. Then we provide a description of the impact on users with disabilities and a technical description of why correcting the problem helps users with disabilities. Lastly, we provide a recommended code change and a description of where the error occurs.
In our opinion, if your audit reports don't give your web development teams this kind of detail, they are doing you a disservice. Web development teams need to know what the problem is, why it's important, and how to fix them. But, after having done web accessibility audits for almost 20 years, we also know that this isn't enough to really make our customers independent and proactive.
Precise Requirements and a System for Accountability
The second part of the solution is to give each web accessibility audit customer a subscription to WebAlign. Now, each entry in the report would point to the relevant section in WebAlign that discusses each issue. Below a screenshot of the WebAlign page for our module on WCAG Success Criteria 1.3.1, which was used in the last example. Here, we provide a brief training video specific on this requirement (we have about 80 similar videos built into WebAlign). Plus, we have tabs that described how UX designers, developers, and QA teams need to work together to make sure that WCAG 1.3.1 is met. After all, if designers aren't trained on the same requirements as developers, inaccessible designs are just going to creep back into the system. Most recently, we've also added basic testing steps that use freely available manual test tools (not difficult-to-use and expensive assistive technologies) so QA teams can make sure the code is correct. Plus, because developers can see those easy test steps themselves, they can make sure their code meets requirements before it ever hits a production server.
But the real "glue" that ensures good knowledge transfer and accountability is WebAlign's series of interlocking guides or checklists that forces training principles in day-to-day practice. In the screenshot below is a snippet of how these work. This snippet is taken from the developer checklist-- there are also guides for all pre-production teams (copy, UX, graphics), developers, and QA teams. For instance, for "language of page", the guide tells us that either copy or design teams need to include the language of the page in their designs (it's part of their checklist). The item number is a link directly back to the associated training video. This system means that each member of the web development team learns exactly what they need to know and can immediately apply it. In our opinion, this is how knowledge is effectively transferred.
Ready to Get Off the Web Accessibility Merry-Go-Round?
Companies come to us when they're sick and tired of paying a lot of money over and over again-- and always remaining stuck behind the eight ball. If you want to get out of the same old rut 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 2)Lack of Knowledge Transfer”