Mobile Accessibility Checkliste

Der Farbkontrast muss den WCAG 2.2 AA-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 usw.).

• Verwenden Sie das hidden-Attribut oder visibility- oder display-Stileigenschaften.
• Sofern nicht absolut unvermeidbar, sollte das aria-hidden-Attribut nicht verwendet werden.

Alle aktivierbaren Elemente müssen fokussierbar sein:

• Standardkontrollen wie Links, Schaltflächen und Formularfelder sind standardmäßig fokussierbar.
• Nicht-standardisierte Kontrollen müssen eine passende ARIA-Rolle zugewiesen bekommen, wie button, link oder checkbox.

Der Fokus sollte in einer logischen Reihenfolge und konsistent gehandhabt werden.

Für jedes nicht ausschließlich präsentationale Nicht-Text-Element innerhalb der App muss ein Textequivalent 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 oder aria-describedby.

Textbilder müssen vermieden werden.

Alle Benutzeroberflächenkomponenten mit sichtbarem Text (oder Textbildern) als Labels müssen denselben Text im programmatischen name der Komponente haben. WCAG 2.1: Label in Name.

Alle Formularelemente müssen Labels (<label>-Elemente) haben, um benutzerfreundlich für Bildschirmlesegeräte zu sein.

• Beispiele, wann eine Ausrichtung unerlässlich ist, sind eine Klavieranwendung oder ein Bankscheck.

Ein App-Titel muss bereitgestellt werden.

Überschriften dürfen die Hierarchiestruktur nicht brechen

<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 die Struktur einer App oder eines Dokuments zu beschreiben, wie banner, complementary, contentinfo, main, navigation, search.

Für Touch-Ereignisse stellen Sie sicher, dass Folgendes zutrifft (WCAG 2.1: Zeiger-Abbrechen):

• Das Down-Ereignis sollte nicht verwendet werden, um einen Teil der Funktion auszuführen;
• Wenn das oben genannte fehlschlägt, sollte der Abschluss der Funktion beim Up-Ereignis erfolgen, und es muss ein Mechanismus vorhanden sein, um die Handlung vor ihrer Fertigstellung abzubrechen oder rückgängig zu machen, nachdem sie abgeschlossen wurde;
• Wenn das oben genannte fehlschlägt, sollte das Up-Ereignis in der Lage sein, jede Aktion rückgängig zu machen, die auf einem Down-Ereignis ausgelöst wurde;
• Alle oben genannten Punkte dürfen verletzt werden, wenn es unerlässlich ist, die Aktion beim Down-Ereignis auszulösen, normalerweise um reale Erfahrungen zu simulieren oder um Echtzeit-Feedback zu geben. Zum Beispiel bei Spielsteuerungen, Klaviertastaturen oder virtuellen Tastaturen.

Touch-Ziele müssen groß genug sein, damit der Benutzer interagieren kann (siehe die BBC Mobile Accessibility Guidelines für nützliche Richtlinien zur Größe von Touch-Zielen).