Issue 59


Sebastian Boga
Test Consultant @ Endava

Raluca Beian
Developer @ Endava


Nowadays, more and more companies are concerned to make their web pages accessible to as many users as possible. Because of this, we started to turn our attention to a special category of users: users with different kinds of disabilities. Websites owners want the delivered information to be accessible not only to the regular people, but also to those with disabilities, whatever the disability degree is - temporary or permanent.

Therefore, one aspect the testing process focuses on is this type of users - people with different disabilities. The World Wide Web Consortium (W3C) has initiated an international procedure by which they try to establish a set of good practices and recommendations, named Web Accessibility Initiative (WAI).

These rules are described as good practices and they support the standardization of web page objects in order to be correctly interpreted by a specialized soft and to be displayed properly on the web page, so that it can be understood by people with disabilities.

These strategies, guidelines and resources come to help us create web content which is accessible to people with disabilities. As a result, the user experience for all types of users is significantly improved. However, if requirements are taken into consideration, a consistent improvement can be noticed in S.E.O.

Currently, there are several compliance standards. The most frequently requested standard is called WCAG-2.0.

If you want to become a tester specialized in Accessibility Testing, you should start by trying to understand what the accessibility concept is, to whom it is addressed, what the accessibility principles and guidelines are. Moreover, you should take a look at each of these guidelines and then test each guideline on a web page. The effect is not a visual one, so you should still know what HTML is, what each markup means, what each attribute refers to and so on.

If the rules are not observed, the impact for a common user is not distinguishable and, as a result, it is hard to identify the accessibility problems before the test process.

Because Accessibility Testing is a difficult process which consumes a big time chunk of the testing phase, we decided to automate this process. By researching the existing testing tools for automatic testing which are specialized on Accessibility Testing, we found the AChecker, a tool which comes with an API.

The client claims are growing more and more, and one of their exposed requirements requests that any piece code, which is written for the client, should not be exposed anywhere outside. As a response to this requirement, we implemented the AChecker tool on the internal servers of our company.

By testing using the AChecker tool, we realized that the testing time has decreased considerably. The irregularities were found pretty fast, but even so, there were some steps which made the process uncomfortable and among these, we mention:

Therefore, in order to overcome these issues, we created the ARobot project.

The AccessibilityRobot application comes with all of these inconveniences resolved:

The ARobot project is ready. Until now, more than 50 web pages were registered in the ARobot application in order to be automatically tested in terms of accessibility. ARobot is accessible just in Endava:




  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Colors in projects