Nicht empfehlenswerte Praktiken

Nicht empfehlenswerte Praktiken für barrierefreie Apps (HTML)

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation]

Sie suchen die C#/VB/C++/XAML-Version dieses Themas? Informationen finden Sie unter Nicht empfehlenswerte Praktiken für barrierefreie Apps (XAML).

Vermeiden Sie die folgenden Praktiken, wenn Ihre Windows-Runtime-App mit JavaScript barrierefrei sein soll.

  • Vermeiden Sie es, benutzerdefinierte UI-Elemente zu erstellen, wenn Sie Standard-HTML-Tags oder die Steuerelemente verwenden können, die im Framework für Windows Runtime enthalten sind. Wenn Sie ein benutzerdefiniertes UI-Element – normalerweise durch Verwendung des div-Tags – erstellen, ist es aufwendiger, die Barrierefreiheit sicherzustellen. Standard-HTML-Tags und Standardsteuerelemente für Windows Runtime sind standardmäßig barrierefrei. Sie müssen unter Umständen nur noch den barrierefreien Namen eines Steuerelements festlegen, um für vollständige Barrierefreiheit zu sorgen.
  • Verwenden Sie weder statischen Text noch andere nicht interaktive Elemente in der Aktivierreihenfolge (beispielsweise durch das Festlegen des tabIndex-Attributs auf einen höheren Wert als 0 für ein Element, das nicht interaktiv ist). Nicht interaktive Elemente in der Aktivierreihenfolge verstoßen gegen die Barrierefreiheitsrichtlinien für Tastaturen, da sich durch diese die Effizienz bei der Tastaturnavigation verringert. Außerdem können dadurch Benutzer verwirrt werden, die ausschließlich interaktive Elemente in der Aktivierreihenfolge erwarten (Schaltflächen, Kontrollkästchen, Texteingabefelder, Kombinationsfelder, Listen usw.).
  • Legen Sie das role-Attribut nicht auf einen willkürlichen Wert fest, da Ihnen hierdurch die Vorzüge der integrierten Unterstützung für Barrierefreiheit entgehen, die die Windows-Runtime-Plattform bietet. Das Festlegen des role-Attributs eines Elements auf den Wert einer gültigen (nicht abstrakten) Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA)-Rolle ist die beste Möglichkeit, um der Plattform die richtige Darstellung des Elements für Bildschirmleseprogramme und andere Hilfstechnologieprogramme zu ermöglichen.
  • Verwenden Sie keine benutzerdefinierten Cascading Style Sheets (CSS) zur absoluten Positionierung von UI-Elementen. Ordnen Sie, wenn möglich, UI-Elemente in Dokumentreihenfolge oder logischer Reihenfolge an, um sicherzustellen, dass Bildschirmleseprogramme diese UI-Elemente in der richtigen Reihenfolge lesen können. Wenn die sichtbare Reihenfolge von UI-Elementen von der Dokumentreihenfolge oder der logischen Reihenfolge abweichen kann, verwenden Sie die Attribute aria-flowto und x-ms-aria-flowfrom, um die richtige Lesereihenfolge zu definieren.
  • Vermeiden Sie es, Informationen nur durch den Einsatz von Farben zu transportieren. Benutzer, die farbenblind sind, können Informationen, die ausschließlich durch Farben vermittelt werden, beispielsweise bei einer farbbasierten Statusanzeige, nicht wahrnehmen. Schließen Sie andere visuelle Hinweise, vorzugsweise Text, ein, um dazu zu sorgen, dass diese Informationen zugänglich sind.
  • Vermeiden Sie es, ganze Seiten automatisch zu aktualisieren. Wenn Sie Seiteninhalte automatisch aktualisieren müssen, aktualisieren Sie nur bestimmte Bereiche der Seite, und kennzeichnen Sie die Bereiche als dynamische Bereiche.
  • Verwenden Sie keine UI-Elemente, die mehr als dreimal pro Sekunden blinken. Blinkende Elemente können bei einigen Menschen Anfälle auslösen. Am besten ist es, blinkende UI-Elemente vollständig zu vermeiden.
  • Vermeiden Sie den automatischen Wechsel des Benutzerkontexts oder die automatische Aktivierung von Funktionalität. Kontext- oder Aktivierungsänderungen sollten nur erfolgen, wenn der Benutzer eine direkte Aktion mit einem Benutzeroberflächenelement ausführt, das den Fokus hat. Zu Änderungen des Benutzerkontexts zählen die Verlagerung des Fokus, die Anzeige neuer Inhalte und die Navigation zu einer anderen Seite. Kontextwechsel ohne Beteiligung des Benutzers können für Benutzer mit Behinderungen verwirrend sein. Ausnahmen von dieser Vorgabe sind das Anzeigen von Untermenüs, die Überprüfung von Formularen, das Anzeigen von Hilfetext in einem anderen Steuerelement sowie Kontextwechsel als Reaktion auf ein asynchrones Ereignis.

Verwandte Themen

Barrierefreiheit für Windows-Runtime-Apps mit JavaScript und HTML

 

 

Anzeigen:
© 2016 Microsoft