Understanding How To Do Accessibility Testing

Posted by Albert Gareev on Jan 18, 2016 | Categories: AccessibilityMy ArticlesStories

This story was featured in my article
published on StickyMinds –
The Politics of Accessibility Testing”, January, 2016.


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.

Software developers – designers, programmers, testers, business analysts – must face the challenges to meet the legal standards and business needs.

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 #2:
Understanding How To Do Accessibility Testing

Test estimation is a tricky challenge by itself. How people approach this non-trivial task often defines the flow of testing phase. If estimation is not based on plausible assessment of efforts the results might be overly optimistic. Same happens if some risks were overlooked or underestimated.

I once was asked to review the testing strategy for a project that requested feedback and support from the QA center of excellence. I knew accessibility was in scope, but when I reviewed test coverage, I couldn’t find plans to run these specialized tests. I was told testers would cover accessibility aspects “along the way” while executing functional test cases. I asked whether it might be too complex to do everything altogether, but I got a reply that the testing team is comfortable using keyboard-only operations.

terminal1 Based on some presentation attended by the test manager, accessibility was perceived as a matter of keyboard support. She thought that as long as testers could tab through the screens, the application was considered tested for accessibility. This is indeed an important requirement, but it is not the only requirement.

Unawareness combined with overconfidence may cause a significant underestimation of risks. The testing team was invited to an accessibility testing workshop, where they learned about the multifaceted requirements and got acquainted with important skills and techniques, such as operating screen readers.

While testing teams may think they’re approaching accessibility testing seriously enough, it might be challenging to ensure the right coverage for legal compliance. Friendly suggested peer reviews and involvement in internal accessibility workshops may help spread understanding across the board.


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

  • Don’t take anything personally. Really, applies to all testing.
  • Be patient. Don’t expect immediate changes or big wins right away.
  • Support and create opportunities for trial and learning, like workshops and pilot projects.
  • Encourage participation in global communities and local Accessibility groups. Find them near you at and connect through Twitter (hashtag: #a11y).
  • Refer to the facts. Keep down the drama.
  • Help people to avoid feeling bad about mistakes, turn that into the benefit of practical experience.
  • Demonstrate what real help the tools can offer and what their fundamental limitations are.
  • Skills and experience are the main keys to success. Promote learning through practice.
  • Gain supporters across the organization. Make sure to speak their language.
  • Stay positive and be persistent.
  • Remember that your job is the service of testing. Let the product owners make final decisions about quality of the software.

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.

Image credits

  • Trackbacks

  • Trackback fromTesting Bits – 1/17/16 – 1/23/16 | Testing Curator Blog
    Sunday, 24 January, 2016

    […] Understanding How To Do Accessibility Testing – Albert Gareev – […]

  • Trackback fromJava Testing Weekly 4 / 2016
    Monday, 25 January, 2016

    […] Understanding How To Do Accessibility Testing is a blog post that made me feel (a bit) ashamed of myself. The reason why I reacted this way is that no one has ever done accessibility testing for the software that was written by me, and this blog post reminded me of the fact that this probably means that there are people who simply cannot use “my software”. It would be quite easy to say: “It is not my fault because…”. I won’t do this because I want to be proud of my work and blaming other people won’t help me to achieve this goal. Instead I decided to learn more about about accessibility. Where should I start? […]

    [Albert replies:
    Hi, Petri..
    Thank you for your comment.
    WebAIM ( has pretty good introduction articles on Accessibility.
    Good luck!]

  • Trackback fromCompelling Sunday – 24 Posts on Programming and QA
    Sunday, 31 January, 2016

    […] Understanding How to Do Accessibility Testing – Albert Gareev (Automation Beyond) […]

  • Leave a Reply

    * Required
    ** Your Email is never shared

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.