ZUGÄNGLICHKEIT FÜR ENTWICKLER & QA-TESTER
Übersicht
Diese Dokumente decken alle wichtigen Designgrundlagen ab und sollten vom Team zu Projektbeginn überprüft werden. Sie behandeln alle wesentlichen besten Praktiken zur Barrierefreiheit von Websites, die nicht mit einem bestimmten Komponentendesign zusammenhängen. Wie viele der Komponentendokumente enthalten sie Tests, die der Projektmanager als Abnahmekriterien für die QA verwenden kann, sowie Techniken, die Entwickler nutzen können, um diese Kriterien zu erfüllen.
Diese Leitfäden sind so konzipiert, dass sie jedes Designsystem unterstützen, einschließlich Googles Material Design, und können außerdem verwendet werden, um barrierefreies Design für Drittanbieterplattformen wie Wordpress, SAP und Salesforce zu unterstützen und somit in jedem Sprint eines Projekts eingesetzt werden.
Weitere Schulungen und Ratschläge zur Barrierefreiheit finden Sie auf den folgenden YouTube-Kanälen:
1. Erstellung barrierefreier Komponenten
Bei der Entwicklung neuer Komponentendesigns können Barrierefreiheitsprobleme auftreten, die von Richtlinien zur Barrierefreiheit nicht abgedeckt werden, weil sie spezifisch für ein bestimmtes Interaktionsdesign sind.
In solchen Fällen sind zusätzliche Recherchen erforderlich, um Best Practices, die anderswo im Web verfügbar sind, zu identifizieren. Die folgende Seite bietet Ihnen daher eine Liste von Komponenten, die zusätzliche Recherchen benötigen, sowie die Techniken und Methoden, die Sie anwenden können, um sicherzustellen, dass Ihre Komponente den Erwartungen der Nutzer entspricht.
Soweit zutreffend enthalten die Leitfäden Referenzimplementierungen, die erforderliches Code-Verhalten demonstrieren und empfohlene QA-Tests bereitstellen.
Testen
Um Teams die Integration von Testkriterien in ihren Arbeitsplan zu ermöglichen, hilft das folgende Testskript zur Barrierefreiheit sowohl Projektmanagern als auch Entwicklern, die Erfolgskriterien für Barrierefreiheit zu erreichen. Automatisierte Tests sind außerdem verfügbar über UTS Test Magic, Cucumber, Sa11y for Salesforce und sollten in Kombination mit dem folgenden manuellen Testskript verwendet werden: Colt Developer Testing Script.
Um die Zugänglichkeit für Screenreader zu testen, verwenden Sie Windows Narrator, um die Barrierefreiheit Ihrer Komponente oder Anwendung zu überprüfen. Der Leitfaden Using Windows Narrator to Test Web Accessibility skizziert die Steuerelemente, Vorgehensweise und erwarteten Zahlen.
Webseiten können teilweise mit Browser-Plugins getestet werden. Es gibt mehrere kommerzielle und nicht-kommerzielle Plugins, die in Microsoft Edge und Google Chrome laufen. Eines, das zuverlässig, kostenlos nutzbar ist und Tabellen ausgibt, die zur Fehlerverfolgung verwendet werden können, ist IBMs Equal Access Tracker:
Verschiedene automatisierte Testtools können unterschiedliche Ergebnisse liefern, einige sind kommerziell oder halb-kommerziell und nicht alle erstellen Berichte. Stellen Sie sicher, dass alle Mitglieder eines Produktteams dasselbe Tool verwenden.
In Kombination mit den manuellen Tests in den Leitfäden und den Tests mit Windows Narrator sind die meisten Nutzungsbarrieren leicht zu erkennen und zu beheben.
Diese Übersicht von Sparkbox behandelt alle wichtigen Funktionen des IBM-Testtools.
Komponentenguides
Die folgenden Best-Practice-Leitfäden stammen aus verschiedenen Drittanbieter-Designsystemen, Blogs oder vertrauenswürdigen Dokumentationsquellen. Obwohl die Designs möglicherweise nicht exakt denjenigen entsprechen, die von Colt implementiert werden, sind die Methoden und Techniken dennoch eine gültige Möglichkeit, potenzielle Probleme und deren Lösungen zu verstehen.
Navigation
Interaktive Inhalte
Metafelder
Dateneingabe
2. Plattform-Barrierefreiheit
Wenn Sie Webseiten, Apps oder Komponenten auf einer Drittanbieterplattform oder einem Framework wie Salesforce, SAP oder Wordpress erstellen, bieten diese Plattformen jeweils spezifische Leitfäden für ihre Plattformen. Diese sollten zusätzlich zu den Colt Accessibility Guides verwendet werden.
Wordpress
Salesforce
SAP
3. Farbwahrnehmung
Jede Farbe wird von verschiedenen Personen geringfügig und manchmal erheblich unterschiedlich wahrgenommen, und viele Menschen können einige Farbnuancen überhaupt nicht unterscheiden. Sicherzustellen, dass Colts Webseiten-Designs nicht von einer genauen Farbwahrnehmung abhängen, bedeutet, dass niemand ausgeschlossen wird, weil bestimmte Funktionen im Design auf Farbe basieren.
Durchdachter Einsatz der Colt-Markenfarben kann jedoch die Barrierefreiheit für manche Nutzer erhöhen und die Nutzbarkeit für viele Nutzer verbessern. Anstatt Farb-basierten Bedeutungen auf einer Webseite zu vermeiden, stellen Sie sicher, dass, wenn Farbe als visuelle Kennzeichnung verwendet wird, auch alternative nicht-farbige visuelle Hinweise vorhanden sind. Dies wird in Design und Technik oft als 'Redundanz.'
Rot-Grün-Farbsehschwäche ist die häufigste Form der sogenannten Farbfehlsichtigkeitsstörungen. Sie betrifft etwa 1 von 12 Männern und 1 von 200 Frauen. Blau-Gelb-Sehschwäche ist deutlich seltener, und monochrome Farbenblindheit ist noch seltener. Es gibt auch andere Zustände wie Synästhesie, Glaukom, Irlens-Syndrom und einige Menschen mit ASC die Probleme bei der Farbwahrnehmung verursachen können.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Tests, die manuell durchgeführt werden sollten
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Sind alle Links auf der Seite visuell identifizierbar, ohne Farbe zu verwenden? [Y/N]
Wenn Sie mit den einzelnen Funktionen auf der Seite interagieren (z. B. Validierungs- oder Fortschrittsanzeigen), ist es möglich zu erkennen, in welchem Zustand sich jede befindet, auch wenn Farbe deaktiviert ist? [Y/N]
Bezüglich Diagrammen und Grafiken: Sind Kategorien oder Datensätze im Diagramm durch eine visuelle Behandlung außerhalb der Farbe gekennzeichnet? [Y/N]
Zusätzliche Testmethoden und Strategien
Wenn Sie selbst nicht farbenblind sind, können Sie eine Webseite mit einem Farbfehlsichtigkeitssimulator testen. Die App Sim Daltonism kann auf Ihrem Mobiltelefon installiert werden und öffnet einen Betrachter, der einen Farbfehlsichtigkeitsfilter auf alles vor der Kamera anwendet.
4. Formularinteraktionen
Formulare können für Nutzer mit Seh- und/oder kognitiven Beeinträchtigungen eine Herausforderung darstellen. Sicherzustellen, dass Formulare gut gestaltet und zugänglich sind, bedeutet, dass Nutzer diese Formulare wie vorgesehen verstehen und verwenden können.
Wenn Webformulare Konventionen und gute Usability-Praktiken anwenden, können Nutzer Formulare schneller und mit weniger Fehlern beim ersten Versuch ausfüllen. Formulare können Zugangspunkte zu Colts Inhalten und Diensten sein – z. B. für Anmeldungen, Stellenbewerbungen, den letzten Schritt zum Kunden oder sogar die einzige Möglichkeit, ein Problem oder eine Beschwerde vorzubringen. Wenn Formulare schlecht gestaltet oder implementiert sind, schließen sie Nutzer mit Behinderungen vollständig aus.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Tests, die automatisiert werden könnten
Nachfolgend ein Beispiel für einen Test, der kein manuelles Durchsuchen erfordert:
Hat jedes Eingabeelement ein semantisch gültiges HTML-Label-Element, das damit verbunden ist? [Y/N]
Tests, die manuell durchgeführt werden sollten
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Kann das gesamte Formular, einschließlich Korrektur möglicher Fehler, ausschließlich mit der Tastatur ausgefüllt und abgeschickt werden? [Y/N]
Ist die Tab-Reihenfolge durch das Formular (wie durch ein sichtbares Fokusindikator) logisch und vorhersehbar für einen sehenden Tastaturnutzer? [Y/N]
Sind Pflichtfelder sichtbar als solche markiert, und verwenden sie das HTML input required Attribut am Eingabeelement? [Y/N]
Sind Fehlermeldungen so formuliert und angezeigt, dass klar ist, welche Eingabefelder die Eingabe abgelehnt haben, warum die Eingabe nicht akzeptiert wurde und was zu tun ist, um sie zu korrigieren? [Y/N]
Zurücksetzen, Zeitlimits & Validierung
Zurücksetzen-Schaltflächen
Vermeiden Sie die Verwendung eines Zurücksetzen-Buttons in Formularen. Sie werden selten genutzt, und es kann frustrierend sein, wenn ein vollständig ausgefülltes Formular durch einen versehentlichen Klick gelöscht wird. Beachten Sie, dass ohne einen Zurücksetzen-Button Radiobutton-Gruppen in bestimmten Fällen problematisch sein können. Eine ihrer Eigenschaften ist, dass Sie die Auswahl nicht "aufheben" können, sobald eine Option in der Gruppe ausgewählt wurde; Sie können die Auswahl nur auf einen anderen Radiobutton derselben Gruppe verschieben. Aus diesem Grund wird empfohlen, wo angemessen eine "keine der oben genannten"-Option aufzunehmen.
Zeitlimits
Formulare, die zu früh ablaufen, können frustrierend sein, insbesondere wenn der Vorgang lang war, z. B. das Ausfüllen einer Spezifikation für ein Angebot oder eine Bewerbung. Wenn es keinen speziellen Grund für ein Timeout auf einem Formular gibt, stellen Sie sicher, dass Daten für mindestens 20 Stundengespeichert werden. Falls ein Timeout erforderlich ist, stellen Sie sicher, dass es mindestens fünfmal länger ist als die Zeit, die ein durchschnittlicher sehender Nutzer benötigt, und dass die Zeitangaben in den Anweisungen vermittelt werden.
Validierung
Bei der Validierung eines Formulars stellen Sie sicher, dass der ursprüngliche Wert des Benutzers, der den Fehler verursacht hat, nicht gelöscht wird. Indem der ursprüngliche Wert beibehalten wird, kann der Nutzer seinen Fehler leichter erkennen und ihn korrigieren, indem er ihn bearbeitet. Die Verwendung von WAI-ARIA-Attributen kann Validierungsfehler für Nutzer unterstützender Technologien besser nachvollziehbar machen. Verwenden Sie das aria-invalid-Attribut um jedes ungültige Eingabefeld als fehlerhaft zu kennzeichnen, und das aria-describedby-Attribut um die spezifische Fehlermeldung mit diesem Eingabefeld zu verknüpfen.
Fehlermeldungen
Wenn Fehlermeldungen überhaupt nicht angezeigt werden, sollte dies als schwerwiegender Defekt betrachtet werden. Wenn das Absenden eines Formulars abgelehnt wird und es kein Feedback gibt, das erklärt, was korrigiert werden muss, damit der Vorgang fortgesetzt werden kann, wird das Formular unbrauchbar.
Fehlermeldungen sollten prägnant und spezifisch erklären, warum die Formularübermittlung abgelehnt wurde, und sie sollten lange technische Fachbegriffe vermeiden. Alle Fehlercodes sollten in nicht-technischer Weise erklärt werden.
Überprüfen Sie, ob alle anzeigbaren Fehlermeldungen die folgenden Anforderungen erfüllen:
Spezifisch: Einfach zu sagen "es gab einen Fehler" oder "das Formular ist ungültig" ist nicht hilfreich. Die Meldung sollte klar angeben, welches Eingabefeld oder welche Felder ungültig waren und warum die Eingabe abgelehnt wurde. Der Name des Eingabefelds in der Fehlermeldung sollte genau mit dem Label des Eingabefelds übereinstimmen, in dem der Fehler aufgetreten ist.
Freundlich: Auch wenn der Nutzer einen Fehler gemacht hat, sollte die Erfahrung hilfreich wirken. Vermeiden Sie Formulierungen, die aggressiv klingen, wie "Benutzerfehler: ungültige Eingabe", auch wenn sie technisch korrekt sind, da sie keine gute Nutzererfahrung schaffen.
Handlungsorientiert: Zu kommunizieren, dass es ein Problem gibt und worin das Problem besteht, ist nur ein Teil der Antwort. Der Nutzer muss auch wissen, welche Schritte er unternehmen kann, um das Problem zu beheben. Stellen Sie sicher, dass Informationen darüber vorhanden sind, was als Nächstes getan werden muss, um fortzufahren, und verlinken Sie bei Bedarf auf FAQs und einen Helpdesk.
Platzhaltertext
Dies sind Worte, die innerhalb eines Formulareingabefeldes erscheinen und als nette Hinweise gedacht sind. Sie sind kein Ersatz für ordentliche Labels und sollten ein Label nicht duplizieren, sondern zusätzliche Anweisungen oder Hinweise geben.
Platzhalter, die Labels ersetzen, sind für Tastaturnutzer schwer zu verwenden, weil die Anweisungen verschwinden, sobald ein Nutzer in das Textfeld tabbt. Der Kontrast von Platzhaltertext ist von Haus aus niedrig, was ein weiterer Grund ist, warum sie keine Labels ersetzen können. Außerdem kann Platzhaltertext nicht umgebrochen werden, sodass der Nutzer auf schmalen Bildschirmen den Text möglicherweise nicht vollständig sehen kann.
5. Tastaturzugang
Obwohl es viele verschiedene Tastaturtypen (oder äquivalente Schaltgeräte) gibt, die Menschen verwenden können, um auf Webseiten zu navigieren, müssen wir aus Implementierungssicht die folgenden Gruppen berücksichtigen:
Alle anderen Tastaturnutzer, das heißt Nutzer, die zumindest teilweise den Bildschirm sehen können, die möglicherweise einen Screenreader zur Ergänzung ihrer Erfahrung verwenden oder nicht, aber die auf visuelle Hinweise auf dem Bildschirm angewiesen sind, um zu navigieren.
Nutzer, die entweder keinen Zugriff auf ein Zeigegerät wie ein Trackpad oder eine Maus haben oder physische Bedingungen wie RSI, Zerebralparese oder Gliedmaßenunterschiede haben und für die eine Tastatur die bessere Methode ist.
Internationale Gesetze und Richtlinien Konvention der Vereinten Nationen über die Rechte von Menschen mit Behinderungen fordert Webseitenanbieter auf, "sicherzustellen, dass, wo immer möglich, Inhalte über eine Tastatur oder Tastaturoberfläche bedient werden können." Ohne Tastaturunterstützung werden diese Nutzer vom Zugriff auf Ihre Webseite ausgeschlossen. Eine WebAIM-Umfrage unter Screenreader-Nutzern ergab, dass ein beträchtlicher Teil der Befragten angab, dass "ein Mangel an Tastaturzugänglichkeit" für sie ein Problem darstellte. Der Zugriff kann die Nutzung von Formularen, Navigationsmenüs, interaktiven Widgets, Pop-ups, Warnungen und jeder anderen Art von Komponente auf einer Seite umfassen.
Fokussierbare Steuerelemente
Link: Die Enter-Taste sollte den Link aktivieren/öffnen
Schaltfläche: Die Enter- oder Leertaste sollte die Schaltfläche aktivieren/drücken
Kontrollkästchen/Radiobuttons: Die Pfeiltasten sollten das markierte Element verschieben, die Leertaste sollte das markierte Element aktivieren oder deaktivieren
Auswahl (Dropdown): Die Pfeiltasten sollten das markierte Element verschieben, die Enter-Taste sollte das markierte Element auswählen
Dialog: Die Esc-Taste sollte den Dialog schließen
Fokus sichtbar halten
Webbrowser sind bereits zugänglich, wenn es darum geht anzuzeigen, welches Element auf einer Webseite den Fokus hat, indem sie eine sichtbare Umrandung hinzufügen. Durch CSS-Styling dieses Fokus kann der Indikator angepasst oder sogar deaktiviert werden. Ein fehlender oder schwer sichtbarer Fokusindikator sollte als Defekt betrachtet werden.
Anmerkung #1: Alleinige Verwendung einer Farbänderung zur Anzeige des Fokus wäre für Nutzer, die Farben nicht wahrnehmen können, unzugänglich.
Anmerkung #2: Deaktivieren Sie nicht Funktionen, die für die Tastaturnavigation benötigt werden, z. B. :focus {outline:none;}
Sichtbar bei Fokus
Inhalte, die visuell auf dem Bildschirm verborgen sind, aber per Tastaturnavigation den Fokus erhalten können, sollten so verfasst werden, dass der Inhalt sichtbar wird, sobald er den Fokus hat. Ein Beispiel dafür wäre ein "Zum Hauptinhalt springen"-Link, der es Nutzern ermöglichen soll, schnell über alle Navigationsinhalte oben auf jeder Seite zu springen und zum Hauptinhalt weiterzugehen.
Validierung
Bei der Validierung eines Formulars stellen Sie sicher, dass der ursprüngliche Wert des Benutzers, der den Fehler verursacht hat, nicht gelöscht wird. Indem der ursprüngliche Wert beibehalten wird, kann der Nutzer seinen Fehler leichter erkennen und ihn korrigieren, indem er ihn bearbeitet. Die Verwendung von WAI-ARIA-Attributen kann Validierungsfehler für Nutzer unterstützender Technologien besser nachvollziehbar machen. Verwenden Sie das aria-invalid-Attribut um jedes ungültige Eingabefeld als fehlerhaft zu kennzeichnen, und das aria-describedby-Attribut um die spezifische Fehlermeldung mit diesem Eingabefeld zu verknüpfen.
Tastenkürzel
Während es viele bekannte Tastenkürzel in Desktopanwendungen gibt, ist dies nicht für die Vielzahl von Webseiten der Fall. Obwohl das accesskey-Attribut verwendet werden kann, um benutzerdefinierte Schnellzugriffe zu definieren, erhöht dies die Zugänglichkeit nicht unbedingt, wenn Nutzer diese nicht vorhersagen oder leicht erlernen können. Solche Shortcut-Keys könnten sogar problematisch werden, wenn sie mit integrierten Standardkürzeln des Browsers oder der unterstützenden Technologie in Konflikt geraten. Siehe gängige Kürzel in der BBC GEL Megapedia.
Vermeidung von Keyboard-Traps
Eine "Keyboard-Trap" besteht, wenn eine Funktion auf einer Webseite den Nutzer daran hindert, ein fokussiertes Element zu verlassen. Dies sollte natürlich nicht passieren, aber schlecht implementiertes JavaScript kann manchmal das normale Verhalten des Tastaturfokus so verändern, dass es auf diese Weise gebrochen wird, wenn der Autor der Webseite nicht vorsichtig ist.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Tests, die (zumindest teilweise) manuell durchgeführt werden sollten
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Ist es möglich, die Tabulator- Taste zu verwenden, um vorwärts zu navigieren, und die Shift+Tab Tastenkombination zu verwenden, um den Fokus so zu verschieben, dass jeder Link und jedes Steuerelement ohne Maus oder Touchscreen zugänglich und nutzbar ist? [Y/N]
Wenn Sie den Fokus bewegen, sollte klar sichtbar sein, welches Element auf der Webseite derzeit den Fokus hat, z. B. durch eine konsistente, sichtbar kontrastierende Umrandung. [Y/N]
Wenn Sie den Fokus bewegen, folgt jedes Element, das Fokus erhält, einer logischen, vorhersehbaren Reihenfolge, die von oben nach unten und von links nach rechts verläuft (bei Webseiten in Englisch und anderen links-nach-rechts-Sprachen)? [Y/N]
Bei interaktiven Komponenten, einschließlich Formularelementen, ist es möglich, jedes Element zu navigieren und zu bedienen, einschließlich der Einstellung möglicher Optionen, mit den Pfeiltasten, Enter-Taste, Leertaste usw.? [Y/N]
Bei komplexen Komponenten, die den Fokus automatisch verschieben, wenn neuer Inhalt geöffnet oder angezeigt wird, kehrt der Fokus nach dem Schließen dieses Inhalts zum ursprünglichen Element zurück? [Y/N]
Bei Inhalten, die beim Laden der Webseite visuell verborgen sind, wird dieser Inhalt sichtbar, wenn der Tastaturfokus in das Element wechselt? [Y/N]
6. Beschriftungen für interaktive Elemente
Formularsteuerelemente und andere interaktive Elemente müssen korrekt beschriftet sein. Andernfalls wird es für Nutzer unterstützender Technologien schwierig zu verstehen, welchen Zweck das Steuerelement hat. Fehlende oder falsch beschriftete interaktive Elemente können Probleme oder Verwirrung für Ihre Nutzer verursachen.
Internationale Gesetze und Richtlinien verlangt von den Mitgliedsstaaten, auf die "Identifizierung und Beseitigung von Hindernissen und Barrieren für die Barrierefreiheit" in vielen Bereichen hinzuarbeiten, einschließlich "Informationen, Kommunikation und andere Dienstleistungen, einschließlich elektronischer Dienstleistungen." Dies gilt hauptsächlich, aber nicht ausschließlich für staatliche Dienstleistungen. geben an, dass alle interaktiven Elemente sowohl ein Label als auch einen zugänglichen Namen haben sollten. Das Label wird visuell dargestellt und der zugängliche Name wird von unterstützenden Technologien wie Screenreadern verwendet. Oft sind beide identisch; zum Beispiel, wenn ein Link den Text "Startseite"umfasst, wie etwa Startseite der Text "Startseite" ist das Label und der zugängliche Name.
Ebenso hat eine Schaltfläche mit dem Text "Senden" sowohl ein sichtbares Label als auch einen zugänglichen Namen von "Senden".
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Tests, die manuell durchgeführt werden sollten
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Gibt es ein sichtbares Textlabel, das angibt, welche Art von Information eingetragen werden soll? [Y/N]
Ist das Label nahe bei dem Steuerelement platziert, das es beschreibt, sodass offensichtlich ist, auf welches Steuerelement es sich bezieht? [Y/N]
Ist das Label noch sichtbar, wenn das Steuerelement den Fokus hat? [Y/N]
Wenn das Steuerelement eine Gruppe wählbarer Optionen ist, wie ein Dropdown-Menü oder eine Liste von Radiobuttons oder Kontrollkästchen, gibt es ein sichtbares Textlabel, das die Optionssammlung beschreibt? [Y/N]
Wenn Steuerelemente von einem Screenreader gelesen werden, wird das Label wie erwartet vorgelesen? [Y/N]
Beispiele und zusätzliche Informationen
Die drei Aspekte von Labels und zugänglichen Namen, die korrekt implementiert werden müssen, basieren auf dem Nutzer und wie er mit der Webseite interagiert. Ein sichtbares Label ist offensichtlich erforderlich, damit sehende Nutzer, die mit einem Cursor oder einer Maus navigieren, wissen, wozu interaktive Elemente dienen: die Schaltfläche "Tab schließen" anklicken oder per Tab-Taste zum Link "Support-Seite" springen sind Beispiele.
Durch das Bereitstellen dieser Labels auf zugängliche Weise bedienen Sie auch Nutzer von Screenreader-Geräten, die diesen Text verwenden, um den zugänglichen Namen dem Nutzer vorzulesen. In einigen Fällen ist es jedoch möglich, ein sichtbares Label anzuwenden, das sich vom zugänglichen Namen unterscheidet. Dies führt zu potenziellen Problemen für Nutzer, die Sprachsteuerung und Spracherkennung verwenden, um zu navigieren, z. B. indem sie "klicke Senden" sagen. Diese Nutzer sehen das Label und verwenden es zur Steuerung ihrer assistiven Technologie, die sich wiederum auf den zugänglichen Namen verlässt. Aus diesem Grund wird empfohlen, das sichtbare Label gleich dem zugänglichen Namen zu halten.
Verlassen Sie sich nicht auf Platzhaltertext
Platzhaltertext wird manchmal von Seitenerstellern verwendet, als wäre er ein Ersatz für ein Label. Dies ist manchmal ein Versuch, Platz in einem Formular zu sparen, da der Platzhaltertext innerhalb des Eingabefeldes erscheint anstatt daneben. Genau aus diesem Grund eignet er sich nicht als Label. Abgesehen davon, dass er standardmäßig einen niedrigen Kontrast hat, verschwindet er per Design, sobald der Nutzer mit der Texteingabe beginnt. Zu diesem Zeitpunkt gibt es kein sichtbares Label mehr. Nutzer mit Kurzzeitgedächtnisbeeinträchtigungen oder solche, die abgelenkt sind oder sich abgewendet haben, wissen möglicherweise nicht mehr, wofür das Eingabefeld gedacht ist.
Fügen Sie kein Title-Attribut hinzu
Ein Title-Attribut wird manchmal Formulareingabeelementen hinzugefügt. Obwohl die meisten Screenreader das Title-Attribut vorlesen, hat dies keinen Vorteil: Die Verwendung des semantischeren label-Elements würde ebenfalls funktionieren und hat den Vorteil, dass das Label angeklickt werden kann, um das Eingabefeld zu fokussieren. Sowohl ein Label als auch ein Title-Attribut zu haben, bedeutet natürlich, dass beide Textzeichenfolgen vorgelesen werden und zu Duplikationen führen.
Teile von Labels vor Screenreadern verbergen
In einigen Fällen haben bestimmte Teile des in einem Label verwendeten Textes eine konventionelle Bedeutung, aber nur visuellen Charakter. Zum Beispiel wird der Stern (*) oft verwendet, um visuell anzuzeigen, dass ein Formularfeld erforderlich ist. Während einige Screenreader das Sternchen vorlesen, tun dies viele Screenreader nicht. Es ist akzeptabel, das Sternchen vor Screenreadern zu verbergen, wenn die Information auf alternative Weise deutlich gemacht wird.
Teile von Labels vor Nicht-Screenreadern verbergen
Ein Label ist oft einfacher Text, kann aber auch ein Element mit Alternativtext wie ein Bild sein, sofern das Bild ein gut verstandenes Symbol ist. Wenn ein Label nur als Symbol sichtbar ist, muss für Nutzer, die das Symbol nicht sehen können, ein Alternativtext bereitgestellt werden. Idealerweise würde die Steuerung diesen Text zusammen mit dem Symbol für alle sichtbar machen, aber gestalterische Einschränkungen können dies unmöglich machen. In diesem Fall ist es akzeptabel, Text als Label bereitzustellen, der nur für Screenreader zugänglich ist, vorausgesetzt, das Symbol ist sehenden Nutzern ohne Text gut bekannt und verständlich (z. B. ein "Vergrößerungsglas"-Symbol als Label für ein Suchformular).
Das folgende Beispiel verwendet eine der Techniken aus dem Textalternativen für Bilder Abschnitt. Diese Textalternativen werden natürlich vor Nutzern verborgen, die das Bild betrachten.
7. Landmarken
Durch das Hinzufügen von HTML-Landmarken zu Ihren Webseiten ermöglichen Sie unterstützenden Technologien, Regionen zu identifizieren, zu denen ein Nutzer möglicherweise schnell springen möchte, z. B. durch Verwendung der minimalen header-, nav-, main-, section- und footer-Tags. W3C-Leitfaden zu WAI-ARIA-Landmarks.
Eine WebAIM-Umfrage unter Screenreader-Nutzern zeigte, dass mehr als die Hälfte der Befragten zumindest hin und wieder HTML-Landmarken verwendet, um auf einer Webseite zu navigieren. Während laut Umfrage andere Funktionen wie Überschriften Obwohl die Richtlinien kein Gesetz oder eine rechtliche Verpflichtung sind, gilt das Erfüllen ihrer Kriterien in vielen Rechtsordnungen als Nachweis für die Einhaltung gesetzlicher Vorschriften, und diese Gesetze enthalten oft Verweise auf die UN-BRK (siehe oben) oder verlangen vergleichbare und/oder gerechte Ergebnisse. Die WCAG-Richtlinien sind nicht die benutzerfreundlichste Ressource, da sie eher retrospektiv als erklärend sind, obwohl ihr Inhalt sehr nützlich ist. Deshalb hat Colt eigene Leitfäden für Beschriftung interaktiver Elemente, häufiger verwendet werden können, kann das Hinzufügen von HTML-Landmarks zur Reihe virtueller Wegweiser nur hilfreich sein, insbesondere für Nutzer, die ein Dokument nicht visuell durchsuchen können, um zu entscheiden, wo sie beginnen sollen.
Die Navigation nach HTML-Landmarks ist eine Technik, die sowohl sehende als auch blinde Nutzer verwenden können, sogar ohne die Unterstützung eines Screenreaders.
Für Nutzer, die keinen Zugriff auf in ihrem Browser oder ihrer unterstützenden Technologie integrierte Navigations-nach-Landmark-Funktionen haben, können Sie sogenannte "Skip-Links" als Funktion der Webseite bereitstellen. Die Skip-Links sollten der erste Inhalt im Body der Webseite sein und auf den durch das main-Landmark identifizierten Inhalt verlinken.
Dies ist hilfreich für Nutzer, die ansonsten viele Navigationslinks und Header-Inhalte per Tastatur durchsuchen müssten, bevor sie zu dem Inhalt gelangen, den sie aufrufen möchten. Es ist akzeptabel, diese Skip-Links zu verbergen, um die Seite für Nutzer, die mit einem Zeigegerät navigieren (z. B. Maus oder Touch), nicht zu überfrachten, indem CSS angewendet wird, das den Link visuell verbirgt, bis er den Tastaturfokus erhält. Tests, die automatisiert werden könnten:
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Hat die Webseite genau einen Bereich, der mit dem main-Landmark gekennzeichnet ist? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Ist aller Inhalt auf der Webseite innerhalb einer Landmark-Region enthalten? [Y/N]
Tests, die (zumindest teilweise) manuell durchgeführt werden sollten:
Sind Bereiche der Webseite, die hauptsächlich Navigationslinks anzeigen sollen, mit dem nav-Landmark gekennzeichnet? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Ist der Header-Inhalt der Webseite mit dem header-Landmark gekennzeichnet? [Y/N]
Ist der Footer-Inhalt der Webseite mit dem footer-Landmark gekennzeichnet? [Y/N]
Betrachtet man andere Landmarken, wenn sie verwendet werden, kommuniziert jede korrekt den jeweiligen Inhalt: section, article, aside? [Y/N]
Wenn ein Skip-Link existiert, befindet sich dieser Link oben oder in der Nähe des Seitenanfangs und kann er bei Tastaturnavigation verwendet werden, um zum Hauptinhalt zu springen? [Y/N]
8. Links
Beim Verfassen von Linktext verwenden Sie eine prägnante, aber vollständige Beschreibung der verlinkten Ressource. Dies ist besonders wichtig für Menschen, die einen Screenreader verwenden, um die gesamte Webseite zu scannen und nur die Links als Liste vorgelesen zu bekommen, wobei jeder Link keinen Kontext hat und für sich allein verstanden werden muss.
Beispiel: Eine Reihe von Artikelzusammenfassungen, die jeweils den Link mit dem Text "Weiterlesen" enthalten, wird einem Screenreader-Nutzer als Liste vieler "Weiterlesen"-Snippets präsentiert, ohne Hinweis darauf, worüber der jeweilige Link mehr Informationen bietet.
Screenreader-Nutzer:
"Weiterlesen" was? Kontext zum Linktext hinzuzufügen beseitigt Barrieren für Screenreader-Nutzer und hilft wahrscheinlich auch sehenden Nutzern, den Überblick zu behalten, wohin sie navigieren. In Ausnahmefällen, in denen es für sehende Nutzer redundant oder ablenkend wäre, vollständige Details im Link anzuzeigen, kann dies durch Hinzufügen des Kontexts als visuell versteckten Text gehandhabt werden, der nur für Screenreader-Nutzer verfügbar ist.
Obwohl der Linktext visuell nur als "Weiterlesen" im Kontext des Artikels mit dem Titel "Unsere Werte" erscheint, wird er für einen Screenreader-Nutzer in der Liste aller Links auf der Webseite als "Weiterlesen über unsere Werte..." erscheinen. Wenn möglich, sollten Sie den für Screenreader gedachten Inhalt visuell mit dem Inhalt für andere Nutzer übereinstimmend halten. Nicht alle Screenreader-Nutzer sind blind, und Screenreader-Nutzer, die den Text sehen können, könnten verwirrt sein, wenn sie unterschiedliche Inhalte hören und sehen.
Symbole in Links
Obwohl beschreibender, sichtbarer Text die zugänglichste Art ist, einen Link zu beschriften, gibt es Anwendungsfälle, in denen ein allgemein verstandenes Symbol natürlicher wäre. In diesen Fällen muss ein Alternativtext für Screenreader-Nutzer bereitgestellt werden, die das Symbol nicht sehen können.
Ein einfaches
HTML img-Element zeigt das Symbol an. Screenreader geben bekannt, dass ein "Bild" vorhanden ist, und lesen jeden Text im alt-Attribut Vorhandener Text im alt-Attribut wird vorgelesen..
Siehe Leitfaden für Textalternativen für funktionale Bilder.
Externe Links
Beim Verlinken zu externen Websites ist es aus Sicherheits- und Verantwortungsgründen sinnvoll, den Nutzer darüber zu informieren, dass er Inhalte besucht, für die Sie nicht verantwortlich sind. Dies kann relevant sein, wenn der Nutzer auf Ihrer Seite angemeldet ist oder eine andere Sitzung hat, die unterbrochen oder beendet wird, sobald er Ihre Seite verlässt.
Neue Tabs
Das Öffnen von Links in neuen Tabs oder Fenstern kann die Erfahrung für einige Nutzer verwirrender und weniger zugänglich machen, daher sollte dies selten verwendet werden. Eine Ausnahme können Links zu externen Websites sein. Wenn der Link ein Modal oder eine Seite in einem neuen Tab oder Fenster öffnet, stellen Sie sicher, dass dies im Linktext erklärt wird.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Tests, die manuell durchgeführt werden sollten:
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Enthält jeder Link sichtbaren Text oder ein allgemein verstandenes, konventionelles Symbol? [Y/N]
Bei Links, die nur ein Symbol enthalten, ist dem Grafikelement äquivalenter Text zugewiesen? [Y/N]
Sind alle Links konsistent und visuell von umgebendem Text unterscheidbar, sodass der Nutzer sie auf eine Weise identifizieren kann, die nicht ausschließlich von Farbe abhängt? [Y/N]
Ist bei der Navigation der Webseite mit der Tastatur visuell erkennbar, wenn ein Link Tastaturfokus hat? [Y/N]
Wenn Links als separate Liste präsentiert werden, haben sie alle eindeutigen Texte oder Alternativtexte, die knapp, aber deutlich die verlinkte Ressource beschreiben? [Y/N]
Ist der Text aller oder irgendeines Links auf der Seite vollständig verständlich, wenn er isoliert vorgelesen wird? Verwenden Sie beispielsweise nicht "hier klicken" oder "mehr Informationen". [Y/N]
9. Metadaten
Metadaten sind wörtlich "Daten über Daten" und sind für die Barrierefreiheit einer Webseite von entscheidender Bedeutung. Der HTML-Standard definiert mehrere Möglichkeiten für Webseiten-Autoren, diese Metadaten bereitzustellen, einschließlich einer Reihe treffend benannter "meta-Tags" sowie verschiedener anderer Tags und Attribute, die Dinge wie Sprache, Zeichensatz, Titel und bevorzugte Viewport-Skalierung deklarieren – allesamt Aspekte des Dokuments der Webseite.
Während Webseiten-Metadaten mit verschiedenen Tags und Attributen bereitgestellt werden können, haben sie alle gemeinsam, dass sie etablierten Industriestandards folgen und somit maschinenlesbar sind.
Barrierefreiheit und SEO
Die Vorteile genauer und gut geschriebener Metadaten gelten für zwei Arten der Maschinenlesbarkeit: Suchmaschinen-Crawler und unterstützende Technologien. Zum Beispiel ermöglicht ein aussagekräftiges und gut formuliertes HTML title-Tag einer Webseite, dass Google diesen Titel als klickbare Überschrift in den Suchergebnissen anzeigt, dass er beim Teilen der Webseite in sozialen Medien enthalten wird und dass er als Name des Lesezeichens im Browser eines Nutzers verwendet wird.
Darüber hinaus wird derselbe Titel von Screenreadern verwendet, um den Namen der Webseite beim Laden anzusagen, sodass Nutzer, die den Bildschirm möglicherweise nicht sehen können, eine genaue und prägnante Beschreibung des Themas der Seite hören.
Validierung
Die Validierung des HTML ist immer ein guter Anfang, um die zugrunde liegenden Metadaten zu überprüfen. Die Web Developer Browser Extension macht dies einfach; verwenden Sie das Menüelement: Tools → Validate HTML. Die Bewertung der Meta-Tags wird ebenfalls durch dieses Tool vereinfacht. Aktivieren Sie die Menüoption: Information → View Meta Tag Informationen für die zu testende Webseite.
Letztendlich müssen Sie aufgrund der Natur von Metadaten, die für Maschinen optimiert sind, möglicherweise die Quellansicht der Entwicklerwerkzeuge Ihres Browsers verwenden, um direkt auf das HTML der zu testenden Webseite zuzugreifen. Suchen Sie nach Metadaten, die im html-Tag gesetzt oder im head-Bereich des Dokuments definiert sind.
Deklaration der Seiten-Sprache
Internationale Gesetze und Richtlinien Das lang-Attribut kann vielen HTML-Elementen hinzugefügt werden, um anzugeben, in welcher Sprache der Text in diesem Element geschrieben ist. Mindestens das äußerste html-Tag muss eine Sprache deklarieren. Wenn Teile der Seite in einer anderen Sprache verfasst sind (z. B. wenn absichtlich ein fremdsprachiger Ausdruck zitiert wird), muss dieses Element einen korrekten lang-Attributwert entsprechend der verwendeten Sprache haben. Wenn die verwendete Sprache nicht der Standard-Leseordnung von links nach rechts folgt, stellen Sie sicher, dass auch das dir-Attribut enthalten ist, um z. B. "rtl" anzugeben, wenn ein rechts-nach-links-Anzeigemuster zitiert wird.
Das Versäumnis, die Sprache zu setzen, kann Ihr Suchmaschinen-Ranking schädigen, es schwieriger machen, automatische Übersetzungen Ihres Inhalts zu rendern, und Screenreader daran hindern, die jeweils passendste Aussprache-Engine beim Vorlesen Ihres Textinhalts zu verwenden.
Machen Sie Titel spezifisch genug, um unterscheidbar zu sein
Der Titel einer Webseite sollte spezifisch genug sein, um diese Seite von jeder anderen Seite auf der gesamten Website unterscheiden zu können. Wenn Sie dieser Regel folgen, hat am Ende jede Webseite einen eindeutigen Titel; andernfalls deutet dies darauf hin, dass der gewählte Titel entweder nicht spezifisch genug war oder Sie mehrere Webseiten mit identischem Inhalt haben.
Deaktivieren Sie nicht 'Pinch and Spread' zum Zoomen
Touch-Geräte unterstützen oft Gesten wie Pinch and Spread, mit denen Nutzer in sichtbare Bereiche einer Webseite hinein- oder herauszoomen können. Technisch ist es möglich, Metadaten zu definieren, die dies deaktivieren (z. B. durch Setzen von maximum-scale=1). Wenn dies der Fall ist, sollte dies als Defekt betrachtet werden.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Hat die Webseite genau einen Bereich, der mit dem main-Landmark gekennzeichnet ist? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Ergibt die Überprüfung durch ein W3C HTML-Validierungstoolkeine HTML-Validierungsfehler für die Webseite? [Y/N]
Hat die Webseite mindestens ein übergeordnetes Sprachattribut, das den Standard-Sprachcodes für HTML folgt? [Y/N]
Sind Bereiche der Webseite, die hauptsächlich Navigationslinks anzeigen sollen, mit dem nav-Landmark gekennzeichnet? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Verfügt die Webseite über ein title-Tag das das Thema der gesamten Seite genau und prägnant beschreibt? [Y/N]
Wenn die Webseite auf einem Touchscreen angezeigt wird, der Pinch-and-Spread unterstützt, ist es möglich, diese Gesten zum Hinein- und Herauszoomen zu verwenden? [Y/N]
10. Verbesserung & responsives Design
Progressive Enhancement stellt sicher, dass Nutzer die größtmögliche Bandbreite an Geräten und Software verwenden können, während der Kernzweck der Webseite weiterhin nutzbar und verständlich bleibt. Zusätzliche Nice-to-have-Funktionen können für leistungsfähigere Geräte und Browser auf diesen Kern aufgesetzt werden.
Robuste Barrierefreiheit
Die Anwendung von Progressive-Enhancement-Praktiken macht Ihre Webseite robuster und inklusiver; nicht jeder Nutzer hat die schnellste Verbindung, den leistungsfähigsten Computer oder die neueste Software installiert. Manchmal kann eine Funktion auch vom Nutzer absichtlich deaktiviert sein. Sie sollten davon ausgehen, dass es einen guten Grund für diese Entscheidung gibt, aber nicht jeder Nutzer hat eine Wahlmöglichkeit.
1. Stellen Sie sicher, dass Text vergrößerbar ist
Text gilt als nutzbar und lesbar, wenn er nicht abgeschnitten ist und sich nicht überlappend mit anderem Text oder nahegelegenen Elementen darstellt. Er sollte sich bei Bedarf umbrechen und seine typografischen Eigenschaften beibehalten, z. B. ausreichende Zeilenhöhe sowie Zeichen- und Zeilenabstände. Stellen Sie sicher, dass relative Einheiten (ems oder rems) zur Angabe der Größen von Webseiten-Elementen wie Text und Layout verwendet werden. Dadurch kann die Seite relativ zur Größe eines Gerätes oder seiner Ausrichtung (Hoch- oder Querformat) skaliert und angepasst werden.
2. Stellen Sie sicher, dass die Webseite zoombar ist
Das Seitenzoom erhöht die scheinbare Größe der gesamten Seite, während die Textvergrößerung nur die Textgröße erhöht. Stellen Sie sicher, dass alle Inhalte sichtbar und nutzbar sind, wenn die Seite auf mindestens 200% ihres Standardwerts gezoomt wird.
3. Passen Sie Touch-Ziele auf kleineren Bildschirmen an
Auf mobilen Geräten mit Touchscreen hat der Nutzer sowohl einen kleineren physischen Bildschirm als auch die Verwendung eines Fingers zum Antippen von Zielen wie Links oder Schaltflächen. Berücksichtigen Sie dies: Die Mindestgröße eines physischen Touch-Ziels sollte mindestens 7 x 7 mm betragen, oder größer, wenn möglich. Dies erfordert unweigerlich, interaktive Elemente auf kleineren Bildschirmen zu vergrößern.
4. Verlassen Sie sich nicht auf ein noscript-Fallback
Einige Webseiten verwenden das noscript-HTML-Tag, um alternativen Inhalt für Browser bereitzustellen, in denen JavaScript deaktiviert ist. Recherchen von Gov.uk zeigten, dass ein erheblicher Teil der Nutzer, die JavaScript nicht ausführen konnten, JavaScript nicht deaktiviert hatten. Mit anderen Worten: JavaScript war aktiviert, lief aber aus einem anderen Grund nicht. Das ist wichtig, weil ein Browser noscript-Inhalte nur in dem spezifischen Fall anzeigt, dass JavaScript deaktiviert wurde. Wenn JavaScript aus einem anderen Grund nicht ausgeführt wird, sieht der Nutzer nicht den Inhalt, der JavaScript benötigt, und sieht auch keinen noscript-Alternativinhalt.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Hat die Webseite genau einen Bereich, der mit dem main-Landmark gekennzeichnet ist? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Sind in der Gestaltung (CSS) der Webseite alle Größenangaben ausschließlich mit relativen Einheiten (ems oder rems) deklariert, ohne die Verwendung fester Pixelangaben wie px? [Y/N]
Sind Bereiche der Webseite, die hauptsächlich Navigationslinks anzeigen sollen, mit dem nav-Landmark gekennzeichnet? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Wenn die Textgröße in den Browsereinstellungen auf 200% des Standardwerts verändert wird, sind alle Texte auf der Webseite weiterhin sichtbar und lesbar? [Y/N]
Wenn das Seitenzoom im Browser auf 200% erhöht wird, vergrößert sich dann aller Text auf der Webseite proportional? [Y/N]
In den DevTools, mit CPU- und Netzwerk-Drosselung des Browsers auf die am stärksten verschlechterten Einstellungen gesetzt, wird der Kernzweck der Seite weiterhin erfüllt? [Y/N]
In den DevTools, wenn der Gerätemodus des Browsers auf den kleinsten verfügbaren Geräteschirm gesetzt ist, wird der Kernzweck der Seite weiterhin erfüllt? [Y/N] Gerätemodus Simulator
Zusätzliche Testpraktiken
Sie können Tools wie den Chrome-Browser DevToolsverwenden und die Gerätemodus Einstellungen anwenden, um die zu testende Webseite auf einer Reihe von Geräten zu approximieren: von Mobilgeräten über Tablets bis hin zu Desktop. Sie können sogar Geräteeingaben für Touch, Geolocation und Geräteorientierung simulieren.
Beachten Sie, dass die Netzwerk-Registerkarte es Ihnen ermöglicht, CPU- und Netzwerk-Drosselung zu simulieren.
11. Semantische Struktur
Innerhalb jeder Webseite werden Überschriften verwendet, um die Gesamtorganisation und Struktur des Inhalts zu kommunizieren. Die Überschriften sollten als grobe Gliederung des Seiteninhalts fungieren, mit einer logischen Rangordnung der Themen und Unterthemen in hierarchischer Reihenfolge.
Eine WebAIM-Umfrage unter Screenreader-Nutzern ergab, dass 67,5 % der Befragten am ehesten zuerst Überschriften versuchen um Informationen auf einer langen Webseite zu finden. Und 85,7 % gaben an, dass richtige Überschriftenebenen bei der Navigation einer Webseite mittels Überschriften nützlich waren.
Das Versäumnis, brauchbare und gut organisierte Überschriften bereitzustellen, hindert Screenreader-Nutzer daran, die Struktur Ihres Inhalts zu verstehen und sich effizient innerhalb Ihrer Seite zu bewegen. Während Überschriften für alle nützlich sind, sind Nutzer unterstützender Technologien stärker benachteiligt, wenn Überschriften fehlen oder falsch implementiert sind.
Überschriften
Die h1-Überschrift sollte das Thema der gesamten Webseite beschreiben und daher dem Titel-Element der Webseite ähnlich oder identisch sein.
Es ist typisch, dass die allererste Überschrift eine h1 ist, aber es ist kein Defekt, wenn z. B. eine h2 zuerst erscheint. Die logische Rangfolge und Reihenfolge der Überschriften ist wichtiger als welche Überschrift zuerst erscheint; beispielsweise sollte nicht auf eine h2 direkt eine h4 folgen (wobei die erwartete h3 übersprungen wird). Zur Veranschaulichung: Wenn der Navigationsbereich der Seite vor dem angezeigten Titel der Seite erscheint, könnten Sie der Navigation die Überschriftenstufe h2 geben und dann weiter unten eine h1 verwenden, um das Hauptthema der gesamten Seite zu kennzeichnen.
Screenreader-Geräte können nicht erkennen, wenn Elemente nur visuell als Überschriften gestaltet sind, ob sie echte Überschriften sind. Verwenden Sie ein Tool, das den HTML-Quellcode überprüfen kann, um die tatsächlichen Überschriften zu finden (genau so, wie es Screenreader tun), und verwenden Sie ein div nur für den Zweck, für den es vorgesehen ist; verwenden Sie es niemals als Ersatz für geeignetere Tags. Für ein authentischeres Navigations-Erlebnis durch Überschriften verwenden Sie den in Windows integrierten Bildschirmleser Narrator, um die Seite zu testen.
Dies macht die Bedeutung der H1 für Benutzer von Screenreadern unzugänglich.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Hat die Webseite genau einen Bereich, der mit dem main-Landmark gekennzeichnet ist? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Erscheinen HTML-Überschriften-Tags wie h1 und h2 im HTML der Seite? [J/N]
Sind die Überschriften in einer hierarchischen Reihenfolge ohne Auslassen von Überschriftenebenen (z. B. von h2 auf h4)? [J/N]
Sind Bereiche der Webseite, die hauptsächlich Navigationslinks anzeigen sollen, mit dem nav-Landmark gekennzeichnet? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Werden Überschriften in einem konsistenten und erkennbaren Stil angezeigt, der sie gegenüber anderem Nicht-Überschrifteninhalt leicht identifizierbar macht? [J/N]
Beschreibt der Text jeder Überschrift das Thema, das sie einleitet, korrekt und prägnant? [J/N]
Beschreibt die primäre h1 auf der Seite das Thema der gesamten Seite korrekt und prägnant? [J/N]
Sind alle Textbeispiele, die visuell so gestaltet sind, dass sie wie Überschriften aussehen, mit einem HTML-Überschriften-Tag umgesetzt? [J/N]
12. Textalternativen
Wenn dem Benutzer Bilder in seinem Webbrowser nicht zur Verfügung stehen oder wenn der Benutzer aufgrund einer Beeinträchtigung Bilder nicht sehen kann, MÜSSEN Textalternativen bereitgestellt werden, die als vergleichbare Informations- und Nutzungsquelle dienen, damit der Benutzer die Webseite weiterhin für ihren angestrebten Zweck zugreifen, verstehen und verwenden kann.
Dieses Dokument behandelt die Techniken und Tests, die erforderlich sind, um sicherzustellen, dass funktionale Bilder wie Symbole, Schaltflächen, Steuerelemente, Logos und Markenassets für Screenreader-Benutzer zugänglich sind.
Es behandelt auch Techniken zur Identifizierung von Inhaltsbildern; die Tests werden jedoch nicht abschließend nachweisen, dass Inhaltsbilder zugänglich sind. Verlassen Sie sich niemals auf ein automatisiertes KI-Tool zur Generierung von Alt-Text. Funktionale Bilder benötigen eine Textalternative, die beschreibt, was sie tun oder wofür sie stehen, und nicht nur, wie sie aussehen. Eine visuelle Beschreibung einer Schaltfläche oder eines Symbols ist für einen Benutzer wenig oder gar nicht nützlich.
Rein dekorative Bilder
Diese Bilder fügen dem Inhalt der Webseite keine Bedeutung hinzu und sollten daher von Screenreadern stillschweigend ignoriert werden. Dekorative Bilder könnten definitionsgemäß entfernt werden, ohne die Verständlichkeit und Nutzbarkeit der Seite zu beeinträchtigen.
Ebenso werden Hintergrundbilder (in CSS definiert) von Screenreadern automatisch ignoriert und dürfen daher nur für rein dekorative Zwecke verwendet werden.
Es gibt einen häufig missbräuchlich genutzten Randfall, bei dem das Element, das das Hintergrundbild anzeigt, so erstellt ist, dass es Text enthält, der als Alternative zum Bild gedacht ist, anstatt im HTML-alt-Attribut definiert zu sein.
Beachten Sie, dass der alternative Text im Body der Webseite steht, aber (mittels einer vom Entwickler definierten visually-hidden-Klasse) so gestylt ist, dass er nur für Benutzer eines Screenreaders zugänglich ist. Technisch ist dies zwar für Screenreader-Benutzer zugänglich, aber es ist eine schlechtere Vorgehensweise als die Verwendung eines img-Elements mit einem alt-Attribut, weil der visuell versteckte Text niemals angezeigt wird, wenn Bilder deaktiviert sind oder aus irgendeinem Grund nicht geladen werden, während der alt-Attribut-Text angezeigt würde.
Inhaltsbilder
Diese Bilder sind dem Inhalt oder der Funktionalität der Seite inhärent. Verwenden Sie das HTML-alt-Attribut, um eine textliche Alternative für das Bild bereitzustellen.
Seien Sie jedoch vorsichtig, keine redundanten Inhalte bereitzustellen. Wenn der als Alternative verwendete Text bereits in der Nähe im regulären Seiteninhalt vorkommt, sollte die Alternative als redundant betrachtet werden und das Bild daher als rein dekorativ behandelt werden. Andernfalls würde der Screenreader denselben Text zweimal vorlesen.
Bewerten Sie bei der Beurteilung der Qualität alternativer Texte die redaktionelle Bedeutung und den Zweck des Bildes im Kontext der umgebenden Seite. Der alternative Text sollte knapp vermitteln, was das Bild bedeutet, nicht nur, was es zeigt.
Gehen Sie nicht davon aus, dass andere HTML-Funktionen, die alternative Texte bereitstellen sollen, wie die Attribute longdesc, title oder figcaption, für Screenreader funktionieren. Es ist nicht vorhersehbar, ob ein bestimmtes Screenreader-Gerät (abhängig von seiner Konfiguration) diese Attribute ignoriert oder ob es einige oder alle davon vorliest.
Wenn die Menge an benötigten Textinformationen groß oder komplex ist, ist es akzeptabel, ein ARIA-Attribut zu verwenden, um ein anderes angrenzendes HTML-Element als alternativen Text zu kennzeichnen.
Bilder in Steuerelementen
Wenn Bilder als Beschriftung eines Steuerelements fungieren – denken Sie an ein Bild eines Social-Media-Logos, das der einzige Inhalt eines Links zum Social-Media-Auftritt des Unternehmens ist – muss das Steuerelement für Benutzer zugänglich sein, die das Bild nicht sehen können. Verwenden Sie alternative Texte, die die Aktion des Steuerelements erklären. Ein Link sollte das Ziel beschreiben, zum Beispiel "Startseite", "Über uns" usw. Ein Bild in einer Schaltfläche sollte alternativen Text verwenden, der den Zweck der Schaltfläche beschreibt, wie zum Beispiel "Suche", "Anmelden" oder "Absenden".
Grafiken im SVG-Format
In einigen Fällen kann das angezeigte Bild nicht mit einem traditionellen img-Tag definiert sein, aber es muss dennoch möglich sein, dass Screenreader auf einige textliche Alternativen zugreifen können. Das folgende Beispiel zeigt eine von Léonie Watson dokumentierte Technik, die eine Kombination aus role- und aria-labelledby-Attributen verwendet, die sich auf ein title und desc beziehen, um Nutzern von Assistenztechnologien Zugriff auf textliche Beschreibungen der Grafik zu geben.
Wie man das testet
Führen Sie für jede Webseite die folgenden Prüfungen durch. Beantworten Sie jede Frage mit "ja" oder "nein". Das Bestehen wird nach jeder Frage in Großbuchstaben angegeben, z. B. [Y/N], wobei Y erforderlich ist, um zu bestehen. Für jedes Nichtergebnis dokumentieren Sie es als eines der folgenden:
Als Defekt
Ein Defekt, aber mit einer Erklärung, warum er als Ausnahme zugelassen werden sollte
Ein Defekt, aber mit einer Erklärung, warum er nicht anwendbar ist
Hat die Webseite genau einen Bereich, der mit dem main-Landmark gekennzeichnet ist? [Y/N]
Unten ist ein Beispiel für eine Schlüsselfrage, die Sie stellen sollten:
Hat jedes Bild einen damit verknüpften Alternativtext (auch wenn dieser Text leer ist)? [J/N]
Sind Bereiche der Webseite, die hauptsächlich Navigationslinks anzeigen sollen, mit dem nav-Landmark gekennzeichnet? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Ist der alternative Text knapp, grammatikalisch korrekt und frei von Rechtschreibfehlern? [J/N]
Wenn der Bildzweck rein dekorativ ist, ist der alternative Text dann ein leerer Wert, wie alt="" ? [J/N]
Beschreibt der alternative Text das Bild so, dass er eine vergleichbare Bedeutung für Benutzer vermittelt, die das Bild nicht sehen können? [J/N]
Wenn das Bild als einzige Beschriftung für ein Steuerelement, z. B. einen Link oder eine Schaltfläche, dient, ist es dann möglich zu verstehen, was das Steuerelement allein aus dem alternativen Text tut? [J/N]
Ist der alternative Text originell / nützlich und wiederholt nicht nur angrenzenden Seiteninhalt? [J/N]
Entspricht die Sprache des alternativen Textes der für den Rest des Dokuments deklarierten Sprache? [J/N]
Wenn das Bild ein Markenlogo ist und nicht funktional, gibt es dann einfach den Namen der Marke an? [J/N]
Wenn das Bild z. B. ein Diageo-Symbol ist, verwendet es dann den mit diesem Symbol verbundenen Text, wie im Designsystem beschrieben? [J/N]
Hat die Webseite genau einen Bereich, der mit dem main-Landmark gekennzeichnet ist? [Y/N]
Unten ist ein Beispiel für eine Schlüsselfrage, die Sie stellen sollten:
Zeigt der automatisierte Kontrastprüfer keine Kontrastfehler an? [J/N]
Sind Bereiche der Webseite, die hauptsächlich Navigationslinks anzeigen sollen, mit dem nav-Landmark gekennzeichnet? [Y/N]
Nachfolgend einige Beispiele für Schlüsselfragen, die Sie stellen sollten:
Mit aktivierter Simulation verschwommener Sicht, ist es möglich, den über Bildern oder Verläufen gelegten Text leicht zu lesen? [J/N] Hinweis: Holen Sie die Meinungen von mindestens 2 weiteren Personen ein, die an diesem Projekt beteiligt sind
Simulation verschwommener Sicht
Ausreichender Kontrast ist besonders wichtig, wenn Benutzer Ihre Website bei verschwommener Sicht, bei starkem Blenden oder bei Ablenkung verwenden. Die Aktivierung der Simulation verschwommener Sicht ist eine hervorragende Methode, um zu testen, ob Text ausreichend lesbar ist.
Im Chrome-Browser ist diese Simulation verfügbar, wenn Sie die folgenden Schritte ausführen:
Drücken Sie die Tasten: command + shift + p und geben Sie dann den Text "render" ein, um alle verfügbaren Rendering-Optionen anzuzeigen
Scrollen Sie zum Dropdown-Menü "Emulate vision deficiencies"
Wählen Sie dann die Option "Blurred vision"
Um Kontrast und Lesbarkeit für Benutzer mit Farbsehdefiziten zu überprüfen, wählen Sie die Option "Achromatopsia" (Entfernen aller Farben).
Zusätzliche Informationen
Das Deaktivieren von Bildern (auch eine Option über die Web Developer-Browsererweiterung) ist eine effektive Methode, um sicherzustellen, dass Text, der vorgesehen war, über einem Bild zu erscheinen, weiterhin lesbar ist, falls dieses Bild nicht angezeigt wird. Das Festlegen einer Fallback-Hintergrundfarbe für solche Elemente mit Hintergrundbildern ist wichtig, um solche Fälle zu behandeln.
14. Verwendung des Windows Narrators
Narrator ist ein in alle Windows-Betriebssysteme integrierter Screenreader. Dieser Leitfaden soll Entwicklern und Testern, die neu mit Narrator sind, helfen, die grundlegenden Steuerungen zum Testen ihrer Webseiten zu erlernen.
Narrator funktioniert derzeit am besten mit dem MS Edge-Browser, bietet aber auch Unterstützung für Chrome und Firefox.
Erste Schritte
Um Narrator zu starten oder zu beenden, drücken Sie die Windows-Taste + Strg + Eingabetaste. Es öffnet sich ein Fenster mit Optionen, um mehr über Narrator zu erfahren und Ihre Einstellungen zu konfigurieren. Wenn Sie neu bei Narrator sind, sehen Sie sich dieses Video an für ein kurzes Einführungstutorial.
Nützliche Dinge, an die man sich erinnern sollte:
Drücken Sie die Windows-Taste + Strg + N, um auf die Einstellungen zuzugreifen. Hier können Sie Stimme, relative Lautstärke und Geschwindigkeit ändern.
Sowohl die Feststelltaste (Caps Lock) als auch die Einfügen-Taste (Insert) können als Narrator-"Modifier"-Taste verwendet werden, die in vielen Befehlen genutzt wird—wir nennen sie Narrator-Taste.
Strg + Pos1: bringt Sie zum Seitenanfang
Strg + R: aktualisiert die Seite (nützlich, wenn Sie verloren sind oder wenn Narrator sich nicht wie erwartet verhält)
Für eine vollständige Liste der Narrator-Tastenkombinationen https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
Zuhören von Webinhalten
Es gibt mehrere Möglichkeiten, Narrator zum Zugriff auf Webinhalte zu verwenden. Hier sind die nützlichsten Tasten:
Strg + ↑/↓: Vorherige/nächste Zeile vorlesen
↑/↓: Vorherigen/nächsten Absatz oder Eintrag vorlesen
Narrator + Tab: Aktuelles Element erneut vorlesen
Narrator + +/-: Sprechgeschwindigkeit erhöhen/verringern
Strg: Vorlesen stoppen
Sie möchten vielleicht das Vorlesen auf einigen verschiedenen Seiten üben, bevor Sie mit dem Testen beginnen.
Testen der Seitennavigation
Die meisten sehenden Benutzer überfliegen eine Webseite und erfassen eine visuelle Momentaufnahme, um eine Vorstellung davon zu bekommen, wo alles ist. Das können Sie nicht, dann ist der Inhalt der Seite in Bezug auf Überschriften, Bilder, Formularelemente, Meldungen usw. unbekannt. Wenn eine Webseite gut strukturiert ist und den Colt Accessibility Guides gefolgt ist, sollte ein Benutzer die Seite mithilfe von Überschriften, Landmarks, Links oder Listen usw. navigieren können.
Es gibt mehrere Einzeltasten-Abkürzungen, um schnell nach gängigen Seitenelementen zu navigieren. Überprüfen Sie, ob diese funktionieren und ob Sie auf jeden Elementtyp erfolgreich zugreifen können.
Dazu gehören:
H: Überschriften
1 - 6: Überschrift 1, Überschrift 2 usw.
D: Landmarks
Tab: Links und Formularelemente
F: Formularelemente
B: Schaltflächen
K: Links
L: Listen
I: Elemente in einer Liste
T: Tabellen
Shift + Beliebige Navigations-Taste kehrt die Aktion um.
Öffnen Sie den Suchdialog und versuchen Sie, nach verschiedenen Elementen zu suchen
Narrator + Strg + F : Öffnet den Suchdialog
Narrator + F3: Durch Narrator-Suchergebnisse navigieren (Shift hinzufügen, um rückwärts zu gehen)
Leitfaden zur Navigationszugänglichkeit
Formulare testen
Wenn ein Formularelement den Tastaturfokus erhält, liest Narrator das Label (falls vorhanden) und kündigt dann den Typ des Formularelements an. Wenn eine Gruppe von Formularelementen—typischerweise Gruppen von Kontrollkästchen oder Optionsfeldern—in einem fieldset mit einer Legende enthalten ist, präsentiert Narrator Elemente in einem fieldset als Gruppe und liest die Legende, wenn Sie zum ersten Mal etwas innerhalb der Gruppe ansteuern.
Verwenden Sie die folgenden Tastatursteuerungen des Browsers, um mit Formularelementen zu interagieren und zu testen, ob sie ansteuerbar sind und ob ihre Beschriftungen sowohl einzigartig als auch beschreibend sind.
Tab und Shift + Tab: Durch Formularelemente navigieren
Leertaste zum Auswählen und Aufheben der Auswahl von Kontrollkästchen
↑/↓: Aus einer Gruppe von Optionsfeldern auswählen
Leertaste, dann ↑/↓ oder der erste Buchstabe einer Option: Ein Kombinationsfeld erweitern und dann eine Option auswählen
Eingabetaste: Ein Formular absenden
Leitfaden zur Formularzugänglichkeit
Bilder testen
Bilder können funktional, inhaltlich oder dekorativ sein. Colts Streamgrafiken sind hauptsächlich ästhetisch und würden daher als dekorativ eingestuft. Das würde bedeuten, dass sie für Screenreader stumm sind. Wenn kein alternativer Text definiert ist, sagt Narrator typischerweise „image“ oder „unlabeled graphic“ (die meisten anderen Screenreader ignorieren diese). Der alternative Text eines funktionalen oder Inhaltsbildes wird von Narrator vorgelesen und sollte den Zweck der Nutzung des Bildes beschreiben.
Beispiele:
Colt-Logos sollten einfach den Namen der Marke sagen, "Colt Technology Services"
Co-Branding-Logos sollten beide Markennamen sagen, "Colt Technology Services in Partnership with Cisco"
Colt-Symbole Accessibility Conformance Report (ACR) ESG-Grafiken, sollten einfach den Zweck dessen angeben, wofür das Bild steht.
Bilder, die Links sind: Wenn das Colt-Logo auch ein Link zur Startseite ist, sollte sowohl der Markenname als auch das Ziel berücksichtigt werden, z. B. "Colt-Startseite".
Leitfaden zur Bildzugänglichkeit
Tabellendaten testen
Um zur nächsten Tabelle auf einer Seite zu navigieren, drücken Sie die Taste T. Um innerhalb einer Datentabelle, halten Sie Strg + Alt gedrückt und verwenden Sie ↑/↓/←/→, um von Zelle zu Zelle zu wechseln. Wenn eine Tabelle korrekte Zeilen- und Spaltenüberschriften hat, werden diese beim Navigieren automatisch vorgelesen.
Stellen Sie sicher, dass die Zeilen und Spalten sinnvolle Beschriftungen haben.
Für eine vollständige Liste der Narrator-Tastenkombinationen: https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
15. Downloads
Um Entwicklern das Testen auf potenzielle Zugänglichkeitsprobleme zu erleichtern, haben wir eine Manuelle Zugänglichkeits-Checkliste erstellt, um Ihre Tests zu strukturieren.
Zuletzt aktualisiert
War das hilfreich?