Es gibt die Ansicht, dass Barrierefreiheit keine Checkliste ist, was bedeutet, dass man, wenn man wirklich versucht, eine Website barrierefrei zu gestalten, nicht einfach einige Punkte von einer Liste abhaken und sie für perfekt halten kann. Die Liste mag unvollkommen sein und schlimmer noch, sie schließt den Benutzer aus der Gleichung aus, so wird gesagt.
Karl Groves argumentierte einst dagegen
Ich würde argumentieren, dass ein gut dokumentierter Prozess, der bewertungsbasierte Checklisten beinhaltet, besser geeignet ist, um sicherzustellen, dass die Bedürfnisse aller Benutzer erfüllt werden, nicht nur die einiger Benutzer.
Ich erwähne dies, weil Sie ein automatisiertes Werkzeug zum Testen der Barrierefreiheit als eine weitere Form einer Checkliste betrachten könnten. Diese Werkzeuge haben eingebaute Regeln und testen Ihre Website anhand dieser Regeln.
Ich bin ziemlich neu in diesem Bereich, also kein Experte hier, aber es scheint eine ganze Menge Optionen zu geben! Werfen wir einen Blick auf einige davon.
aXe
The Accessibility Engine for automated testing of HTML-based user interfaces. Drop the aXe on your accessibility defects!
aXe kann ein HTML-Dokument analysieren, potenzielle Barrierefreiheitsprobleme finden und sie Ihnen melden. Zum Beispiel gibt es Browser-Erweiterungen (Firefox / Chrome), mit denen Sie einen Bericht über Barrierefreiheitsprobleme auf der von Ihnen betrachteten Seite erstellen können.
Im Grunde ist es ein Skript, so dass es auf vielfältige Weise eingesetzt werden kann. Zum Beispiel könnten Sie dieses Skript in einem Pen laden und diesen Pen auf Barrierefreiheit testen.
Es gibt eine CLI, so dass Sie sie in Build-Prozesse oder Testumgebungen oder Deployment-Flows oder was auch immer integrieren können.
Es sieht so aus, als ob intern-a11y helfen kann, aXe für zusätzliche Funktionalität zu skripten.
Pa11y
Pa11y ist Ihr automatisierter Barrierefreiheitstest-Kumpel. Er führt HTML CodeSniffer von der Kommandozeile aus für programmatische Barrierefreiheitsberichte.
Pa11y ist ein weiteres Werkzeug in dieser Richtung. Es ist ein Skript, das eine URL auf Barrierefreiheitsprobleme testen kann. Sie können es von der Kommandozeile mit einem Dateipfad oder einer URL aufrufen (pa11y http://example.com) und einen Bericht erhalten.
Sowie die Verwendung aus einer Node-Umgebung und die Konfiguration nach Bedarf. Es ist eigentlich absichtlich nur für die programmatische Verwendung gedacht, da es die programmatische Version von HTML_CodeSniffer ist, der Bookmarklet/visuellen Version.
Es gibt auch eine native App-Version namens Koa11y, falls das die Nutzung erleichtert.
Seren Davies schrieb kürzlich über ein bestimmtes Szenario, in dem sie Pa11y gegenüber aXe bevorzugten.
Wir begannen mit der Untersuchung von aXe CLI, merkten aber bald, dass es nicht unseren Anforderungen entsprach. Es konnte keine Seiten überprüfen, die einen Besucher-Login erforderten, sodass wir zwar unsere Produktseiten testen konnten, aber keine Kundenkontoseiten. Stattdessen wechselten wir zu Pa11y. Sein
beforeScript-Schritt bedeutete, dass wir uns in die Seite einloggen und Seiten wie die Bestellhistorie testen konnten.
Google Accessibility Developer Tools
Google ist mit Accessibility Developer Tools ebenfalls im Rennen.
Die Hauptkomponente ist die Zugänglichkeitsprüfung: eine Sammlung von Prüfregeln, die auf häufige Barrierefreiheitsprobleme prüfen, und eine API zum Ausführen dieser Regeln auf einer HTML-Seite.
Es ist ähnlich wie die anderen, da es für die Verwendung auf verschiedene Weise konzipiert ist, z. B. als Grunt-Aufgabe, über die Kommandozeile oder den Browser.
Addy Osmani hat a11y, angetrieben von Chrome Accessibility Tools, das eine schönere API und schönere Berichte zu bieten scheint.
Es scheint jedoch, dass der Großteil des Google-Aufwands für Website-Audits heutzutage auf Lighthouse gelegt wird, das Barrierefreiheitstests beinhaltet. Zum Beispiel der Test „Buttons Have An Accessible Name“, aber dieser Test verwendet tatsächlich aXe im Hintergrund.
Es ist mir nicht klar, ob Lighthouse eine vollständige und aktuelle aXe-Audit durchführt oder nicht, und ob die Accessibility Developer Tools zugunsten dessen irgendwie veraltet sind, oder was.
Automated Accessibility Testing Tool (AATT)
PayPal ist mit AATT ebenfalls im Rennen, einer Kombination und Erweiterung bereits erwähnter Werkzeuge.
Browserbasierte Werkzeuge und Plugins für Barrierefreiheitstests erfordern manuelles Testen jeder Seite, eine nach der anderen. Werkzeuge, die eine Website durchsuchen können, können nur Seiten scannen, die keine Anmeldedaten benötigen und die sich nicht hinter einer Firewall befinden. Anstatt eine separate Testsuite für Barrierefreiheit zu entwickeln, zu testen und zu verwenden, können Sie jetzt Barrierefreiheitstests in Ihre bestehende Automatisierungs-Testsuite integrieren, indem Sie AATT verwenden.
AATT umfasst HTML CodeSniffer, aXe und Chrome Developer Tool mit Express und PhantomJS, die unter Node laufen.
Es startet einen Server mit einer API, die Sie zum Testen von Seiten auf anderen Servern verwenden können.
accessibilityjs
GitHub selbst hat kürzlich accessibilityjs veröffentlicht, das Werkzeug, das sie selbst für Barrierefreiheitstests verwenden. Sie nutzen es auf der Client-Seite, wo es beim Finden eines Fehlers einen großen roten Rahmen anbringt und einen Klick-Handler hinzufügt, damit Sie darauf klicken können, um zu erfahren, was das Problem ist.
Sie beschränken es auf diese häufigen Fehler:
ImageWithoutAltAttributeErrorElementWithoutLabelErrorLinkWithoutLabelOrRoleErrorLabelMissingControlErrorInputMissingLabelErrorButtonWithoutLabelErrorARIAAttributeMissingError
Tenon.io
Tenen.io ist vielleicht das einfachste aller Werkzeuge, um loszulegen, da die Homepage oben einen Validator hat, mit dem Sie HTML kopieren und einfügen oder eine URL einfügen können, um sie zu validieren.
Tenon.io kann 508- und WCAG 2.0-Probleme in jeder Umgebung identifizieren – sogar auf dem Laptop Ihres Entwicklers. Denn die Produktion ist kein guter Ort, um Fehler zu entdecken.
Es gibt eine kostenlose Testversion für 30 Tage / 500 API-Aufrufe, danach ist es ein kostenpflichtiges Produkt.
Tenon.io integriert sich an vielen Stellen. Karl hat mir selbst erzählt:
Wir haben eine CLI. Wir haben Grunt & Gulp Plugins, Node-Module und Plugins für Chrome, Firefox, IE und Opera. PHP-Klassen, Ruby Gems, CMS-Integrationen für WordPress, Drupal usw.
Ehrenwerte Erwähnungen
Ich versuche nicht absichtlich, ein bestimmtes Barrierefreiheitstestwerkzeug hervorzuheben oder zu verstecken. All das ist neu für mich. Es schien nur, dass dies viele der großen Akteure waren. Aber eine Web-Suche enthüllt noch viel mehr!
- Tanaguru: „Automated accessibility (a11y) testing tool, with emphasis on reliablity and automation“
- The A11y Machine „ist ein automatisiertes Barrierefreiheitstestwerkzeug, das Seiten jeder Webanwendung durchsucht und testet, um detaillierte Berichte zu erstellen.“
- tota11y: „ein Visualisierungstoolkit für Barrierefreiheit (a11y)“
Meine Arbeit nutzt den Siteimprove-Dienst zum Scannen von Teilen unserer Website. Sie haben auch ein Chrome-Plugin veröffentlicht, das einen Großteil der gleichen Technologie wie ihr kostenpflichtiger Dienst verwendet. Besonders gefällt mir, dass es die gefundenen Fehler nach dem WCAG-Level (A, AA, AAA) kategorisiert und auf den Teil der Spezifikation verweist, der geprüft wird, und ob es einen tatsächlichen Fehler erkannt hat oder etwas, das manuell überprüft werden sollte. (Denken Sie an „dieses
<img>hat kein alt-Attribut“ vs. „beschreibt das alt-Attribut das Bild ausreichend?“) Sie verlinken auch sowohl auf die Spezifikation als auch auf die WCAG-Seiten zu empfohlenen Techniken zur Einhaltung der Spezifikationen.Noch eine Stimme für die Siteimprove Chrome Extension! Wir haben früher immer Wave benutzt, aber die Siteimprove Chrome Extension ist gründlich und für jeden kostenlos, der sie möchte. Sie hat auch ein modernes Design und Gefühl, was erfrischend ist.
Darf ich die WAVE-Erweiterung erwähnen? https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh
Großartig für eine Vielzahl von a11y-Tests, einschließlich der korrekten Verschachtelung/Reihenfolge der Überschriften.
Noch eine Stimme von mir für das WAVE-Plugin!
Ich mag auch Colorblinding und NoCoffee, um verschiedene Grade und Arten von Sehkraft zu emulieren. Chromevox ist gut zum Üben, um das Web durch Tastaturnavigation und einen Screenreader zu erleben – ich glaube definitiv, dass ich mehr Zeit damit verbringen sollte, zu versuchen, auf diese Weise zu navigieren, um eine bessere Vorstellung davon zu bekommen, wie es wäre, nur auf diese Weise navigieren zu können, was am schwierigsten daran ist, was Seiten auslassen, usw.
Und um die Dinge im richtigen Verhältnis zu sehen, mag ich diese Listen von gov.uk, die verschiedene Sets von Zugänglichkeitsmerkmalen zeigen. Es ist eine gute Erinnerung, dass die Bedürfnisse von Person zu Person variieren und was für den einen barrierefrei ist, ist nicht unbedingt für andere barrierefrei. https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/
Richtig! Barrierefreiheit ist keine Checkliste. Allerdings ermöglichen Ihnen diese Tools, die leicht erreichbaren Früchte (die Tippfehler, die Versehen und so weiter) zu erkennen. Nichtsdestotrotz hat der Mann, den Sie am Anfang des Beitrags zitiert haben (Karl), seine starken Meinungen darüber geäußert, wie man automatisierte Tests nicht durchführt, und Tenon geschrieben: https://tenon.io/
Barrierefrei bedeutet nicht benutzerfreundlich.
Eine Website kann perfekt „barrierefrei“ sein und dennoch ein Albtraum bei der tatsächlichen Nutzung sein.
Wenn wir über Barrierefreiheit sprechen, denken wir meist an unsere blinden Freunde, aber vergessen wir die anderen nicht.
Zoombrowser mögen tiefe Einrückungen normalerweise nicht, da dies zusätzliches Scrollen (/Suchen) bedeutet.
Sehende Nicht-Maus-Benutzer, diese werden die ARIA-Rollen nicht „hören“. Macht es für sie immer noch Sinn? (ARIA-Rolle Tablist kann Verwirrung stiften)
Farbenblindheit, mehr Leute als man denkt haben das. Verwenden Sie Farbe, um einen Status anzuzeigen? (vielleicht das Symbol ändern, um es klarer zu machen)
Funktioniert es trotzdem, wenn sie ihr Handy benutzen, um Ihre Website zu besuchen?
Manchmal kann selbst eine kleine Änderung ihr Leben so viel besser machen. (auch wenn sie sich nicht darüber beschweren)
Zum Beispiel testen die Tools, ob Ihre Bilder ein ALT-Attribut haben, aber alt=„ytfytf“ wird ebenfalls als korrekt markiert.
Navigationspunkte in einer Liste hinzuzufügen ist gut, aber wenn sie nur zwei Elemente enthält, erhalten Sie „Liste, die zwei Elemente enthält, Element eins, Element zwei“. Lohnt sich dieser Overhead oder ist er ärgerlich?
Dasselbe gilt für das Hinzufügen von ARIA-Rollen. Sie erhalten Punkte für das Hinzufügen, aber in Wirklichkeit sollten Sie sie nur hinzufügen, wenn es keinen anderen Weg gibt, mit gängigem HTML.
Diese Tools mögen gut sein, um offensichtliche Fehler zu testen, aber sie sind kein Ersatz für das Testen mit den Leuten, die Ihr Produkt verwenden.
Fragen Sie sie, holen Sie sich all diese (wahrscheinlich) unterschiedlichen Vorlieben und versuchen Sie, daraus ein gutes Ergebnis zu machen :)
Danke für das Posten dieser Tools, automatisierte Tools scheinen die kosteneffizienteste Methode zu sein, um ein bestimmtes Maß an Barrierefreiheit zu gewährleisten... tatsächlich kann ich mir keine Methode vorstellen, die zumindest auf irgendeiner Ebene keine Liste oder einen Satz von Richtlinien beinhaltet.
Danke für den Artikel! Für aXe können Sie mit der axe-webdriverjs-Integration (unter anderem) zusätzliche Funktionalitäten skripten. Das erleichtert Dinge wie die Skripterstellung von Logins und das Testen von Seiten mit Iframes. Die aXe Chrome- und Firefox-Erweiterungen testen auch innerhalb von Iframes.
Es gibt auch eine Vorabversion von axe-core, an der wir arbeiten, die Shadow DOM testet: https://www.deque.com/blog/test-leading-edge-accessibility-axe-coconut-axe-core-3-0/
Gute Liste von Tools hier, noch eine Stimme für das WAVE-Plugin, wie oben erwähnt. Als jemand, der viel für verschiedene Banken arbeitet, die externe Barrierefreiheitsfirmen beauftragen, ist es erwähnenswert, dass ein Großteil dessen, was in den WCAG-Richtlinien enthalten ist, auch eine Frage der persönlichen Vorliebe des Testers ist.
Ich habe die Übersicht verloren, wie oft die Arbeit meines Unternehmens an eine dieser Drittanbieterfirmen ging, nur um mit Empfehlungen zurückzukommen. Sobald die Änderungen implementiert sind, müssen sie erneut getestet werden (normalerweise von einer anderen Person), und sie empfehlen dann, dass wir das tun, was wir ursprünglich getan haben (ohne zu wissen, dass es das ist, was wir ursprünglich getan haben). Es ist oft ein endloser Kreisel aufgrund einiger Richtlinien, die vollständig der persönlichen Interpretation unterliegen. Es ist ehrlich gesagt oft ein Albtraum.
Es ist mir wichtig, diese Technik der Barrierefreiheit in Betracht zu ziehen, um meine Aktivitäten im Zusammenhang mit Websites durchzuführen, die uns bald zur Verfügung gestellt werden. Daher würde ich Sie bitten, die Implementierung voranzutreiben, um unsere Organisation zu erweitern.