Accessibility Testing Part 1
4 Min. Lesezeit
Heute beginne ich mit meinem allerersten Barrierefreiheits-Check. Ich werde Webeiten daraufhin überprüfen, wie gut diese Barrierefreiheit umsetzen, und auf Probleme und verbesserungswürdige Punkte hinweisen.
Bis zur Zustimmung werde ich nicht veröffentlichen, welche Webseiten ich überprüfe, um niemanden in Verlegenheit zu bringen und um den Besitzern die Möglichkeit zu geben, ihre Website zu aktualisieren und zugänglicher zu machen, nachdem ich ihnen meine Ergebnisse übermittelt habe.
Accessibility Tools und wie man diese benutzt
Ich teste die Webseite mit der kostenlosen axe DevTool-Erweiterung, einer der besten Tools auf dem Markt. Nachdem ich die Erweiterung ausgeführt habe, werden 40 automatische* Fehler gefunden. Diese sind in critical, serious, moderate und minor unterteilt. Die critical und serious Probleme sind die wichtigsten, die behoben werden müssen. Schauen wir uns diese genauer an und überlegen, was getan werden kann, um die Webseite zu verbessern.
*Automatisch bedeutet, dass Fehler mit Hilfe von Entwicklungswerkzeugen für die Barrierefreiheit gefunden werden. Doch selbst wenn alle aufgelisteten Fehler behoben sind, bedeutet das nicht unbedingt, dass die Webseite nun vollständig zugänglich ist. Es sind immer noch manuelle Tests erforderlich, bei denen z.B. nur die Tastatur verwendet oder die Webseite mit einem Bildschirmlesegerät (Screen Reader) bedient wird, um wirklich alle Probleme aufzuzeigen und diese beheben zu können.
Elements Must Have Sufficient Color Contrast
“Elemente müssen einen ausreichenden Farbkontrast aufweisen“. Die meisten schwerwiegenden Probleme standen im Zusammenhang mit dem Farbkontrast. Um die Fehler auf der Webseite leicht zu finden, kannst du sie durch Aktivieren der Schaltfläche „Hervorheben“ hervorheben.
Problembeschreibung (von axe Devtools, übersetzt von Julia)
Stellt sicher, dass der Kontrast zwischen Vorder- und Hintergrundfarben den Grenzwerten der WCAG2AA für das Kontrastverhältnis entspricht.
Menschen mit Sehschwäche können aufgrund des schwachen Farbkontrasts Schwierigkeiten beim Lesen des Inhalts haben.
Primary color
Dieser Button hat keinen ausreichenden Farbkontrast (blauer HEX-Farbwert von #2FAFF5 auf weißem HEX-Farbwert #FFFFFF). Der WebAIM Color Contrast Checker zeigt, dass das Kontrastverhältnis nur 2.45:1 beträgt, was ziemlich niedrig ist. Um WCAG2.1 AA zu erfüllen, muss das Kontrastverhältnis mindestens 4.5:1 betragen. Um dieses Verhältnis zu erreichen, müsste das Blau auf eine Helligkeit von 32 % reduziert werden.
Diese Farbkombination verursacht auch drei der anderen Probleme.
Neutrale Farbe
Die beiden anderen Probleme werden durch einen Grauton in der Zwischenüberschrift verursacht.
Das Grau (#737373) selbst würde mit einem Kontrastverhältnis von 8,59:1 auf einem weißen (#FFFFFF) Hintergrund ausreichen, aber es wurde eine Deckkraft von rgba(115, 115, 115, 0,74) eingestellt, die den Kontrast auf 2,95:1 abschwächt.
Wie man das Problem löst
Wenn du die Primärfarbe oder die Textfarbe in eine dunklere Farbe änderst und die Deckkraft aufhebst, ist dieses Problem gelöst.
Element muss ein lang Attribut haben
Es ist wichtig, dass eine Standardsprache eingestellt ist. Andernfalls verwenden Bildschirmlesegeräte die vom Betriebssystem gewählte Sprache, was ziemlich schrecklich und unverständlich klingen kann, wenn du beispielsweise ein deutsches Wort auf Französisch aussprichst, was der Benutzer des Bildschirmlesegeräts vielleicht nicht erwartet.
Problembeschreibung
Stellt sicher, dass jedes HTML-Dokument ein lang-Attribut hat.
Wie man das Problem löst
Hinzufügen der Sprache der Website, in diesem Fall Englisch, mit dem Attribut lang.
<html lang="en">
<!--document head und body-->
</html>
Wenn Wörter oder Absätze in einer anderen Sprache als der Standardsprache verwendet werden, kannst du die Sprache auch direkt in diesem HTML-Tag angeben.
<p lang="es">Text in einer anderen Sprache</p>
Hier ist eine Liste mit allen HTML Language Code References.
Links müssen erkennbaren Text haben
Das letzte schwerwiegende Problem betrifft einen Anker-Tag um das Firmenlogo in der Kopfzeile oben links.
Problembeschreibung
Stellt sicher, dass Links einen erkennbaren Text haben.
<a href="#" class="logo-link w-nav-brand">
<img loading="lazy" src="https://logo.svg" alt="" class="image" />
</a>
Der Link um das Logo herum führt nirgendwo hin, wenn er angeklickt wird. Der a-Tag wird hier also missbraucht. Aber ich sehe, wie es ist. Die Website wurde mit Webflow erstellt. Ich nehme also an, dass Webflow dies standardmäßig macht, denn viele Webseiten verlinken auf ihre Homepage, wenn man auf das Logo klickt, aber das ist hier nicht der Fall.
Und das ist es, was irreführend ist. Benutzer von Bildschirmlesegeräten können mit der Tabulatortaste auf das Logo zugreifen, weil es sich um ein a-Tag handelt, so dass sie davon ausgehen, dass etwas passiert, wenn sie darauf klicken. Screenreader-Nutzer erhalten keine weiteren Informationen im Attribut alt oder über das aria-label, dass es sich nicht um einen echten Link handelt.
Wie man das Problem löst
Der umgebende <a> Tag sollte entfernt werden.
Das href-Attribut erhält ein Ziel, zu dem verlinkt wird, und einen erkennbaren Text, z. B. im Attribut alt des Bildes. Bei dieser Website handelt es sich um eine einseitige Webseite, d. h. die Links in der Navigationsleiste verweisen auf Abschnitte innerhalb der Seite (z. B. Home, About). Der Zielort könnte derselbe sein wie der für den Home-Bereich.
Nächste Schritte
Ich werde mich mit dem Eigentümer der Webseite in Verbindung setzen und ihm meine Erkenntnisse und Tipps mitteilen, ihn fragen, ob Änderungen vorgenommen werden können, um das Web für alle zugänglich zu machen, und natürlich meine Hilfe anbieten, falls sie benötigt wird.
Ich werde dich auf dem Laufenden halten.
Update 08/14/2022
Ich habe eine positive Rückmeldung vom Eigentümer der Website erhalten. Er und sein Webdesigner werden sich die von mir aufgeführten Probleme ansehen und die notwendigen Anpassungen vornehmen. Auftrag erfüllt.
Dieser Artikel wurde ursprünglich gepostet auf dev.to/yuridevat