Thinking about Digital Accessibility: The Enterprise Journey

By H ROBERT KING

It is sometimes difficult to remember, but most digital resources have not really been around that long. What we affectionately call “the Internet”, more accurately known as “the Word Wide Web,” is younger than the 30 year-old Americans with Disabilities Act, and digital accessibility is younger than that. With the rise in demand for access, and the massive migration to online resources in 2020, organizations are eager to ensure their digital resources are accessible, but they are often at a disadvantage from the lack of information and rapid technological changes they face.

In this book, we explore what an accessibility program looks like at an enterprise level and how it grows and develops as it matures. Business justifications, stumbling blocks, as well as organization and personnel issues all find a place in the discussion that has been called “the high level playbook”, “the perfect overview,” and “a primer on accessibility…to an enterprise that doesn’t know where to start”.

• Language: English
• Publisher: Lulu.com
• Release date: Aug 20, 2021
• ISBN: 9781304804839

Book preview

Introduction

One of the topics organizations are becoming eager to address is how an organization can ensure all of its products are accessible. Although there are a number of advantages to building accessible products, frequently the desire to ensure accessibility is a response to external interest, or pressure, in the accessibility measures an organization has taken, or not taken, often in the form of a civil action taken in the courts, or as part of a Structured Negotiation¹.

While there are disadvantages to a focus on the legal requirements for accessibility, the legal requirements are a significant concern and must be addressed alongside the advantages building accessibility brings to an organization. Justification for accessibility programs aside, however, there are still significant questions about how accessibility at scale can be achieved, and accessibility at scale can become particularly difficult, in part because of the history of digital accessibility and how the work has been performed in the past.

It is sometimes difficult to remember, but web pages have not really been around that long. What we affectionately call "the Internet", more accurately known as "the World Wide Web," is only about as old as a Millennial, and digital accessibility is younger than that. It’s helpful to look back at how industries have evolved over time to see what that might tell us about web development work and digital accessibility, both their past and their future.

In times past, if someone needed a new pair of shoes, they would visit the cobbler, or if they needed a new dress, they would visit the dressmaker. The artisan, who likely learned the trade from their parents, who in turn learned it from their parents, going back generations into history, would take the measurements, ask questions about how the item would be used, and then design and create the product. These bespoke items were well-suited for their purpose and, if the crafter had learned their trade, well-made. Granted, we have succeeded in separating the design and construction roles to some degree; however, software engineering, including web applications, is still very much in this stage. Product owners talk to designers, and perhaps user researchers, who craft a user experience. Digital accessibility, long considered a part of software engineering, is also in this same evolutionary stage.

Accessibility has, traditionally, been a thing that has been added on at the end, because that is when accessibility evaluations have typically been performed. One of the reasons provided for why testing is typically pushed to the end is because that is where the testing for Conformant Accessibility is easiest; however, that is not the only reason. Another, important reason why accessibility has been an at the end problem is because accessibility is like those bespoke shoes and dresses, it has been the domain of dedicated artisans who have gone out of their way to learn more than the basics about their craft. More than knowing what type of leather or silk to use or the height of a heel, these professionals have taken the time to learn to create shoes with soles of different thickness to accommodate customers with one leg shorter than the other leg, or they have learned which dress lines flatter which body types. This sort of customer-facing knowledge is essential in building an accessibility program and delivering accessibility at scale, but it alone is not enough.

When we use the term at scale, we are talking about multiple products or features in development simultaneously, and when we talk about accessible human-computer interfaces we are discussing something markedly more complex than shoes or clothing. Expecting designers and developers to each add the required amount of knowledge to build fully accessible interface to their existing knowledge base is not only cognitively daunting, it is realistically too heavy a load to maintain. It would be analogous to expecting the cobbler who has learned the skills to finely craft your shoes to also learn the skills to finely craft your apparel.

Further, the amount of knowledge in each domain is ever increasing as those who develop human-computer interfaces have been encouraged, or required, by product development or technology management teams to keep pace with advancements in hardware to exploit those advancements. The practice of exploiting each generation’s greater processing power and speed to design increasingly dazzling and dynamic interfaces has created an implicit corollary to Moore’s Law². The amount of design and engineering knowledge required to keep pace can prove daunting, and the corollary addressing the requisite design and engineering knowledge applies to accessibility knowledge as well.

A side effect of this evolutionary model, with two-year generational cycles, has been the development of increasingly strong boundaries between designers, engineers, and accessibility experts, as each group struggles to keep pace with the complexity, maintaining and building their knowledge and struggling to resolve differences between the competing needs. As Neil Milliken, the Global Head of Accessibility at Atos said in the first session of the Strategic Leader in Accessibility webinar series, the complexity of the program we need to run, if we’re going to be successful, is immense. (Casey and Milliken) We can try to simplify the needs along product, design, and engineering lines as much as possible, but it will not be enough. The complexity of delivering accessibility at scale is too great for it to be the responsibility of a grassroots, bottom-up approach that relies on people dedicated to their craft in design or engineering.

Until we manage the complexity, we will not be able to deliver accessibility at scale, and it takes a village to do both, and a village whose members recognize their role, that their way of seeing the world is different than others, and that they need to work together, is further along on that journey. The purpose of this book is to help you along that journey by establishing a shared foundation and identifying the different tools, processes, and roles involved in large accessibility efforts so we can get there, together.

Accessibility for the Enterprise

When we talk about accessibility in an enterprise, the clearest pathway to success is a pathway that brings accessibility fully into the enterprise by making it a part of the shared attitudes, values, goals, and practices of the organization. Developing and integrating accessibility into the culture of an enterprise can pose specific challenges, but recognizing and measuring its progression will go a long way to meeting those challenges. Recognizing inflection points and stumbling blocks enables an organization to bring accessibility into the organization and operate at scale, with the least amount of difficulty.

Measuring Progress

To recognize and measure the progression of accessibility we will draw on a common resource used to assess the maturity of a process in the software engineering community, the Capability Maturity Model Integration (CMMI), which will allow us to understand an organization’s maturity using the model’s six levels: "Incomplete", "Initial", "Managed", "Defined", "Quantitatively Managed", and "Optimizing".

Incomplete Level

CMMI level 0, incomplete