[Dies ist eine Übersetzung des englischsprachigen Artikels „Accessibility of Rich Internet Applications„. Copyright © by www.Webaim.org]
Übersicht
Dieser Artikel liefert einige Techniken und allgemeine Ansätze für die Barrierefreiheit von Rich Internet Anwendungen. Dieser Artikel wird nicht alles vorstellen, was Sie wissen müssen, sondern verschafft ihnen einen allgemeinen Überblick darüber, wie man dynamische und komplexe Skriptinhalte zugänglich macht.
WAI-ARIA (Accessible Rich Internet Applications or ARIA) ist ein W3C-Protokoll zur Verbesserung und Unterstützung der Barrierefreiheit von dynamischen Inhalten und Skriptinhalten. ARIA verbessert die Erreichbarkeit der interaktiven Steuerelemente (wie Baummenüs, Drag & Drop, Schieberegler, Sortiersteuerungen, etc.), bietet Inhalts-Rollen zur Identifizierung der Seitenstruktur (Navigation, Suche, Hauptinhalt, etc.). Bereiche, die dynamisch aktualisiert werden können (so genannten „Live-Regionen“ in Aria), unterstützen die Zugänglichkeit, Interaktivität und vieles mehr für Tastaturen besser.
ARIA wird von den meisten Up-to-date-Browsern und Bildschirmlesegeräten unterstützt. Es wird auch von vielen Skriptbibliotheken unterstützt. Obwohl ARIA noch nicht überall unterstützt wird, wenn es mit bestehenden HTML und zugänglichen Skript-Techniken verwendet wird, kann es zusätzliche Unterstützung der Barrierefreiheit bieten, wenn es doch unterstützt wird und führt nicht zu Kompatibilitätsproblemen, wenn nicht.
Lesen Sie unseren Web-AIM Artikel für mehr allgemeine Informationen zur Zugänglichkeit von JavaScript.
Allgemein können Fragen zur Zugänglichkeit mit Rich Internet Anwendungen charakterisiert werden als:
- Unfähigkeit, eine semantische Struktur und Funktionalität der Seite zu bieten. (z.B. Navigation, Hauptinhalt Suche, etc.)
- Unzugänglichkeit von Inhalten die dynamisch sind und sich innerhalb der Seite verändern können (z.B. AJAX Inhalts-Updates)
- Unfähigkeit, den Tastaturfokus auf Seitenelemente zu legen (z.B. den Fokus auf eine Fehlermeldung auf der Seite legen)
- Schwierigkeiten mit der Zugänglichkeit von Tastaturen und Bildschirmlesegeräten mit komplexen Widgets und Navigationselementen (z.B. Schieber, Baummenüs, etc.)
ARIA kann helfen, viele dieser Probleme zu lösen.
Kernkomponenten
Die drei Hauptkomponenten sind Rollen, Eigenschaften, und Zustände.
Rollen
ARIA-Rollen definieren, was ein Element ist oder tut. Die meisten HTML-Elemente haben eine Standardrolle, die Hilfstechnologien präsentiert wird. Zum Beispiel hat ein Knopf die Standardrolle „Knopf“ und ein Formular hat die Standardrolle „Formular“. Mit ARIA können Sie Rollen definieren, die in HTML nicht verfügbar sind. Sie können auch die Standardrollen von HTML überschreiben. Dies erlaubt ihnen, Elemente und Widgets, in HTML, Screenreadern in einer noch genaueren und zugänglicheren Art anzuzeigen.
Ein Beispiel für eine ARIA-Rolle ist <form role="search">. In HTML haben alle Formulare die gleiche Semantik. Aber mit ARIA können Sie zu der Semantik eines bestimmten Formulars etwas hinzufügen, um es als Suchformular zu definieren.
Eigenschaften
ARIA-Eigenschaften… naja, Eigenschaften oder Bedeutungen der Elemente. Sie können die native HTML-Semantik erweitern, indem Sie Eigenschaften für Elemente definieren, die in Standard-HTML nicht erlaubt sind. Ein Beispiel ist <input aria-required="true">. Diese Eigenschaft will Screenreader dazu veranlassen, diese Eingabe als erforderlich zu lesen (Das bedeutet, dass der Nutzer dies ausfüllen muss).
Zustände
ARIA-Zustände sind Eigenschaften, die den aktuellen Zustand eines Elementes definieren. Sie ändern sich in der Regel bei Benutzerinteraktion, oder basierend auf einer dynamischen Variablen. Ein Beispiel ist <input aria-disabled="true">. Diese Eigenschaft wird einen Screenreader dazu veranlassen, den Input als deaktiviert zu lesen, aber dieser Zustandswert könnte, dynamisch auf Benutzereingaben basierend, einfach zu false (falsch) verändert werden.
ARIA-Rollen, Zustände und Eigenschaften können im Markup definiert, oder mit Hilfe von Scripting definiert und dynamisch festgelegt und geändert werden. ARIA-Zustände und Eigenschaftsattribute beginnen immer mit „aria-“ (z.B. aria-required="true").
Landmark-Rollen
Bei aktuellen Versionen von HTML und XHTML, gibt es keinen Mechanismus zur Identifikation der Funktion oder des Zwecks von Seitenelementen in einer programmatisch bestimmbaren Weise (dies ist eine raffinierte Art zu sagen „in einer Weise, in der es der Computer herausfinden kann“). Mit anderen Worten, Sie können, Hauptinhalt, Navigation, Suche, etc., in ihrem Code nicht identifizieren. Während Sie eine klare Überschriftenstruktur in ihrem Dokument nutzen können und sollten, liefert dies keine Standardmethode für Nutzer, auf die semantische Rolle von Seitenelementen zuzugreifen oder diese festzustellen.
Dieses Problem wird durch die Notwendigkeit von „Direkt zum Hauptinhalt„- oder „Navigation überspringen“-Links. Weil ein Browser oder Screenreader keine Möglichkeit hat, zu wissen, welcher Teil der Seite die Navigationselemente beinhaltet, ist es für Seitenautoren wichtig, einen spezifischen Link zu erstellen, der es Tastaturnutzern erlaubt, solche Links zu überspringen. Auch ein direkter Zugriff auf häufig genutzte Funktionen der Seite, wie die Suche, erfordert, dass der Nutzer durch die Seite blättern, oder die Seite durchhören kann, um sie zu finden oder zu entdecken.
WAI-ARIA bietet für Entwickler die Möglichkeit, die Rollen für Dokumentbereiche (und viele andere Dinge) zu spezifizieren. Die verfügbaren Dokumentlandmark-Rollen sind:
Banner- Webseiten-orientierter Inhalt, wie den Namen der Webseite, den Titel der Seite und/oder das Logo.
Navigation- Der Bereich, der die Navigationslinks für das Dokument oder die Webseite enthält.
Hauptteil- Der Hauptinhalt oder der zentrale Inhalt des Dokuments.
Suche- Dieser Abschnitt enthält die Suchfunktionalität für die Webseite.
Artikel- Alleinstehende Inhalte die, wegen dem Kontext vom Rest des Dokuments, Sinn machen. Beispiele können Blog-Posting, ein Kommentar auf einem Blog, ein Forumsbeitrag, etc. sein. Insbesondere könnte ein Blog-Posting als ein Artikel identifiziert werden und individuelle Blog-Kommentare könnten für eine Rolle eines Artikels in diesem Blog-Posting markiert werden.
Ergänzungen- Unterstützende Inhalte für den Hauptinhalt.
Inhaltsinfos- Informative Kinderinhalte, wie Fußnoten, Urheberrechte, Links zu Datenschutzerklärungen, Links zu Präferenzen und so weiter.
Auf einer Seite, können das Logo und der Headerinhalt die Rolle des Banners bekommen. Die Navigations-Registerkarten oben würden als Navigation identifiziert werden. Das Suchformular der Seite würde natürlich <form role=search> erhalten. Die weiterführenden Links in einer Seitenleiste könnten als Ergänzungen identifiziert werden. Der Hauptkörper eines Artikels wäre der Hauptteil. Die Fußzeile und Links am unteren Rand der Seite hätten die Rolle Inhaltsinfo.
Die meisten Seiten können jetzt zumindest ein paar Landmark-Rollen anwenden – <ul role="navigation"> oder <div role="main"> oder <form role="search">. Diese Funktion von AIRA ist nicht auf Rich Anwendungen beschränkt, sondern kann auf fast allen aktuellen Webseiten verwendet werden.
Hilfstechnologien bieten Tastenkombinationen, um durch Elemente zu navigieren, die als Landmarks definiert sind, oder um eventuell zu bestimmten Strukturelementen (zum Beispiel S für Suche) zu springen und/oder bieten eine Liste aller Strukturelemente des Dokuments. Zusätzlich bietet ARIA neue Rollen für andere Typen von Elementen, wie role="presentation" für Tabellen, die im Layout verwendet werden. Es erlaubt ihnen auch, erforderliche Formularelemente zu identifizieren, eine bessere Etikettierung und Beschreibung des Formulars zu bieten und ein sofortiges Feedback an Screenreader-Nutzern zu liefern.
Dynamische Inhaltsupdates
Wenn der Inhalt sich dynamisch innerhalb einer Webseite verändert, kann es zu Problemen der Zugänglichkeit führen. Was passiert, wenn ein Screenreader grade ein Element liest, das aktualisiert wird? Wenn der aktualisierte Inhalt wichtig ist, sollten Sie den Nutzer unterbrechen und den Fokus sofort auf den neuen Inhalt setzen, informieren Sie einfach den Nutzer über das Update informieren, oder tun Sie nichts? Wie setzen Sie den Fokus, oder erlauben Sie dem Nutzer, zu dem aktualisierten Inhalt zu springen?
Mit Standard-Scripting muss der Entwickler diktieren, was passiert, wenn ein Inhalts-Update auftritt, wie eine AJAX-geführte Rückmeldung. Der Entwickler kann dem Update einfach erlauben aufzutreten und den Nutzer nicht darüber informieren, den Nutzer mit einem eingebetteten Audio-Sound auf die Aktualisierung aufmerksam machen, oder den Fokus direkt auf den aktualisierten Inhalt setzen. Der Entwickler muss jede dieser Situationen schriftlich ausarbeiten, also die Kontrolle vom Nutzer entfernen.
Mit WAI-ARIA können Entwickler Regionen identifizieren, die sich dynamisch wie eine Live-Region verändern. Eine Live-Region erlaubt Inhaltsupdates in einer Weise, die ein Screenreader versteht. Es erlaubt dem Nutzer auch, zusätzliche Funktionalität hinzuzufügen, um den Nutzer zu warnen, bietet Steuerungen für die Live-Regionen, bestimmt die Menge an neuem Inhalt, die gelesen wird und vieles mehr.
Um eine Live-Region zu schaffen, fügt der Entwickler die ARIA-Live-Eigenschaft zu einem Element mit einem Wert von off, polite, assertive oder rude hinzu. Der Wert oder das Höflichkeitslevel (oder alternativ das Aufdringlichkeitslevel) spezifiziert, was ein Screenreader tun soll, wenn das Element aktualisiert wird.
Der Wert off (aria-live="off") sagt dem Screenreader, das Update nicht bekannt zu geben. Falls der Screenreader-Nutzer auf den aktualisierten Inhalt stößt, wird es dann vorgelesen. Dies wird für unwichtige oder irrelevante Inhaltsupdates verwendet.
Der Wert polite wird den Nutzer über die Veränderung des Inhalts benachrichtigen, sobald er/sie die aktuelle Aufgabe erledigt hat. Dies kann in Form eines Signaltons oder eines Audiosignals auf das Update hinweisen. Der Nutzer kann dann wählen, ob der direkt zu dem aktualisierten Inhalt springen möchte. Dieser Wert wäre der häufigste für Inhaltsupdates, besonders für Dinge wie Statusbenachrichtigungen, Wetter- oder Aktienupdates, Chat-Nachrichten, etc.
Der ARIA-Live Wert assertive wird darin enden, dass der Nutzer über die Inhaltsveränderung sofort oder so schnell wie möglich alarmiert wird. Assertive wird für wichtige Updates, wie Fehlermeldungen verwendet.
Sie können auch definieren, welche Inhalte gelesen werden, wenn ein Update auftritt. Darüber hinaus gibt es spezielle ARIA-Rollen, die bestimmte Arten von hoch dynamischen Inhalten definieren, wie Warnungen, Protokolle und Timer. Das hohe Niveau der Treue von ARIA-Live-Regionen, ermöglicht eine große Flexibilität, sowohl für Entwickler, wie auch für Endanwender.
Verbesserung der Zugänglichkeit für Tastaturen
In HTML können nur Links und Formularelemente den Tastaturfokus erhalten. Das bedeutet, wenn Sie sich mit der Tab-Taste durch die Seite arbeiten, stoppt der Browser, oder setzt den Fouks nur auf dieser Art von Elementen. Mit Scripting aber können Sie Mausinteraktivitäten auf fast jedes Element legen. Das bedeutet, Sie können normale Seitenelemente, wie Absätze oder Spannen, interaktiv und reagierend auf die Maus machen (z.B. können Sie Klartexte anzeigen und sich wie einen Knopf verhalten lassen). Die Funktionalität dieser nicht-fokussierbaren Elemente kann nicht für Screenreader- und nur Tastatur-Nutzer zugänglich gemacht werden. Entwickler benötigen es oft, dass Seitenelemente interaktiv sind, anders als bei Links und Formularelementen.
Darüber hinaus ist es oft notwendig, den Fokus auf Seitenelemente zu setzen. Zum Beispiel könnte eine Fehlermeldung der Formularvalidierung als Text (nicht als ein Link oder Formularelement) angezeigt werden. Sehende Nutzer können die Fehlermeldung sofort sehen. Jedoch kann ein Screenreader-Nutzer nicht wissen, dass eine neue Nachricht vorhanden ist. Damit der Fokus auf die Fehlermeldung gesetzt werden kann und sie von einem Screenreader gelesen werden kann, muss die Nachricht in der Lage sein, den Fokus zu erhalten – etwas, was sie normalerweise nicht tun kann, es sei denn sie ist ein Link oder Formularsteuerelement.
ARIA bietet wieder Mechanismen für nicht-fokussierbare Elemente, um den Fokus durch die Tabindex-Eigenschaft zu erhalten. (Sehen Sie sich unseren verwandten Artikel über Tabindex an). ARIA erweitert die Tabindex-Eigenschaft, sodass es auf jedes Element angewendet werden kann. Indem der Tabindex-Wert auf 0 gesetzt wird (tabindex="0"), wird ein Element in die Tab-Reihenfolge des Dokuments gesetzt. Dies bedeutet, dass der Browser stoppen wird und den Fokus auf das Element in der Navigationsreihenfolge des Dokuments setzt (z.B. wenn der Nutzer mit der Tab-Taste zu dem Element gelangt). Dies erlaubt zusätzliche Funktionalität und Interaktivität, die auf das Element angewendet werden kann, wie Funktionalität auslösen, wenn das Element den Tastaturfokus erhält, oder wenn der Nutzer eine Taste drückt, während das Element den Fokus hat.
Ein Tabindex-Wert von -1 erlaubt einem Element, den Fokus zu erhalten, aber nur wenn der Fokus programmatisch festgelegt ist – was bedeutet, dass der Nutzer einen Link zu dem Element aktiviert (<a href="#maincontent"> ...), oder, dass der Fokus mit Scripting gesetzt wurde (z. B. document.getElementById('errormessage').focus();).
Durch die Erweiterung der Fokus-Funktionen im Web-Browser auf Elemente, die andernfalls nicht den Fokus erhalten könnten, erlaubt ARIA zusätzliche Möglichkeiten, um Zugänglichkeit zu bieten.
Barrierefreiheit für Widgets
Der Begriff „Widget“ wird allgemein verwendet, um interaktive Elemente zu beschreiben, die mit Scripting erstellt und kontrolliert werden. Es bezieht sich auf Kontrollen, die nicht ursprünglich in HTML oder in HTML-Kontrollen gegeben sind, die durch Scripting stark verbessert worden sind. Beispiele von Widgets wären Schieber, Drop-Down- und Fly-out-Menüs, Baumsysteme, Drag&Drop-Steuerungen, auto-vervollständigende Textfelder und Tooltip-Fenster, um einige zu nennen. Die Barrierefreiheit von Widgets entsteht nicht ursprünglich oder natürlich. HTML hat nur ein sehr begrenztes Markup, um komplexe Widgets zu definieren.
Während Scripting oft Zugänglichkeit für viele dieser Elemente bieten kann, wird es oft in unterschiedlicher Weise realisiert. Kurz gesagt, ist es oft möglich, diese Widgets für Tastaturen und Screenreader zugänglich zu machen, aber es ist ziemlich schwierig und das Ergebnis ist oft nur geringfügig zugänglich für praktische Zwecke. Wie machen Sie ein komplexes Menü-System intuitiv zugänglich für Tastaturen? Wie machen Sie ein drag&drop-Element zugänglich für Tastaturen? Wie präsentieren Sie Sortierkriterien für sortierbare Listenitems? Wie präsentieren Sie blinden Nutzern visuelle Tooltips oder Pop-up-Nachrichten?
Durch die Festlegung von Standard-Sets von Rollen, Eigenschaften und Werten erlaubt ARIA den Entwicklern, die Fragen zur Barrierefreiheit mit relativer Leichtigkeit anzugehen.
Das Folgende bietet einige sehr grundlegende Beispiele, wie ARIA umgesetzt werden könnte.
: (benötigt)
<label for="name">Vorname</label>: <input name="name" id="name" aria-required="true"> <em>(benötigt)</em>
Dieses Eingabefeld demonstriert ein verbreitetes Problem – das Formularelement wird benötigt, aber das Wort „benötigt“ ist nicht im Label für das Formularelement enthalten und wird somit wahrscheinlich nicht von einem Screenreader ausgesprochen. aria-required="true" von ARIA wird ein Bildschirmlesegerät darauf hinweisen, dass das angegebene Formularelement benötigt wird.
ARIA ändert in der Regel nicht die Funktionalität der Seite. In dem obigen Beispiel würde das aria-required-Attribut nicht irgendwie erzwingen, dass der Nutzer etwas in die Textbox eingibt. Stattdessen wird der Nutzer einfach informiert, dass das Feld erforderlich ist.
Knopf-Beispiel
Das Folgende ist ein Textelement (nicht ein tatsächlicher HTML-Button), der mit der Tastatur angeklickt oder aktiviert werden kann (Springen Sie mit der Tab-Taste bis zu dem Knopf und drücken Sie Enter oder die Leertaste).
Klick mich
<span style="background-color: #ddd; border: medium outset white;" role="button" tabindex="0" onkeydown="if(event.keyCode==13 || event.keyCode==32) alert('Sie haben mich mit der Tastatur aktiviert');" onclick="alert('Sie haben mich mit der Maus angeklickt');">Push Me</span>
In diesem Beispiel wird der Text so gestylt, dass er visuell wie ein Knopf erscheint. Das role="button" sagt dem Browser, dass der Text sich wie ein Knopf verhalten soll. tabindex="0" stellt das Element in den Tastatur-Navigationsfluss, damit Nutzer den Knopf aktivieren können. Der onkeydown-Event-Handler erkennt, ob der Nutzer Enter oder die Leertaste gedrückt hat, während das Element fokussiert wird. Während dieses Beispiel ein Wenig gekünstelt ist (Warum nicht einfach einen tatsächlichen Knopf nutzen?), demonstriert es die Möglichkeit von ARIA, eine Semantik und zugängliche Interaktivitäten zu einem Element hinzuzufügen.
Beispiel für die Formularvalidierung
In diesem Beispiel, eingeben, um dem Browser zu erlauben, auf andere Teile der Seite zu navigieren.
Da der Tastaturfokus nach einer falschen Antwort mit JacaScript zurück zum Formularelement gesetzt wird, wird die Rückmeldung nicht von einem Screenreader gelesen. In diesem Fall erhält die Fehlermeldung role="alert", wenn sie angezeigt wird. Dies bewirkt, dass die Rückmeldung sofort vom Screenreader gelesen wird. Der Nutzer kann nun erneut versuchen, die Antwort mit dem entsprechenden Feedback einzugeben. Sobald die richtige Antwort eingegeben ist, wird der Fokus auf den Text gelegt, der unmittelbar folgt (welcher tabindex="0" erhalten hatte, damit er den Fokus erhalten kann, eher der Fokus auf das nächste Formularelement oder den nächsten Link der Seite springt).
Für komplexere und individuell gebaute Widgets definiert ARIA Standardattibute und Tastaturinteraktionsmuster, den gefolgt werden muss. Achten Sie darauf, den standardisierten ARIA-Designmustern Folge zu leisten.
Fazit:
Diese Beispiele demonstrieren nur einige grundlegende Wege, auf die ARIA jetzt implementiert werden kann, um die Zugänglichkeit von interaktiven Elementen zu verbessern. ARIA unterstützt jedoch viele verschiedene Typen von Widgets und Interaktionen. Für komplexe Widgets und Interaktionen ist es sehr wahrscheinlich, dass ein Entwickler, anstatt von Grund auf alles neu zu bauen, die Scripting Bibliotheken nutzen wird, um solche Elemente zu kreieren. Glücklicherweise ist ARIA in vielen Scripting-Bibliotheken implementiert (wie in jQuery, Dojo, YUI, und GWT). Während Entwickler ARIA sicherlich in ihren fortgeschrittenen Widgets und Anwendungen umsetzen, vereinfachen ARIA unterstützende Bibliotheken den Prozess der Bereitstellung des Zugänglichkeitsniveaus stark.
ARIA kann nicht alle Fragen zur Barrierefreiheit lösen und es kann ein bisschen schwierig zu implementieren sein, aber es bietet deutlich höhere Level der Barrierefreiheit, als derzeit mit HTML und Scripting allein möglich ist. Als Unterstützung in Browsern steigen Hilfstechnologien und Scripting-Bibliotheken an. ARIA wird ein großartiges Werkzeug für die Sicherstellung der Barrierefreiheit für Rich Internet Inhalte und Anwendungen.