Automatically Test EASI Web Project

This video shows the testing/evaluation of a local web evaluation project using the EASI (Expert Accessibility Support and Integration) tool.

These are the steps that needs to be undertaken and are shown in the video: (Note: how to create such a project is shown in another video. If you haven't please watch that video first. Note 2: The links included in the following text will open the video on the youtube web page.)

  • In the project configuration the user can select the evaluation tests that should be performed. These tests include:
    • Tests grouped by the type of content they apply to, e.g. all tests related to forms, to images, to tables, to links and so on.
    • Tests related to search engine optimization.
    • Tests implementing WCAG 2.0 (Web Content Accessibility Guidelines 2.0).
  • After the user has selected one or more tests (in this case she has selected all "form related" tests) she can start the evaluation from within the configuration file. Note: the local HTML source code that is tested inside the video contains a login form with labels and text fields for the user name and password. However this form fails some accessibility criteria.
  • When finished the results are displayed in two different ways:
    1. At the bottom of the EASI developer perspective all the results are displayed in one table
    2. On the right side of the EASI developer perspective (in the "Accessibility Report" view) the results are grouped by the content they address, e.g. form related rules, image related rules and so on. This view has three tabs:
      1. in the "Summary" tab for each type of content the the following information is presented:
        1. Number of problems found by automated testing.
        2. Number of problems found by developer testing.
        3. Number of outstanding developer tests.
      2. The second tab "Automated Testing" displays all the evaluation results for those tests, that can be tested automatically, i.e. where the test either return a "pass" or a "fail".
      3. The third tab "Developer Testing" displays all those tests, where a manual check is involved that needs to be undertaken by the developer. For each grouping of result the developer can use arrow keys to navigate through the single results and highlight the related element in the browser.
    3. Using the "Accessibility Report" view the user discovers that there are two main issues with the form:
      1. Issue 1: The form does not have a submit button
      2. Issue 2: The form elements have no associated labels (although there are labels inside the HTML code, they are not implemented in an accessible way)
    4. Using the accessibility tips that come with the evaluation results (not shown in this video) the user is able to fix the problems, save / synchronize the web page and start the evaluation again. This time the tests regarding the labeling and the submit button pass.

Note: this video is part of a more complex use case which includes three videos:

  1. Create EASI Web Project
  2. Automatically Test EASI Web Project
  3. Manually Test EASI Web Project