Wir stellen vor: axe™ 2.1.7

Marcy Sutton

By Marcy Sutton

December 22, 2016

We recently released an update to our open source JavaScript accessibility testing engine, axe-core version 2.1.7. This release comes with an axe: the accessibility engine logoupdate to our free Chrom extension (Firefox coming soon), as well as updates to our open source modules axe-webdriverjs und react-axe.

Here are some highlights of the code changes included in this release, as noted in our Changelog:

Add promise-based axe.run API method in favor of axe.a11yCheck

We added a new audit method, axe.run(), and deprecated axe.a11yCheck() The main benefit of axe.run() is the use of the Promises API for asynchronous execution of accessibility audits, making it possible to bubble up JavaScript errors. This also makes debugging iframes easier.

The basic function signature for axe.run() is nearly identical to axe.a11yCheck(), except for one new callback argument for error handling: err, which will either be null or return an Error object. If you do not provide a callback function, axe.run() will return a promise, which you can use for resolving or rejecting results asynchronously.

Basic usage:

axe.run(context, options, function(err, results) {
    if (err) throw err;
    // do stuff with results
});

Promise chain usage:

axe.run(context, options)
    .then(resolve)
    .catch(reject);

We’ll eventually remove the deprecated axe.a11yCheck() method from a future release, so now is the time to migrate to axe.run().

Color contrast rule performance improvements with elementsFromPoint

The color contrast rule updates in this release improve the speed of axe-core 8x when that rule is enabled. We changed part of our implementation to utilizes dom.elementsFromPoint browser method, currently supported in Chrome, Firefox, and Internet Explorer (we have a polyfill for other browsers). It also makes use of the promise chain introduced in axe.run, further improving performance by yielding to the main thread on nearly every tick. Paul Irish and the Lighthouse team were thrilled!

Add Inapplicable and Incomplete (Can’t Tell) results

axe notably does not include warnings in audit results to minimize false positives. However, in this release, we introduced the concept of Inapplicable and Incomplete items for audits that do not strictly fit into Violation or Pass results. These new results can only currently be utilized with axe-core or axe-webdriverjs, and not with our Chrome or Firefox extensions (stay tuned for updates to that soon).

  • Inapplicable results include a list of the axe rules that did not apply in an audit. For example, if a webpage does not include a video, video rules will go into the inapplicable list.
  • Incomplete results occur when axe can tell that a rule does not definitely pass, but cannot quite tell whether it definitely fails – in this case, it will gather some information that can be presented to a human for a decision. An example of an incomplete result is the color contrast of text over background images or gradients, which are extremely difficult to audit with automated tools without generating false positives.

New rule: frame-title-unique

We added a rule to check iframe title attributes for uniqueness, so there are not duplicate names listed in a screen reader elements list.

Improvements to rules: td-has-header, th-has-data-cells

In addition to other various rule improvements, we changed how axe checks table headers for data, as well as reducing false positives of row and colspan attributes on table cells.

Add better support for implicit roles

axe rules now have better support for implicit roles according to the HTML5 spec, such as input[type="reset"], input[type="submit"], summary, td, th, footer, dd, dl, dt, form, <code”>table, optgroup, option, main, math, nav, and more. With these changes, every current implicit role is accurately handled by the axe engine.

Move TypeScript definition to root of project

axe can be used in TypeScript and Angular projects with our TypeScript definition file, now included at the root of the project instead of the typings directory. Read more about using axe with TypeScript.


Get involved

To check out the latest axe-core features or to report issues, find us on Github. You can also join us in San Diego for the axe Hackathon at CSUN 2017!

Marcy Sutton

Marcy Sutton

Marcy ist Developer Advocate bei Deque Systems. Außerdem ist sie Mitglied des #axeCore-Teams, Organisatorin des @a11ySea-Meetups und begeisterte Bergsteigerin.

Erhalten Sie Blog-Beiträge direkt in Ihren Posteingang

Kein Geschwafel, sondern echte Erkenntnisse zum Thema Barrierefreiheit von qualifizierten Experten.

Sie erklären sich damit einverstanden, dass Deque Informationen gemäß den Bestimmungen in DequeDatenschutzerklärungbeschrieben, Informationen von Deque entgegennimmt, nutzt und weitergibt. Sie können Ihre Einwilligung jederzeit widerrufen, indem Sie uns kontaktieren.

Mehr zu diesem Thema

Testen Sie Ihre benutzerdefinierten Elemente und verlassen Sie sich auf die Ergebnisse – dank der Unterstützung von „ElementInternals“ durch Axe-core

Wilco Fiers 400 × 400 1 300 × 300
27. August 2026 Von Wilco Fiers

Wenn Sie ein großes Unternehmen sind, das aufgrund von Interoperabilitätsproblemen mit Barrierefreiheitsproblemen zu kämpfen hat, ist die Umstellung auf ElementInternals ein kluger Schachzug. Sie können standardisieren und sicher testen. Und da „ Axe-core “ nun ElementInternals unterstützt, können Sie diese Komponenten testen und sich auf die Ergebnisse verlassen.

Artikel lesen
Ein Testablauf, der eine einzelne benutzerdefinierte Schaltfläche veranschaulicht, die von „ Axe-core “ für die Frameworks React, Angular oder Vue erfasst wird

Deque und Microsoft: Zwei Jahrzehnte, in denen wir die Zukunft der Barrierefreiheit geprägt haben

beschnittenes Bild „preety kumar400x400 300x300 1 1.jpg“
25. August 2026 Von Preety Kumar

Was vor fast zwei Jahrzehnten als Austausch zwischen zwei Menschen begann, die sich leidenschaftlich für die Verbesserung der Barrierefreiheit in den digitalen Angeboten von Microsoft einsetzten, hat sich zu einer dauerhaften Partnerschaft entwickelt, die auf gemeinsamem Lernen, gegenseitigem Respekt und der gemeinsamen Überzeugung basiert, dass Barrierefreiheit in jeder Phase der Softwareentwicklung berücksichtigt werden sollte.

Artikel lesen
Preety Kumar und Jenny Lay-Flurrie führen ein Interview, im Hintergrund ist die Skyline von Seattle zu sehen.