Axe-core 3.2 erscheint in Kürze

Die erste „Axe“-Version des Jahres 2019 steht kurz bevor! Wir führen einige neue Regeln, erweiterte Berichtsfunktionen und eine Reihe von Fehlerbehebungen ein. Wir freuen uns sehr, all diese neuen Funktionen mit unseren Nutzern teilen zu können. Wir haben in diesem Jahr große Pläne für „ axe-core “, und „ axe-core “ 3.2 verschafft uns eine solide Ausgangsbasis für ein weiteres hervorragendes Jahr im Bereich Barrierefreiheit. Im Laufe des Monats März werden wir alle „axe“- und „Attest“-HTML-Tools aktualisieren und „ axe-core “ Version 3.2 integrieren. Wenn Sie wissen möchten, wie sich diese Version auf andere „ Deque “-Tools auswirkt, wenden Sie sich bitte an Ihren Kundenbetreuer, um weitere Informationen zu erhalten.

Neue Regeln

Regel 1:<aria-label>; die Werte entsprechen dem Inhalt der Widgets

Diese neue, auf den WCAG 2.1 basierende Regel wurde speziell zur Unterstützung von Nutzern von Diktiersoftware entwickelt. Indem sichergestellt wird, dass der auf dem Bildschirm angezeigte Text mit dem barrierefreien Namen übereinstimmt, weiß die Diktiersoftware, welche Schaltflächen, Links und andere Steuerelemente mit einem „Namen aus dem Inhalt“ aktiviert werden sollen.

Beispiel für einen Fehler:

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

Beispiel für eine Übergabe:

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

Regel 2: Formularfelder dürfen keine doppelten Beschriftungen haben

Diese Regel wurde aus der Regel zu den Beschriftungen von Formularfeldern herausgelöst und in eine eigenständige Best-Practice-Regel umgewandelt. Ein häufiger Fehler beim Auszeichnen von Formularen besteht darin, dass Autoren versehentlich einem einzelnen Formularfeld zwei Beschriftungen zuweisen. Das absichtliche Zuweisen mehrerer Beschriftungen ist keine gängige Praxis; es führt zu Code, der schwer zu warten ist.

Beispiel für einen Fehler:

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

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

Beispiel für eine Übergabe:

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

Regel 3: Ergänzende Orientierungspunkte befinden sich auf der obersten Ebene

Diese Best-Practice-Regel stellt sicher, dass aside Elemente oder Elemente mit role=complementary kein interner Bestandteil eines anderen ARIA-Landmarks sind. Verschachtelte Landmarks führen zu unübersichtlichen Dokumentstrukturen. Diese Regel ähnelt bestehenden Regeln, die dieselbe ARIA-Anforderung für das banner, contentinfo, und main Rollen.

Beispiel für einen Fehler:

<main>

<p>Some text</p>

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

</main>

Beispiel für eine Übergabe:

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

<aside>An aside</aside>

Weitere neue Funktionen

Merkmal 1: In den Analyseergebnissen enthaltene Details zur Testumgebung

Eine häufig gestellte Frage bei der Verwendung von axe-core – und eigentlich bei den meisten Tools zur Barrierefreiheitsprüfung – ist, dass es schwierig sein kann, bestimmte Probleme zu reproduzieren. Warum gab es gestern keine Probleme, aber wenn ich Axe heute ausführe, werden mir 5 Probleme angezeigt? Fast immer lautet die Antwort eine der folgenden:

1. Die Seite hat sich geändert.
2. Axe-core wurde aktualisiert oder die Konfiguration hat sich geändert.
3. Die Browsereinstellungen sind unterschiedlich.

Zwar kann axe Ihnen nicht mitteilen, ob sich die Seite geändert hat, doch enthält die „ axe-core “-Analyse seit Version 3.2 Informationen in den Ergebnissen, anhand derer Sie alle anderen Variablen ermitteln können. „ Axe-core “ meldet nun die folgenden Eigenschaften:

