Bei der Barrierefreiheit im Web geht es darum, Websites und Anwendungen so zu gestalten, dass sie von allen genutzt werden können, insbesondere von Menschen mit Behinderungen. Angesichts der Vielzahl konkurrierender Prioritäten bei der Webentwicklung – von Barrierefreiheit über Leistung bis hin zur Sicherheit – ist es sinnvoll, Teile des Prozesses zu automatisieren. Manuelle Tests sind für die Barrierefreiheit zwar unverzichtbar, doch ein gewisser Teil des Aufwands kann und sollte in die Automatisierung fließen, um personelle Ressourcen für komplexere oder differenziertere Aufgaben freizusetzen.
Automatisierte Tests sind eine hervorragende Möglichkeit, Barrierefreiheit schrittweise in Ihre Website zu integrieren, mit dem Ziel,den Fokusimmerstärkerauf den UX- und Erkundungsprozesszu verlagern. Automatisierte Tests können zwar keineswegs alle Probleme aufdecken, sind jedoch ein wertvolles Mittel, um einfache Verbesserungen umzusetzen und grundlegende Fehler zu vermeiden. Integrieren Sie Barrierefreiheit in Ihren UI-Code, dokumentieren Sie Funktionen für Ihre Teams und verhindern Sie im Idealfall Qualitätsverschlechterungen bei der Bereitstellung in der Produktion.
In diesem Beitrag werden wir die Stärken und Schwächen automatisierter Tests zur Barrierefreiheit im Web beleuchten, um sowohl Ihren Arbeitsablauf zu optimieren als auch Menschen mit Behinderungen zu unterstützen.
Menschen für komplexere Aufgaben entlasten
Viele Probleme im Bereich Barrierefreiheit und Benutzerfreundlichkeit erfordern manuelle Tests durch einen Entwickler oder einen Mitarbeiter der Qualitätssicherung, während andere automatisiert werden können. Letztendlich hängt es von der Art des Projekts ab, welche automatisierten Tests Sie erstellen: Handelt es sich um eine wiederverwendbare Musterbibliothek oder um eine trendige Marketing-Website? Eine Musterbibliothek würde von einer Reihe automatisierter Tests profitieren, von Unit- bis hin zu Regressionstests; eine trendige Marketing-Website kann schon froh sein, wenn überhaupt Tests durchgeführt werden.
Bei der Entscheidung, welche Tests automatisiert werden sollen, ist es hilfreich, sich auf die Grundlagen in den zentralen Benutzerabläufen zu konzentrieren. Meiner Meinung nach ist Barrierefreiheit eine Grundvoraussetzung jeder Benutzeroberfläche – warum also nicht auch dafür eine Testabdeckung sicherstellen? Sie können das Testen der Tastaturbedienbarkeit und der barrierefreien Komponentenfunktionen mit Ihrer eigenen Testlogik automatisieren und zusätzliche Tests mithilfe einer Barrierefreiheits-API für Aspekte wie Farbkontrast, Beschriftungen und die Verwendung von ARIA-Attributen hinzufügen.
Betrachten Sie es einmal so: Können Sie sich die Zeit nehmen, alles in Ihrer Anwendung manuell zu testen? Irgendwann wird es kostentechnisch und zeitlich unzumutbar, alles von Hand zu testen, und Automatisierung wird zur Notwendigkeit. Es geht darum, den richtigen Mittelweg zu finden – mit einer gezielten Testabdeckung, die weiterhin einen Mehrwert und eine gute Kapitalrendite bietet.
Unit, Integration, End-to-End – was soll das denn?
Es gibt viele verschiedene Arten von automatisierten Tests, doch zwei Schlüsselbereiche für die Barrierefreiheit in der Webentwicklung sind Unit- und Integrationstests. Beides sind an sich bereits umfangreiche Themen, doch der Grundgedanke besteht darin, dass ein Unit-Test einen isolierten Teil eines Systems ohne externe Abhängigkeiten (Datenbanken, Dienste oder Netzwerkaufrufe) abdeckt. Integrationstests decken einen größeren Teil des Systems in seiner Gesamtheit ab und decken möglicherweise Fehler auf, die bei der Kombination mehrerer Einheiten auftreten. End-to-End-Tests sind eine Art von Integrationstests, die potenziell noch umfassender sind, um die Erfahrung eines echten Nutzers nachzubilden – daher werden sie auch im Zusammenhang mit Barrierefreiheit erwähnt.
Im Bereich der Barrierefreiheit decken Unit-Tests in der Regel die zugrunde liegenden APIs ab, die Informationen zur Barrierefreiheit oder Interaktionen an die richtige Stelle weiterleiten. Sie sollten APIs isoliert testen und ihre Methoden mit simulierten Daten, sogenannten „Inputs“, aufrufen. Anschließend können Sie überprüfen, ob diese Methodenaufrufe die Anwendung oder deren Zustand wie erwartet verändern.
it('should pass aria-label to the inner button', inject(function() {
var template = '<custom-button label="Squishy Face"></custom-button>';
var compiledElement = make(template);
expect(compiledElement.find('button').attr('aria-label')).toEqual('Squishy Face');
}));
Sie können isolierte UI-Komponenten zusätzlich zu den zugrunde liegenden APIs auf Barrierefreiheit unit-testen, sollten jedoch beachten, dass einige DOM-Funktionen in dem von Ihnen gewählten Test-Framework möglicherweise nicht zuverlässig funktionieren (wie z. B. document.activeElementoder CSS :focus). Integrationstests hingegen können die meisten Aspekte abdecken, die im Hinblick auf die Barrierefreiheit automatisiert werden können, wie beispielsweise Tastaturinteraktionen.
Es ist hilfreich, über eine Reihe von Unit- und Integrationstests zu verfügen, um Regressionen – also fehlerhaften Code, der in die Produktion gelangt – bei Codeänderungen zu minimieren. Damit Tests sinnvoll sind, sollten sie zielgerichtet sein: Man sollte keine Tests nur um der Tests willen schreiben. Es lohnt sich, wichtige Benutzerabläufe und Interaktionen zu analysieren und deren Qualität in Ihrer Anwendung mithilfe automatisierter Tests sicherzustellen.
Veraltete Tests vermeiden
Egal, welche Art von Test Sie schreiben: Konzentrieren Sie sich auf das Ergebnis, nicht auf die Umsetzung. Es kann sehr leicht passieren, dass Tests während der Entwicklung auskommentiert oder entfernt werden, wenn sie bei jeder Codeänderung fehlschlagen. Dies ist bei automatisierten Barrierefreiheitstests umso wahrscheinlicher, da Ihre Kollegen diese möglicherweise nicht so gut verstehen oder ihnen nicht dieselbe Bedeutung beimessen wie Sie.
Um veraltete Tests zu vermeiden, stellen Sie sicher, dass der Aufruf einer API-Methode das erwartete Ergebnis liefert,ohnederen Abhängigkeiten oder interne Details zu testen, die sich im Laufe der Zeit ändern können. Sie können API-Methoden direkt in Unit-Tests aufrufen (z. B. „Bei dieser Eingabe gibt die Methode X zurück“) oder indirekt über simulierte Benutzerinteraktionen in Integrationstests (z. B. „Der Benutzer drückt die Eingabetaste im Widget, und es passiert X“). Das Testen von Ergebnissen anstelle von Implementierungen erleichtert die Refaktorisierung – ein Gewinn für das gesamte Team!
Egal, welche Art von Test Sie schreiben – konzentrieren Sie sich auf das Ergebnis, nicht auf die Umsetzung.
In der Praxis kann es schwierig sein, UI-Tests zu pflegen, wenn viele Designänderungen vorgenommen werden – das ist oft der Grund, warum oft davon abgeraten wird, solche Tests zu schreiben. Aber irgendwann sollten Sie die Barrierefreiheit fest integrieren, damit Sie nicht alles manuell testen müssen. Indem Sie sich auf das gewünschte Ergebnis für eine bestimmte Komponente oder Interaktion konzentrieren, können Sie hoffentlich den Aufwand minimieren und eine gute Rendite für Ihre automatisierte Testsuite erzielen. Außerdem könntet ihr so verhindern, dass Kollegen oder ihr selbst versehentlich die Barrierefreiheit beeinträchtigen, ohne es zu merken.
Wenn du mehr über „Testing Fu“ erfahren möchtest, schau dir diesenVortrag von Justin Searlsan, in dem es darum geht, wie du aufhörst, deine Tests zu hassen.
Tastaturtests und Fokusverwaltung
Grundsätzlich würde ich als erstes Tool zum Testen der Barrierefreiheit die Tastatur empfehlen. Navigieren Sie mit der Tabulatortaste durch die Seite, um zu prüfen, ob Sie interaktive UI-Steuerelemente ohne Maus erreichen und bedienen können. Können Sie erkennen, wo sich der Fokus auf dem Bildschirm befindet? Können Sie ausschließlich mit der Tastatur ein modales Fenster über dem Inhalt öffnen, mit den darin enthaltenen Inhalten interagieren und nach dem Schließen problemlos fortfahren? Dies sind entscheidende Interaktionen für jemanden, der keine Maus benutzen oder den Bildschirm nicht sehen kann.
Die Tastatur ist zwar ein praktisches Werkzeug für manuelle Tests, doch lässt sich die Überprüfung der Tastaturbedienbarkeit einer Benutzeroberfläche auch automatisieren. Bei interaktiven Widgets wie Registerkarten-Umschaltern und Modalen können Tests sicherstellen, dass die Funktionalität über die Tastatur (und in vielen Fällen auch über Screenreader) funktioniert. Sie könnten beispielsweise Tests schreiben, die überprüfen, ob die Escape-Taste ein Modalfenster schließt und den Fokus verwaltet oder ob die Pfeiltasten in einem Menü im Desktop-Stil funktionieren. Dies sind hervorragende Tests, die Sie in Ihre Anwendung integrieren sollten, um sicherzustellen, dass sie auch nach zahlreichen Codeänderungen noch funktionieren.
Schwerpunkt: Unit-Tests
Es ist umstritten, ob ein Unit-Test den tatsächlichen Fokus im DOM überprüfen sollte, wie zum Beispiel document.activeElement was ein zu erwartendes Element ist. Tools für Unit-Tests scheitern häufig bei dieser Aufgabe, und am Ende jagen Sie Fehler im Zusammenhang mit Ihrem Test-Harness hinterher, anstatt nützliche Testfälle zu schreiben.
Sie können es mit einem Tool wieSimulant versuchen, solange der Tastaturfokus innerhalb einer einzigen Einheit getestet wird, beispielsweise innerhalb einer isolierten Komponente. In diesem Fall nur zu (und lassen Sie mich wissen, für welche Tools Sie sich letztendlich entscheiden)! Oft lässt sich der Tastaturfokus jedoch besser im Integrationskontext testen, sowohl wegen der einfacheren Handhabung der Tools als auch weil der Fokus eines Benutzers häufig zwischen mehreren Komponenten wechselt (und somit die Grenzen einer einzelnen Code-Einheit überschreitet).
Anstatt Interaktionen in Unit-Tests zu prüfen und ein ausgewähltes Element zu erwarten, können Sie Unit-Tests schreiben, die entsprechende API-Methoden mit statischen Eingaben aufrufen, beispielsweise Zustandsvariablen oder HTML-Fragmente. Anschließend können Sie überprüfen, ob diese Methoden aufgerufen wurden und sich der Zustand entsprechend geändert hat.
Hier ist ein Beispiel für einen Unit-Test für eine Focus-Manager-API aus David Clarks„React-Menu-button“:
it('Manager#openMenu focusing in menu', function() {
var manager = createManagerWithMockedElements();
manager.openMenu({ focusMenu: true });
expect(manager.isOpen).toBe(true);
expect(manager.menu.setState).toHaveBeenCalledTimes(1);
expect(manager.menu.setState.mock.calls[0]).toEqual([{ isOpen: true }]);
expect(manager.button.setState).toHaveBeenCalledTimes(1);
expect(manager.button.setState.mock.calls[0]).toEqual([{ menuOpen: true }]);
return new Promise(function(resolve) {
setTimeout(function() {
expect(manager.focusItem).toHaveBeenCalledTimes(1);
expect(manager.focusItem.mock.calls[0]).toEqual([0]);
resolve();
}, 0);
});
});
Im Gegensatz dazu wird im obigen Unit-Test zwar überprüft, ob eine Focus-Manager-API aufgerufen wurde, ein Integrationstest für das Fokusmanagement könnte jedoch den Fokus eines tatsächlichen DOM-Elements überprüfen.
Hier ist ein Beispiel für einen Integrationstest (End-to-End) aus Googles„howto-components“:
it('should focus the next tab on [arrow right]', async function() {
const found = await helper.pressKeyUntil(this.driver, Key.TAB,
_ => document.activeElement.getAttribute('role') === 'tab'
);
expect(found).to.be.true;
await this.driver.executeScript(_ => {
window.firstTab = document.querySelector('[role="tablist"] > [role="tab"]:nth-of-type(1)');
window.secondTab = document.querySelector('[role="tablist"] > [role="tab"]:nth-of-type(2)');
});
await this.driver.actions().sendKeys(Key.ARROW_RIGHT).perform();
const focusedSecondTab = await this.driver.executeScript(_ =>
window.secondTab === document.activeElement
);
expect(focusedSecondTab).to.be.true;
});
Für jeden Teil Ihrer App, der durch Hover, Mausklick oder Berührung gesteuert werden kann, sollten Sie überlegen, wie ein Nutzer, der eine Tastatur oder einen Screenreader verwendet, dasselbe Endziel erreichen könnte. Nehmen Sie dies anschließend in Ihre Tests auf.
Natürlich hängt die Kombination aus Unit- und Integrationstests, die Sie schreiben, letztendlich von Ihrer Anwendung ab. Die Tastaturunterstützung sollten Sie jedoch auf jeden Fall in Ihren automatisierten Tests abdecken, da Sie wissen, wie die App in dieser Hinsicht funktionieren sollte. Das bringt uns zu folgendem Punkt:
Testen mit der Barrierefreiheits-API „ axe-core “
Neben den benutzerdefinierten automatisierten Tests Ihrer App ist die Einbindung einer API für Barrierefreiheitstests von großem Nutzen. Das Schreiben der Logik und des Boilerplate-Codes für bestimmte Tests zur Barrierefreiheit kann mühsam und fehleranfällig sein, weshalb es hilfreich ist, einen Teil der Arbeit an Experten auszulagern. Es gibt mehrere APIs in diesem Bereich, aber mein persönlicher Favorit (und das Projekt, an dem ich mich vollzeitlich engagiere) ist die Bibliothek von Deque axe-core . Sie ist in Lighthouse für Google Chrome, Sonarwhal vom Microsoft Edge-Team, Ember A11y Testing, Storybook, Intern, Protractor, DAISYund weiteren Projekten integriert.
Es ist wirklich hilfreich, mithilfe einer API Aspekte wie Farbkontrast, Datentabellen, die Korrektheit von ARIA-Attributen und grundlegende HTML-Semantik zu testen, die man vielleicht vergessen hat. Das Team von „ axe-core “ hält die Unterstützung für verschiedene Entwicklungstechniken in assistiven Technologien stets auf dem neuesten Stand, sodass Sie diese Arbeit nicht selbst erledigen müssen – wir bezeichnen dies als „unterstützte Barrierefreiheit“. Sie können sich darauf verlassen, dass die Testergebnisse auch Browser und Screenreader abdecken, die Sie vielleicht nicht täglich testen, sodass Sie Zeit für andere Aufgaben gewinnen.
Sie können die axe.run() API-Methode auf verschiedene Arten: Isolieren Sie die Barrierefreiheitsregeln für eine einzelne Komponente mit der context Option, beispielsweise in einem Unit-Test. Oder führen Sie den gesamten Regelsatz in einem Integrationstest auf Seitenebene auf ein Dokument an. Sie können sich auch die axe-webdriverjs Integration, die im Gegensatz zu axe-core automatisch in Iframes eingebunden wird. Hinweis: Sie können auch die aXe-Browsererweiterungen für Chrom und Firefoxum einen kurzen manuellen Test mit demselben Regelsatz durchzuführen, einschließlich Iframes.
Hier ist ein einfaches Beispiel für die Verwendungvon „axe-core “ in einem Unit-Test:
var axe = require('axe-core');
describe('Some component', function() {
it('should have no accessibility violations', function(done) {
axe.run('.some-component', {}, function(error, results) {
if (error) return error;
expect(results.violations.length).toBe(0);
});
});
});
Im Gegensatz dazu gibt es hier einenAxe-WebDriverJS-Integrationstest, der eher auf Seitenebene ansetzt, was bei der Ausführung vieler Tests manchmal leistungsstärker ist:
var AxeBuilder = require('axe-webdriverjs'),
Webdriver = require('selenium-webdriver');
describe('Some page', function() {
it('should have no accessibility violations', function(done) {
var driver = new Webdriver.Builder().forBrowser('chrome').build();
driver.get('http://localhost:3333')
.then(function(done) {
AxeBuilder(driver)
.analyze(function(results) {
expect(results.violations.length).toBe(0);
done();
});
});
});
});
Bei beiden Tests wird Ihnen ein JSON-Objekt zurückgegeben, das alle von „ axe-core “ gefundenen Elemente enthält: Arrays mit bestandenen Prüfungen, Verstößen und sogar eine Reihe von „unvollständigen“ Elementen, die einer manuellen Überprüfung bedürfen. Sie können Assertions basierend auf der Anzahl der Verstöße schreiben, was hilfreich ist, um Builds lokal oder in der Continuous Integration (CI) zu blockieren.
Es ist wichtig, für jeden Zustand der Seite mehrere Tests zu schreiben, einschließlich des Öffnens von Modalfenstern, Menüs und anderen ausgeblendeten Bereichen, die sonst von der API übersprungen werden. Dadurch wird sichergestellt, dass Sie jeden Zustand der Seite auf Barrierefreiheit prüfen, da ein automatisiertes Tool Ihre Absicht nicht erraten kann, wenn Elemente mit display: none oder beim Öffnen dynamisch eingefügt.
Weitere Informationen finden Sie in der axe-core API-Dokumentation zu aXe undaXe-WebDriverJSeinsehen, um mehr über alle Konfigurationsoptionen zu erfahren – von der Deaktivierung bestimmter Regeln über das Ein- und Ausschließen bestimmter Teile des DOM bis hin zum Hinzufügen eigener benutzerdefinierter Regeln. Diekommende Version 3.0 von axe-coreunterstützt zudem Shadow DOM, das Sie mit einer Vorabversion der API oder in der kostenlosenErweiterung aXe Coconut nutzen können.
Weitere Integrationen und Ressourcen finden Sie auf der Website „ axe-core “:https://axe-core.org
Manuelle Tests und Benutzertests
Es ist wichtig, noch einmal zu betonen, dass automatisierte Tests in Bezug auf die Barrierefreiheit nur bis zu einem gewissen Grad ausreichen. Sie sind kein Ersatz für manuelle Tests mit der Tastatur und Bildschirmleseprogrammen, auch auf mobilen Geräten. Einige dieser Szenarien lassen sich zudem überhaupt nicht automatisieren.
Mit manuellen Tests und Ihren automatisierten Tests können Sie die Grundlagen abdecken. Um jedoch festzustellen, ob Ihre App tatsächlich für Menschen nutzbar ist, sind Nutzertests erforderlich. Es gibt einen Grund, warum aktuelle Initiativen wie der ACAA (Air Carrier Access Act) Nutzertests als Teil ihrer Abhilfemaßnahmen vorschreiben.
Sobald sich Ihr digitales Erlebnis etwas stabilisiert hat, ist es äußerst wichtig, Nutzertests mit echten Menschen durchzuführen, darunter auch Menschen mit Behinderungen. Eine Ausnahme könnte die Prototyping-Phase darstellen, in der Sie Feedback von Nutzern einholen möchten, bevor Sie sich für eine endgültige Lösung entscheiden. In beiden Fällen können Organisationen wieAccess WorksIhnen dabei helfen, Nutzer für die Tests zu finden. Sie sollten auchFern-Testsin Betracht ziehen, um den größtmöglichen Nutzen aus Ihren Bemühungen zu ziehen.
Zusammenfassung
Automatisierte Tests können dazu beitragen, Ihr Team von der manuellen Prüfung jedes einzelnen Teils Ihrer App oder Website zu entlasten. Ab einem bestimmten Punkt sind automatisierte Tests effizienter, als alles von Menschen erledigen zu lassen. Indem Sie Ihre Teststrategie bewusst gestalten und die Barrierefreiheit in die Testabdeckung einbeziehen, können Sie den Mitgliedern Ihres Teams die Codequalität verdeutlichen und möglicherweise verhindern, dass Regressionen in die Produktionsumgebung gelangen.
Wertvolle automatisierte Tests überprüfen Tastaturinteraktionen, die Barrierefreiheit der API-Infrastruktur sowie die Nutzung von Barrierefreiheits-Test-APIs wie axe-core , um Ihnen das Schreiben von Boilerplate-Code zu ersparen, bei dem leicht Fehler unterlaufen können. Allerdings sind automatisierte Tests kein Ersatz für regelmäßige manuelle Tests durch Sie selbst und für Testsmit echten Nutzern. Ein ausgewogener, ganzheitlicher Testansatz ist der beste Weg, um sicherzustellen, dass die Qualität in allen Phasen des Prozesses gewahrt bleibt.
Zögert nicht, michauf Twitteranzusprechen, wenn ihr Fragen habt oder einen anderen Ansatz verfolgt! Ich würde mich sehr freuen zu erfahren, was bei euch gut funktioniert.
Wie meine Kollegin Glenda Sims gerne sagt: „Auf A11y und darüber hinaus!“
