Nicht empfehlenswerte Praktiken für barrierefreie Apps (HTML)

Applies to Windows and Windows Phone

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 Sie die Barrierefreiheit einer Windows-Runtime-App, die JavaScript verwendet, sicherstellen möchten.

  • 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-Apps, die JavaScript verwenden, 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-Apps sind standardmäßig barrierefrei. Sie müssen vielleicht 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) WAI (Web Accessibility Initiative)-ARIA (Accessible Rich Internet Applications)-Rolle ist die beste Möglichkeit, um der Plattform die richtige Darstellung des Elements für Bildschirmleseprogramme und andere Hilfstechnologieprogramme zu ermöglichen.
  • Vermeiden Sie die absolute Positionierung von UI-Elementen über Cascading Stylesheets (CSS). Ordnen Sie, wenn möglich, Benutzeroberflächenelemente in Dokumentreihenfolge oder logischer Reihenfolge an, um sicherzustellen, dass Bildschirmleseprogramme diese 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 Live-Regionen.
  • Verwenden Sie keine Benutzeroberflächenelemente, 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

Erstellen einer barrierefreien Windows-Runtime-App mit JavaScript

 

 

Anzeigen:
© 2014 Microsoft