Axe-core 3.2 is coming soon

The first axe release of 2019 is nearly here! We’re introducing some new rules, enhanced reporting capabilities and a variety of bug fixes. We are very excited to be able to share all of these new features with our users. We have big plans for axe-core this year, and axe-core 3.2 sets us up strong and ready for another excellent year of accessibility. We will be updating all axe and Attest HTML tools over the month of March to include axe-core version 3.2. For how this release affects other Deque tools, please contact your account representative for more information.

New Rules

Rule 1:<aria-label>; values match the content of widgets

This new WCAG 2.1-based rule is specifically designed to support users of dictation software. By ensuring that the text that is visible on the screen matches the accessible name, dictation software knows what buttons, links and other widgets with “name from content” to activate.

Failure Example:

<a href=”page2.html” aria-label=”Page 2”>Next ?</a>

Passing Example:

<a href=”page2.html” aria-label=”Next page”>Next ?</a>

Rule 2: Form fields do not have duplicate labels

This rule was taken out of the form field labels rule and turned into a separate best practice rule. A common mistake when marking up forms is that authors accidentally assign two labels to a single form field. Intentionally assigning multiple labels is not a common practice; it creates code that is difficult to maintain.

Failure Example:

<label class="sr-only" for="nmr">Number of products</label>

<label><input type="text" id="nmr" /> pizza’s</label>

Passing Example:

<input type="text" id="nmr" aria-label="number of pizza's" /> pizza's

Rule 3: Complementary landmarks are at the top level

This best practice rule ensures that aside elements or elements with role=complementary are not an internal part  of another ARIA landmark. Nesting landmarks create confusing document structures. This rule is similar to existing rules that test this same ARIA requirement for the banner, contentinfo, and main roles.

Failure Example:

<main>

<p>Some text</p>

<aside><p>An aside</p></aside>

</main>

Passing Example:

<main><p>Some text</p></main>

<aside>An aside</aside>

Other New Features

Feature 1: Test environment details included in analysis results

A common question when using axe-core, and indeed most accessibility testing tools is that it can be challenging to reproduce specific issues. Why were there no issues yesterday, but when I run axe today, do I get 5 issues? Almost always the answer is one of the following:

1. The page has changed.
2. Axe-core has updated, or its configuration is different.
3. The browser setup is different.

While axe cannot tell you if the page has changed, as of version 3.2, the axe-core analysis includes information in its results enabling you to work out all of the other variables. Axe-core now reports the following properties:

• Test engine:
  • name: axe-core
  • version: 3.2.0
• Test runner:
  • name: The test runner used in the analysis (e.g.,: Axe Devtools Chrome, Axe CLI)
• Test environment:
  • Window width & height: Used to indicate which media queries were applied
  • User Agent: The browser, browser version, and operating system used in analysis
  • Orientation angle & type: If available, axe-core reports the screen rotation

Once these properties are available in axe-core, we add the individual properties into the different axe-core test runners and reporters.

Feature 2: More granular accessibility support feedback

In axe-core 3.1 we started individually notifying users when they were using roles that were not widely supported by assistive technologies. This allows users to distinguish mistyped / non-existing roles from roles less widely supported. Axe-core 3.2 now also reports such issues for ARIA properties and states that are less supported. Less supported ARIA properties include the following attributes:

• aria-details
• aria-roledescription
• aria-describedat (non-standard)

Feature 3: New accessible name computation

A key component to axe-core is its accessible name computation algorithm. It is used to determine how screen readers and other assistive technologies name the various headings, links, and other components on a page. Late last year, the W3C published version 1.1 of the Accessible Name Computation. We took that opportunity to rebuild our implementation not just to give a reasonable indication of whether or not an element has an accessible name, but to calculate it accurately.

With this new accessible name computation method, tools build on top of axe-core can now accurately represent the most likely accessible name that different browsers give to a component. It is built to find the smallest denominator between Chrome, Firefox, and Safari. Additionally, it can be configured to report the accessible name of a specific browser accurately.

Noteworthy Bug Fixes

• Allow off screen labels for form fields (#1187)
• Allow <div> groups in definition lists (#1284)
• Prevent th-has-data-cells from crashing on empty rows (#1285)
• Prevent TypeErrors in color-contrast checks(#1320)
• Deprecate axe.commons.utils namespace (#1330)

Known Issues

• Axe-core does not work under strict content security policy (#1175)
• Using maximum-scale in viewport meta element should not be flagged as an issue (#694)
• Do not check color contrast of non-printable characters (#315)
• Heading order rule can produce false positives when using context.exclude (#278)
• … see the complete bug list.