Follow

Using Access Continuum

APIs

Overview

Access Engine exposes a number of API functions, detailed below. These API functions can be used to use the Access Engine tests to test various development artifacts, from nodes to pages. Note that we have optimized the JavaScript in Access Engine and the entire testing process to ensure that these tests run super fast, and we are running these tests in our own continuous testing process. As such, organizations should see no performance impacts on their test runs. 

API Details

A number of APIs are available in Access Engine, but there are two that make sense within the context of Access Continuum: 

  1. runAllTests_returnInstances_JSON(): This runs all automatic tests and returns the results array as a JSON string. Note that for testing we then convert the JSON back into an array.
  2. runAllTests_returnInstances_JSON_NodeCapture(targetNode): Runs all automatic tests on the targetNode and returns the results array as a JSON string. Note that for testing we then convert the JSON back into an array.

Using the APIs

Introduction

The APIs detailed above can be used by Level Access customers in a variety of applications, but we have included 3 sample projects (to start -- more are coming soon) that show how they can be used. Review each of the sample projects to understand the complete setup and configuration, but there are essentially two "flavors" that are available at the moment:

  1. Jasmine/Karma (JavaScript)
  2. Cucumber/Selenium (Available for both JavaScript and Java)

Jasmine/Karma

  1. In the Jasmine/Karma project, the jasmine-jquery plug-in for karma is used to enable HTML components to be loaded into an iframe through Karma (although Access Engine is not actually written in jQuery).
  2. The Access Engine file is then included in the test folder, with no Continuum.js helper file necessary, to automatically make the Access Engine object (LevelAccess_AccessEngine) available in our unit tests.
  3. Once the Access Engine object is available, it needs to be directed to the window being tested (e.g. in an iframe’s contentWindow), before calls are made to the "runAllTests_returnInstances_JSON_NodeCapture(targetNode)" API function. Note: We tend to only use the "runAllTests_returnInstances_JSON_NodeCapture(targetNode)" API function in our unit tests as we want to just test the contents of the HTML widget under test – rather than the contents the whole page content of the test harness window (e.g. the iframe). In addition, we add additional reporting into our unit tests so that we are informed about the details of any accessibility issues located through an Access Engine test.

Cucumber

Sample Gherkin BDD Test

As an example, a typical Gherkin BDD test would look like:

Feature: Test a web page for accessibility

  • As a QA Tester
  • I want to open the url https://www.levelaccess.com/
  • So that I can test its different states with automatic tests in Access Engine  

Scenario: Run all automated accessibility tests on the specified web page in the page load state

  • Given the web page "https://www.levelaccess.com/" is displayed.
  • And Access Engine is set-up.
  • When I call Access Engine's "runAllTests_returnInstances_JSON" API function.
  • Then no accessibility issues are found.

Referencing Access Engine Tests in Cucumber

When using Access Engine through a BDD framework, the Continuum.js / Continuum.java helper file is required, both of which expose the same set of API functions:

  • setUp(WebDriver webDriver, String locationPath): With this function, the tester sets the webdriver to the webdriver flavor being used, and sets the local project location path to Access Engine (typically in a resources folder).
  • runAllTests_returnInstances_JSON(): This function calls the equivalent API function in Access Engine.
  • runAllTests_returnInstances_JSON_NodeCapture(String cssSelectorForNode): This function calls the equivalent API function in Access Engine.
  • getA11yResults(): This function gets the results from Access Engine as an array object of failing instances, collected together with the test id of the test they failed, and other relevant details. 

As mentioned before, Access Continuum uses the power of the test framework to get content, in a lot of cases web pages or views, to the right state before the appropriate Access Engine API function is called – and simply check that no issues have been found. 

The error message shown, if issues are located, also includes the failing instances found by Access Engine.

Customers may configure the post-testing actions per their internal processes. For example, at Level Access, if the last statement is not correct and accessibility issues are found, our continuous integration tool sends out the dreaded "someone has checked in bad code" email.

You will also note:

  • The "And Access Engine is set-up.” step, which is needed when the Continuum.js / Continuum.java helper file is used, as it allows the Continuum file to locate the Access Engine file within the project, and load it into the page under test.
  • The “Then no accessibility issues are found.” For convenience when BDD testing the results from a call to either API function are stored in a results object.  This object can be retrieved in this step – through the “getA11yResults” API function, and examined in the normal manner through expect statements.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Level Access Support
www.levelaccess.com | 800.889.9659
© 2005 - 2018 - Level Access All rights reserved.
Privacy | Security | Credits | License