Checkliste für mobile Zugänglichkeit
Dieses Dokument bietet eine prägnante Checkliste der Barrierefreiheitsanforderungen für Entwickler von mobilen Apps. Es soll kontinuierlich weiterentwickelt werden, da mehr Muster entstehen.
Farbe
-
Der Farbkontrast muss den WCAG 2.2 AA-Level-Anforderungen entsprechen:
- Kontrastverhältnis von 4.5:1 für normalen Text (weniger als 18 Punkt oder 14 Punkt fett).
- Kontrastverhältnis von 3:1 für großen Text (mindestens 18 Punkt oder 14 Punkt fett).
-
Informationen, die über Farbe vermittelt werden, müssen auch auf andere Weise verfügbar sein (unterstrichener Text für Links, etc.).
Sichtbarkeit
- Techniken zum Verbergen von Inhalten wie null Opazität, z-Index-Reihenfolge und Platzierung außerhalb des Bildschirms dürfen nicht ausschließlich für die Handhabung der Sichtbarkeit verwendet werden.
- Alles außer dem aktuell sichtbaren Bildschirm muss wirklich unsichtbar sein (besonders wichtig für Einzelseiten-Apps mit mehreren Karten):
- Verwenden Sie das
hidden
-Attribut oder dievisibility
- oderdisplay
-Stileigenschaften. - Sofern nicht absolut unvermeidbar, sollte das
aria-hidden
-Attribut nicht verwendet werden.
- Verwenden Sie das
Fokus
-
Alle aktivierbaren Elemente müssen fokussierbar sein:
- Standardkontrollen wie Links, Buttons und Formularfelder sind standardmäßig fokussierbar.
- Nicht-Standardkontrollen müssen eine geeignete ARIA Role zugewiesen bekommen, wie
button
,link
odercheckbox
.
-
Der Fokus sollte in einer logischen Reihenfolge und konsistent gehandhabt werden.
Textersatz
-
Für jedes nicht strikt präsentative nicht-textuelle Element innerhalb der App muss ein Textersatz bereitgestellt werden.
- Verwenden Sie alt und title, wo angemessen (lesen Sie Steve Faulkners Beitrag über die Verwendung des HTML title-Attributs für einen guten Leitfaden).
- Wenn die obigen Attribute nicht anwendbar sind, verwenden Sie geeignete ARIA-Zustände und -Eigenschaften wie
aria-label
,aria-labelledby
oderaria-describedby
.
-
Bilder von Text sollten vermieden werden.
-
Alle Benutzeroberflächenkomponenten mit sichtbarem Text (oder einem Bild von Text) als Beschriftungen müssen denselben Text im programmatischen Namen der Komponente verfügbar haben. WCAG 2.1: Bezeichnung im Namen.
-
Alle Formularelemente müssen Labels (
<label>
-Elemente) haben, um Benutzer von Bildschirmlesegeräten zu unterstützen.
Umgang mit Zuständen
- Standardkontrollen wie Optionsfelder und Kontrollkästchen werden vom Betriebssystem verwaltet. Für andere benutzerdefinierte Steuerungen müssen Zustandsänderungen über ARIA-Staaten bereitgestellt werden, wie
aria-checked
,aria-disabled
,aria-selected
,aria-expanded
undaria-pressed
.
Orientierung
- Inhalte sollten nicht auf eine einzige Ausrichtung beschränkt sein, wie Hoch- oder Querformat, es sei denn, es ist wesentlich. WCAG 2.1: Orientierung
- Beispiele für den zwingenden Einsatz einer Ausrichtung sind eine Klavieranwendung oder ein Bankscheck.
Allgemeine Richtlinien
-
Ein App-Titel muss bereitgestellt werden.
-
Überschriften dürfen die hierarchische Struktur nicht unterbrechen
html<h1>Top level heading</h1> <h2>Secondary heading</h2> <h2>Another secondary heading</h2> <h3>Low level heading</h3>
-
ARIA-Landmark-Rollen sollten verwendet werden, um eine App- oder Dokumentstruktur zu beschreiben, wie
banner
,complementary
,contentinfo
,main
,navigation
,search
. -
Für Touch-Ereignisse stellen Sie sicher Folgendes (WCAG 2.1: Zeigerabbruch):
- Das Down-Event sollte nicht verwendet werden, um irgendeinen Teil der Funktion auszuführen;
- Falls das obige nicht befolgt wird, sollte der Abschluss der Funktion auf dem Up-Event erfolgen, und ein Mechanismus sollte verfügbar sein, um die Aktion vor ihrem Abschluss abzubrechen oder die Aktion nach ihrem Abschluss rückgängig zu machen;
- Falls das obige nicht befolgt wird, sollte das Up-Event in der Lage sein, jede Aktion rückgängig zu machen, die auf einem Down-Event ausgelöst wurde;
- Alle oben genannten Punkte dürfen verletzt werden, wenn es wesentlich ist, die Aktion beim Down-Event auszulösen, normalerweise um reale Erfahrungen zu simulieren oder um Echtzeit-Feedback zu bieten. Zum Beispiel Spielsteuerungen, Klaviaturen oder virtuelle Tastaturen.
-
Berührungsziele müssen groß genug sein, damit der Benutzer interagieren kann (siehe die BBC Mobile Accessibility Guidelines für nützliche Leitlinien zur Größe von Berührungszielen).
Hinweis: Die ursprüngliche Version dieses Dokuments wurde von Yura Zenevich verfasst.