The Politics of Accessibility Testing

[article]
Summary:

Web accessibility is often spoken about in terms of design, programming challenges, frameworks, and technical solutions, but there are also personal difficulties for the people involved. This article addresses some of the cases of initial resistance and provides a few practical ideas on how to minimize the challenges.

Digital accessibility refers to software supported by users' assistive technologies as well as accessibility within web browsers.

This concept, that software should be usable by the widest possible audience, has been around for more than twenty years, yet it remains out of the mainstream of testing and development efforts.

We have also seen diversity and digital inclusion become social priorities. On top of the implied social contract we have explicit legal contracts, such as Section 508 in the US and Canadian provincial legislations (AODA in Ontario, Quebec Standards for Accessibility, and others), which define accessibility standards for government and public sector software. This sets a trending example for the overall market. However, laws and regulations do not define accessibility requirements on their own; they refer to the Web Content Accessibility Guidelines and only dictate the level of compliance, from A to AAA. Note that this web standard is evolving, so the same laws mandate keeping up with the changing requirements.

Web accessibility is often spoken about in terms of technical solutions—design and programming. Less voiced are the challenges of the people involved in the change, conflicts of interests, and people’s perceptions that sometimes create problems bigger than technical challenges.

As a testing practice lead taking on the accessibility testing domain, I was surprised by resistance to the initiative. I couldn’t understand why such a noble goal was not welcomed. I was frustrated by misunderstandings and misconceptions—but I also was responsible for causing some of them.

Here, I relate some situations I’ve experienced and provide some insight on people’s perceptions and reactions that may increase challenges in adopting accessibility.

Challenge #1: It’s Not Business Requirements, It’s the Law

On one project, the development manager saw accessibility as a feature that would create change requests and new business requirements. But the business side insisted accessibility be treated like other system qualities built from the ground up—security, performance, maintainability, etc. Development kept stating that these are new business requirements and should be reflected with a budget increase. The business wasn’t ready for such a turnout, and accessibility was excluded from the release scope, with the resolution to address it next year.

Newly introduced laws and regulations may have a disruptive effect on business goals and budgets. Products that weren’t built with accessibility will require updates and rework, which means extra costs; that is just reality.

When you are the bearer of such “bad news” that the product in the near future might become legally incompliant, both business and development people might feel insecure. The main challenge is not technical work and financing, but how people feel about this serious problem—and about the messenger.

A good strategy is to approach very cautiously, avoid making sudden and dramatic announcements, and be empathetic. It is important to keep the trust. You may suggest conducting an informal assessment first. Argue that before making any decisions, it is worth finding out how big the problem is.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.