It’s Not Business Requirements, It’s the Law
This story was featured in my article
published on StickyMinds –
“The Politics of Accessibility Testing”, January, 2016.
Preface
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. Nowadays friendliness of information technologies and user experience are gaining more and more importance.
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, AMA in Manitoba, 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.
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
Any major software changes, such as making an existing application accessible, or even adding accessibility features into the scope of the current project, in managers’ minds are reasonably associated with costs, efforts, and impact on delivery schedule.
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.
From a technical standpoint, give specific examples where improvement is required. Suggest areas and categories where code changes are most needed.
Breaking down this whole scary legal compliance problem into separate technical points lets you speak the same language your stakeholders are used to. The business side gets a choice to prioritize and budget the improvements, and the development side gets a better understanding of what skills and effort need to be allocated.
Conclusions
Accessibility is about Human Rights, Equality, Diversity, and Inclusion. It’s also a social responsibility and a legal obligation, at least for public companies. And this is an opportunity for business growth and demonstrating excellent customer care!
Supporting Accessibility is a noble goal, and people are willing to subscribe to it – in theory. In practice though, they may resist or appear resisting. Sometimes because supporting Accessibility will conflict with the interests they deem more important. Sometimes because they apply an approach they’re used to without consideration of the specifics of Accessibility. Sometimes it’s just a bit of misunderstanding. After all, this is very new for many teams, and they could use help in learning the technologies and adapting their processes.
As a testing practice lead I see the success in exactly that – helping people to gain practical experience in Web Accessibility domain. This will ensure forming the right understanding and successful approach.
Useful Hints
 |
|
Test Strategy Outline
- Treat Accessibility just like any other system feature.
- Supporting Accessibility at the development framework level will significantly reduce the scope of testing.
- Having standard GUI classes with built-in Accessibility features will help to create UI Mocks, test very early, frequently, and reduce risks of regression.
- Test the design: begin with UI mock-ups and Wireframes.
- Use risk-based sampling to quickly identify areas of incompliance.
- Use automated checking for timely detection of unwanted changes (regression).
- Grow your in-house Accessibility Testing specialist or hire a consultant to teach the team through practice.
