Bei eBay nehmen wir die Barrierefreiheit ernst und haben uns dazu verpflichtet, „für alle da zu sein“. Zu diesem Zweck verfügen wir über ein Expertenteam, das unermüdlich daran arbeitet, sicherzustellen, dass unsere Seiten für alle zugänglich sind. Wir sind der festen Überzeugung, dass Barrierefreiheitsprobleme wie Fehler behandelt und mit der gleichen Sorgfalt behoben werden sollten. Daher freuen wir uns, die nächste Weiterentwicklung unserer Open-Source-Frontend-Entwicklungstools bekannt zu geben. Der Barrierefreiheit für Marko Bietet Entwicklern Feedback zur Barrierefreiheit direkt zum Quellcode, ähnlich wie die Rechtschreibprüfung in einem Textverarbeitungsprogramm. Bevor wir auf die Details eingehen, wollen wir einen Kontext dazu liefern, warum dies eine so wichtige Funktion ist.
Geschichte der Barrierefreiheitstests bei eBay
Manuelles Testen
Vor 2014 wurden alle Barrierefreiheitstests manuell durchgeführt. Entwickler und Tester wurden aufgefordert, jede Seite aus der Perspektive eines Bildschirmlesers oder eines Benutzers, der nur die Tastatur bedient, durchzugehen und mögliche Probleme auszukundschaften, etwa Bilder ohne alternativen Text oder Schaltflächen, die nur mit der Tastatur nicht erreicht werden konnten. Dies ist eine effektive Fangmethode offensichtlich Es gibt zwar Probleme mit der Zugänglichkeit, bringt aber auch einige Nachteile mit sich, die schwer in Einklang zu bringen sind.
Zunächst müssen Entwickler und Tester über alle möglichen Barrierefreiheitsfehler aufgeklärt werden, die auf einer Seite auftreten. Um dabei zu helfen, hat das Barrierefreiheitsteam von eBay OATMEAL (die Open Accessibility Testing Methods for Experts And Layfolk) entwickelt, eine zentrale Anlaufstelle für Barrierefreiheitstests, die für jeden verständlich sein soll, unabhängig von seiner Erfahrung mit Barrierefreiheit. Dies trug dazu bei, die Qualität unserer manuellen Tests zu verbessern, konnte jedoch einige der inhärenten Einschränkungen manueller Tests, bei denen wir helfen wollten, nicht vollständig überwinden.
Schnelles Prototyping und Iteration sind beim manuellen Testen schwierig, insbesondere wenn Entwickler und Tester getrennte Personen sind. Normalerweise beginnen Tester mit ihrer Arbeit erst, wenn die gesamte Seite erstellt wurde. Daher ist es nicht unwahrscheinlich, dass Probleme auftauchen, die den Entwickler dazu zwingen, einen erheblichen Teil seiner Arbeit zu wiederholen. Außerdem erfolgt das Feedback nicht sofort, sodass sich die Zeit, die zum Erstellen jeder neuen Funktion benötigt wird, erheblich verlängern kann, wenn es mehrere Iterationen von Änderungen gibt.
Einer der grundlegenden Nachteile des Vertrauens rein Beim manuellen Testen wird ein großer Teil der Arbeitszeit damit verbracht, strukturelle, regelbasierte Barrierefreiheitsprobleme wie Bilder ohne Alt-Text und Elemente mit ungültigen Arienrollen zu testen. Dadurch bleibt den Testern weniger Zeit, sich auf die unstrukturierten Regeln zu konzentrieren, z. B. sicherzustellen, dass die Tab-Reihenfolge sinnvoll ist und es für Benutzer von Bildschirmleseprogrammen einfach ist, den Kontext zu finden, an dem sie sich auf der Seite befinden.
Aufgrund dieser Nachteile haben wir bei eBay schrittweise Tools entwickelt, die dabei helfen, einen Teil des Prozesses der Barrierefreiheitsprüfung zu automatisieren. Das primäre Tool, das wir für diese automatisierten Tests verwendet haben, ist ein internes Tool namens Web Accessibility Evaluator (WAE).
Automatisiertes Testen mit WAE
Als wir mit der Entwicklung automatisierter Tests zur Barrierefreiheit begannen, gab es noch keine etablierte Community-Lösung. Aus diesem Grund haben wir ein Tool entwickelt, das strukturelle Barrierefreiheitsprobleme mit HTML erkennt und diese als Fehler kennzeichnet. Mit WAE sind Teams in der Lage, abgeschlossene Anträge automatisch auf Barrierefreiheitsfehler und Verstöße gegen Best Practices zu überprüfen. Dieses Tool analysiert den HTML-Code einer Seite und findet alle Fehler, die mit einfachen Regeln identifiziert werden können.
WAE hat dazu beigetragen, die Belastung durch manuelle Tests zu verringern. Entwickler und Tester müssen sich nicht mehr eine Liste einfacher Regeln merken oder darauf zurückgreifen, die Überprüfung erfolgt nahezu augenblicklich, und da alle grundlegenden Fehler von den Tools gefunden werden, ist es einfacher, sich während des Handbuchs auf die subjektiveren und unstrukturierteren Regeln zu konzentrieren Testphase.
Obwohl dieses Tool die Entwicklererfahrung für unsere Teams erheblich verbessert hat und für Entwickler weiterhin von Vorteil sein wird, gab es unserer Meinung nach einige Bereiche, die von zusätzlichen Tools profitieren würden.
In den vergangenen Jahren seit Beginn dieses Projekts entstand eine etablierte Open-Source-Community-Lösung für Barrierefreiheitstests namens axe-core von Deque Systems. Wir stellten jedoch fest, dass Axe-Core keine perfekte Lösung für unsere Anforderungen war.
Eine Herausforderung besteht darin, dass moderne Anwendungen nicht direkt in HTML-Code geschrieben sind; Bei eBay verwenden wir unser Open-Source-Framework namens Marko. Dieses Framework sieht aus wie HTML und generiert es für den Browser, es gibt jedoch keine direkte Zuordnung vom Code für die gerenderte Seite zurück zum Marko-Code. Das bedeutet, dass WAE zwar hervorragend darin ist, Fehler mithilfe der Barrierefreiheit auf der Seite zu finden, der Entwickler jedoch herausfinden muss, woher jeder Fehler stammt. Aus diesem Grund haben wir für einige der einfachsten Fehler ein neues Tool entwickelt, das Barrierefreiheitsprobleme in Echtzeit meldet als Entwickler Code schreiben.
Dynamisches Linting für Marko
Ein Linter ist ein Tool, das Code analysiert und Teile davon findet, die möglicherweise etwas Aufmerksamkeit vom Entwickler erfordern. Dazu gehören Fehler, aber auch zusätzliche Vorschläge wie Stilinkonsistenzen und logische Anti-Patterns. Der Sprachserver von Marko erhielt kürzlich ein großes Upgrade, als wir vollständige Linting-Unterstützung für TypeScript hinzufügten, die Entwicklern hilft, logische Fehler in ihrem Code während der Eingabe zu erkennen. Bei der Entwicklung dieser Funktion haben wir den Grundstein für ein weiteres Tool gelegt, das die Axe-Core-Engine von Deque ebenfalls in den Sprachserver integriert.
Wenn ein Entwickler beispielsweise ein IMG-Tag schreibt, ohne Alt-Text einzufügen, erhält er sofort eine Fehlermeldung, dass auf sein Tag nicht zugegriffen werden kann, und eine Beschreibung, wie das Problem behoben werden kann.
Axe-core bietet alle möglichen Methoden zur Behebung des Problems, normalerweise in der Reihenfolge von den meisten bis zu den am wenigsten akzeptierten.
Dieses neue Tool prüft auf Verstöße gegen eine große Liste von Regeln, von denen viele für Entwickler, die nicht in Barrierefreiheit geschult sind, möglicherweise nicht offensichtlich sind. Da Barrierefreiheitsfehler genauso hervorgehoben werden wie andere Fehler im Code, hoffen wir, dass dieses Tool Entwickler dazu ermutigt, sofort barrierefreien Code zu schreiben, anstatt ihn im Nachhinein zu belassen. Dies ist der nächste Schritt, den wir unternehmen, um sicherzustellen, dass die eBay-Websites standardmäßig zugänglich sind.
Bei eBay helfen uns Projekte wie dieses dabei, unser Ziel zu erreichen sei für alle. Wir glauben, dass Fehler in der Barrierefreiheit nicht weniger wichtig sind als jede andere Art von Fehler. Da wir unsere Tools zur Erkennung von Barrierefreiheitsfehlern verbessern, hoffen wir, allen Nutzern der Website weiterhin ein hervorragendes Erlebnis bieten zu können, unabhängig davon, wer sie sind. Wir freuen uns über die Live-Korrektur der Barrierefreiheit, die unseren Entwicklern jetzt zur Verfügung steht, und da Marko und seine Tools Open Source sind, hoffen wir, dass dies nicht nur dazu beiträgt, barrierefreiere Websites ins Internet zu bringen, sondern auch das Bewusstsein der Entwickler für Bedenken hinsichtlich der Barrierefreiheit schärft . Dies ist ein wichtiger Schritt auf unserem Weg zu einem barrierefreien Internet und wir freuen uns auf eine Zukunft, in der Entwickler standardmäßig für Barrierefreiheit schreiben.