• Test-Engine:
  • Name: axe-core
  • Version: 3.2.0
• Testausführungsprogramm:
  • name: Der bei der Analyse verwendete Test-Runner (z. B.: Axe Devtools Chrome, Axe CLI)
• Testumgebung:
  • Fensterbreite und -höhe: Dient zur Angabe, welche Medienabfragen angewendet wurden
  • User Agent: Der bei der Analyse verwendete Browser, die Browserversion und das Betriebssystem
  • Ausrichtungswinkel und -typ: Sofern verfügbar, meldet „ axe-core “ die Bildschirmdrehung

Sobald diese Eigenschaften in „ axe-core “ verfügbar sind, fügen wir die einzelnen Eigenschaften in die verschiedenen Testausführungs- und Auswertungsprogramme von „ axe-core “ ein.

Funktion 2: Detailliertere Rückmeldungen zur Barrierefreiheitsunterstützung

In „ axe-core “ 3.1 haben wir damit begonnen, Benutzer individuell zu benachrichtigen, wenn sie Rollen verwendeten, die von assistiven Technologien nicht umfassend unterstützt wurden. Dadurch können Benutzer falsch eingegebene oder nicht vorhandene Rollen von Rollen unterscheiden, die weniger umfassend unterstützt werden. „ Axe-core “ 3.2 meldet nun auch solche Probleme bei ARIA-Eigenschaften und -Zuständen, die weniger gut unterstützt werden. Zu den weniger gut unterstützten ARIA-Eigenschaften gehören die folgenden Attribute:

• aria-details
• aria-roledescription
• aria-describedat (nicht standardisiert)

Funktion 3: Neue Berechnung des barrierefreien Namens

Eine zentrale Komponente von „ axe-core “ ist der Algorithmus zur Berechnung barrierefreier Namen. Er dient dazu, festzulegen, wie Screenreader und andere assistive Technologien die verschiedenen Überschriften, Links und sonstigen Elemente auf einer Seite benennen. Ende letzten Jahres veröffentlichte das W3C Version 1.1 des „Accessible Name Computation“. Wir haben diese Gelegenheit genutzt, um unsere Implementierung neu zu gestalten – nicht nur, um einen angemessenen Hinweis darauf zu geben, ob ein Element einen barrierefreien Namen hat oder nicht, sondern um diesen auch genau zu berechnen.

Mit dieser neuen Methode zur Berechnung des barrierefreien Namens können Tools, die auf axe-core basieren, nun den wahrscheinlichsten barrierefreien Namen, den verschiedene Browser einer Komponente zuweisen, genau darstellen. Die Methode wurde entwickelt, um den kleinsten gemeinsamen Nenner zwischen Chrome, Firefox und Safari zu ermitteln. Darüber hinaus lässt sie sich so konfigurieren, dass sie den barrierefreien Namen eines bestimmten Browsers genau angibt.

Wichtige Fehlerbehebungen

• Beschriftungen für Formularfelder außerhalb des Bildschirms zulassen (#1187)
• Allow <div> groups in definition lists (#1284)
• Verhindern, dass „th-has-data-cells“ bei leeren Zeilen abstürzt (#1285)
• Vermeidung von Typfehlern bei der Überprüfung des Farbkontrasts (#1320)
• Den Namensraum „axe.commons.utils“ als veraltet kennzeichnen (#1330)

Bekannte Probleme

• Axe-core funktioniert nicht unter strengen Inhaltssicherheitsrichtlinien (#1175)
• Die Verwendung von „maximum-scale“ im Meta-Element „viewport“ sollte nicht als Problem gemeldet werden (#694)
• Farbkontrast von nicht druckbaren Zeichen nicht prüfen (#315)
• Die Regel zur Reihenfolge der Überschriften kann bei Verwendung von „context.exclude“ zu Fehlalarmen führen (#278)
• … siehe die vollständige Fehlerliste.