Illustration of user on PC with Attest 2.0 extension on screen.

WorldSpace Attest HTML 2.0 Coming Soon

Illustration of user on PC with Attest 2.0 extension on screen.

WorldSpace Attest HTML 2.0 is nearly here! Here is what you need to know about the imminent release to help you prepare for the rollout at your organization.

Major Feature Highlights

The major features in this release include:

  1. Codeless Testing: Improved capabilities to test server applications without writing integration or unit tests. We call this “codeless testing” – and it is delivered through version 2.0 of our AGet utility.
  2. Selecting your rules engine: Improved ability to ensure consistent results between different WorldSpace Suite products and between different components of WorldSpace Attest.
  3. Support for the emerging Web Components standards: Axe-core 3.0 now supports web components.

Major Improvements

In addition to the major feature additions, we have significantly improved some of the existing capabilities, including:

  1. Improved Node APIs,
  2. Improved handling of exceptions in Java and Ruby, and
  3. Significantly improved reference documentation.

How to Prepare for the Release

Artifact deployment

Once released, you will be able to download new artifacts from Agora, Deque’s Artifactory repository, or Deque’s SFTP site (depending on your preference). If you have your Nexus or Artifactory set up to synchronize with Agora then this should happen automatically. If you do the synchronization manually, you will need to login to your system and instruct it to synchronize with Agora.

It you are using the preferred method of deployment for APIs: your own Nexus or Artifactory – your users will have to explicitly update the dependencies to pull in the version 2.0 APIs because of the change in the major version number of all the relevant files. Attest-java has a new version number of 3.0, AGet has new version number of 2.1 and all other modules have a major version number of 2.

Important: Attest-node has a breaking change in 2.0, that significantly improves the understandability of the tool. Because of this, version 2.0 is not backward compatible with Attest-node 1.x. Upgrade instructions are available in the Attest API documentation.

If your users are including the specific API files into their project. Then they will need to be supplied with the new versions of these files.

Browser Extension deployment


You can download the new .xpi for the Firefox Attest extension from Agora or the SFTP server and deploy it to your users with your standard desktop deployment.


If you are deploying Chrome using a .crx file, this can also be downloaded from Agora or the SFTP server.

If you are deploying through Chrome store whitelisting, your users will automatically receive the newest version. IMPORTANT: please pay attention to the “Preparing your users” section below to see what unexpected outcomes might occur.

Preparing your users

This version includes an improved rules engine as the default rules engine.  This new engine is not guaranteed to be backward compatible with the old API and the results it generates are also different. However, Attest users can control when they start taking advantage of the improvements in the new engine.

Please have Attest users read the “Selecting your Rules Engine” section below if you have any of the following scenarios:

  1. You use WorldSpace Comply or WorldSpace Assure and want WorldSpace Attest HTML version 2.0 to produce the same results as the other products in the WorldSpace Suite.
  2. You have automated tests that use the Attest API but your don’t want their behavior to change when you upgrade to Attest HTML 2.0.
  3. You have added custom rules and have not yet upgraded these to the new rules engine

New Feature Details

Codeless Testing – AGet

If your teams are moving towards continuous integration and would like to integrate accessibility testing into their build but do not yet have a lot of automated tests – they are a perfect candidate for the codeless testing solution AGet.


  1. Builds are deployed to a test environment for integration testing
  2. There is a continuous integration environment like Jenkins that can access the test environment, or the team is able to execute a command line (CLI) application to access the test environment

How AGet Works

AGet is a command line interface (CLI) that can be easily integrated into a development build system like Jenkins to run tests against a test environment. It takes a configuration file which can be a mixture of:

  1. URLs on the application to test, and/or
  2. Natural language scripts (AGet Actions) describing how to exercise the application’s functionality and when to analyze the application’s UI

The following code is an example of an AGet Action to login to the Deque University application and analyze the home page:

Once this configuration is in place, you simply call the command line to execute the accessibility tests in the context of the action script

See the AGet CLI documentation on Deque University

Selecting your Rules Engine

There are two reasons your users might want to choose a specific rules engine version:

  1. Newer rules engines introduce new or changed rules that find new issues, perhaps causing a build to break and the team needs to plan time to address those issues, and/or
  2. You are using a different rules version in another product and you want consistent results

Choosing a particular version through the APIs

Each API has a documented way of doing this. Here is an example from the Attest Java API

The magic line of code is:

This instructs the Attest engine to use a specific rules engine file rather than the default one that is bundled with the latest version.

For instructions on how to do this for each of the APIs, please visit the Deque University product pages.

  1. Attest JS:
  2. Attest Java:
  3. Attest Ruby:

Choosing a particular version in the browser extension(s)

If you are using a WorldSpace Comply (WSC) server, your users can authenticate with the WSC server, select a project and the extension will automatically use the rules engine version configured for that project. The WSC documentation shows how to configure the rules for a project and how to configure WSC to use a particular standard by default.

If you are not using a WSC server, your users can take advantage of the Attest 2.0 extension’s new user interface feature for choosing the rules engine version.

Screenshot of Attest Extension with Ruleset selector option.

To do this, a user can follow the steps below:

  1. Go to the “Rules” panel
  2. From the “axe vX.Y.Z” dropdown, select the appropriate version

For more information, see

Improved Reference Documentation

The WorldSpace Attest HTML 2.0 documentation has been significantly improved in many ways:

  1. We have added use cases to help your users figure out which technology to use to solve their specific problem.
  2. We have added documentation on the AGet codeless testing feature
  3. We have added significantly better documentation on custom rule sets and how to use them

Contacting Us

As with all of our products, if there are missing use cases, examples, or incorrect information in our documentation, please report these to us through

If you have feedback on the usability or experience of our products, please contact us at

If you need help with upgrading or planning your upgrade please contact your Deque engagement manager, or

If you have problems with your upgrade, please contact us at

update selasa

Comments 2 responses

  1. What exactly is the breaking change with Attest-node in 2.0? What else should node users review before updating?

  2. @PPI – Regarding upgrading from attest-node 1.0 to 2.0:

    In attest-node version 1.0, the imported module is a function that creates the Attest API object. This object contains a method for creating a reporter. In version 2.0, the imported module is an object with two methods: one that creates the Attest API object and one that creates a reporter.

    When upgrading from v1.0 to v2.0, you’ll need to take two important steps:

    1. Find places where the imported module is called as a function and instead call the buildAttestSource method of the imported module. In other words, change attestNode(‘wcag2’) to attestNode.buildAttestSource(‘wcag2’).

    2. Find report() method calls and make sure they are made as members of the imported module instead of the built Attest API object (see the code example above).

    Please let us know if you have any other questions!

Leave a Reply

Your email address will not be published. Required fields are marked *