Ü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.

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.

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.

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.