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:
After fixing the bugs from the code or after modifying the content of a page, we made a new deploy with the changes, and then we had to reintroduce, in the AChecker tool, the URL of the web page which was needed to be retested.
Web pages which use the HTTPS protocol couldn't be tested.
Therefore, in order to overcome these issues, we created the ARobot project.
The AccessibilityRobot application comes with all of these inconveniences resolved:
The HTML code is not externalized.
The HTTPS pages can be tested.
The dynamic web pages can be tested.
You have to register the URL of the web page you want to be tested just once. Then, it will be automatically tested daily / weekly / monthly.
Besides these, the ARobot project comes with a very simple interface where you can register the web pages for the projects you want to be automatically tested daily / weekly / monthly. The ARobot job is programmed to run daily at a specific hour. This is the time when all the registered web pages are automatically tested in terms of accessibility standards. The result of the test is rendered as a HTML file and attached to an email that is sent to people which are subscribed for each registered web page. The test results, which come under the form of HTML files, are kept by our application.
The ARobot main page contains a menu which gives the opportunity to navigate over four sections: History page, Passed Results page, Manage page and Info page.
The History section is the place where all the execution tests which were run by this application are displayed, in a chronological order. This is the place where all the test results can be seen. Also, it displays a link to the HTML result file for each test run which was ever executed for a registered webpage.
Another part of the application is the Passed Results section, the page which contains a catalogue of all test runs which were finished with a PASSED result regarding the accessibility of the webpage. The PASSED result, in terms of accessibility for a web page, is rarely obtained and because of this we decided to have a special page dedicated to this category of web pages.
The last section of the menu contains the Manage page. Here, all the registered projects and web pages are displayed. The user has the option to subscribe to one or more registered web pages in order to receive an email containing the accessibility test result for the web page to which it subscribes.
The Info part was created in order to explain what the purpose of the ARobot project is, how it can be used, how it works, what its job is, what accessibility means and so on. It also presents the team members in order to enable the communication among the people who were involved in this project and the people who are interested in the topic.
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:
by Andrei Oneț
by Raul Boldea
by Paul Bodean , Eugen Meltis
by Dan Sabadis
