ARIA: Anwendungsrolle

Die application Dokumentenstrukturrolle, zeigt assistiven Technologien an, dass dieser Teil des Webinhalts Elemente enthält, die keinem bekannten HTML-Element oder WAI-ARIA-Widget entsprechen. Jegliche spezielle Interpretation von HTML-Strukturen und Widgets sollte ausgesetzt werden, und die Steuerung sollte vollständig an den Browser und die Webanwendung übergeben werden, um Maus-, Tastatur- oder Berührungsinteraktionen zu handhaben.

In diesem Modus ist der Webautor vollständig verantwortlich für die Handhabung aller Tastatureingaben, das Fokusmanagement und andere Interaktionen und kann nicht davon ausgehen, dass assistive Technologien irgendwelche Verarbeitung ihrerseits durchführen.

Wenn die von der Anwendungsrolle umfasste Webanwendung Teile enthält, die wie normaler Webinhalt behandelt werden sollten, sollte eine Rolle von document oder article verwendet werden, um solche Inhalte zu enthalten.

Aus historischen Gründen haben insbesondere auf Windows Screenreader und einige andere assistive Technologien (AT) traditionell den gesamten Webinhalt vom Browser auf einmal erfasst, nachdem er fertig geladen ist. Die ATs erstellen ihre eigene Repräsentation davon, die am meisten Sinn für einen sehbehinderten Nutzer macht, um den Inhalt zu konsumieren. Dies wird oft als virtuelles Dokument, Browse-Modus oder ähnliche Begriffe bezeichnet. Das Dokument wird in einer Einzelspaltenansicht vereinfacht. Es wird ein Tastatur-Interaktionsmodell erstellt, das sehr ähnlich wie in einem Textverarbeitungsprogramm ist, wo Benutzer Zeile für Zeile, Satz für Satz oder Absatz für Absatz lesen können. Das AT liest alle Semantik wie Links, Überschriften, Formulare, Tabellen, Listen oder Bilder.

Zusätzlich wurde im Laufe der Jahre eine Reihe sogenannter Schnellnavigationstasten etabliert, die es sehbehinderten Nutzern ermöglichen, eine Seite über einen bestimmten Elementtyp zu überfliegen. Solche Elemente umfassen normalerweise Überschriften, Formularfelder, Listen, Tabellen, Links, Grafiken oder Regionsmarkierungen.

Damit all dies funktioniert, fangen ATs fast alle Tastatureingaben ab und verbrauchen sie selbst, ohne sie an den Browser oder andere Benutzeragenten weiterzuleiten. Um mit einer Webseite interagieren zu können, wird eine Standardreihe von Widgets erkannt, bei denen der Druck einer bestimmten Taste (meistens die Enter-Taste) diesen Modus ausschaltet. Der Screenreader-Modus, oft Formularmodus oder Fokusmodus genannt, lässt alle Tastatureingaben wieder an den Browser durch. Escape ist der gebräuchlichste Weg, um in den Browse-Modus zurückzukehren, aber bei einem bestimmten application-Abschnitt erfordern einige Screenreader möglicherweise andere Tasten, um diesen Modus absichtlich zu verlassen. Zum Beispiel NUMPAD PLUS mit JAWS.

Die application-Rolle ist dafür gedacht, eine Möglichkeit für Widgets bereitzustellen, die nicht Teil des Standardsatzes sind, um in ATs, die sowohl den Browse- als auch den Fokus-Modus verwenden, direkt interagierbar zu sein. Die meisten gängigen Widgets haben erwartete Tastatur-Interaktionsverhalten. Aufgrund dessen würde eine vom Webautor erstellte benutzerdefinierte Tastaturerfahrung zu einer verwirrenden Erfahrung führen.

document, article

Wird verwendet, um Teile der Anwendung anzugeben, die als normaler Webinhalt behandelt werden sollen

aria-activedescendant

Wird verwendet, um den Fokus innerhalb der Anwendung zu verwalten.

aria-label

Wird verwendet, um den Namen der Anwendung oder den Zweck des Widgets anzugeben, das dargestellt wird.

aria-describedby

Verweist auf die ID eines Elements, das zusätzliche Anweisungen zum Navigieren oder Bedienen dieses Elements enthält.

aria-roledescription

Wird verwendet, um eine beschreibendere Rollentext für Screenreader anzugeben. Dies sollte lokalisiert werden.

aria-disabled

Gibt an, dass ein Element sichtbar, aber deaktiviert ist.

aria-errormessage

Ein Verweis auf das Element, das die Fehlermeldung für das Element bereitstellt, auf das es gesetzt ist.

aria-expanded

Wenn auf true gesetzt, ist das Gruppenelement, das von diesem Element besessen oder kontrolliert wird, erweitert, oder false, wenn es eingeklappt ist.

aria-haspopup

Gibt an, dass ein Popup, wie ein Menü oder Dialog, durch das Element ausgelöst werden kann.

Die Tastaturinteraktion liegt vollständig in der Kontrolle des Webautors und kann alles sein, was mit dem speziellen Widget verbunden ist, das implementiert wird. In einer Folienanwendung könnte zum Beispiel ein Widget erstellt werden, das die Pfeiltasten verwendet, um Elemente auf der Folie zu positionieren, und das Audiowiedergabe über einen ARIA-Livebereich zur Kommunikation der Position und Überlappungsstatus mit anderen Objekten nutzt. Der Fokus wird über aria-activedescendant verwaltet.

Die Tasten Tab, Space und Enter sowie Escape müssen von der Anwendung gehandhabt werden. Eine Ausnahme ist, wenn der Fokus auf ein Standard-Widget innerhalb der Anwendung gesetzt wird, das Tastaturnavigation vom Browser unterstützt, zum Beispiel ein input-Element.

keyPress

Wird verwendet, um Tastatureingaben zu verarbeiten und den Fokus zu steuern.

Click, Touch

Nach Bedarf für Ihr Widget behandeln.

Ändern von Attributwerten

aria-activedescendant wird verwendet, um den Fokus innerhalb des Anwendungskontexts zu verwalten. Wird als Reaktion auf Tastatur- oder andere Anwendungsereignisse gesetzt, die den Fokus oder den Interaktionspunkt ändern.

Einige prominente Webanwendungen, die die Anwendungsrolle ordnungsgemäß verwenden oder verwendet haben, sind:

• Google Docs, Tabellen und Präsentationen
• CKEditor und TinyMCE WYSIWYG-Webeditoren, wie der auf dem Mozilla Developer Network verwendete
• Einige Teile von Gmail

Das falsche Verwenden der application-Rolle kann unbeabsichtigt den Zugang zu Informationen auf einer Webseite beeinträchtigen, seien Sie daher sehr aufmerksam beim Gebrauch. Überlegen Sie genau, ob Sie sie wirklich benötigen und nicht einfach eine Reihe anderer bekannter Widgets verwenden können, um dieselbe Aufgabe zu erfüllen.

Wenn verwendet, sollte die Anwendungsrolle dem kleinstmöglichen gemeinsamen Container hinzugefügt werden, nicht auf das <body>-Element. Stellen Sie außerdem sicher, dass Sie das Geschriebene mit assistiver Technologie testen, um zu überprüfen, ob es wie beabsichtigt funktioniert.

Die Anwendung der application-Rolle wird dazu führen, dass dieses und alle Nachkommenelemente dieses Elements wie Anwendungskontent behandelt werden und nicht wie Webinhalt. Jegliche Leseverfahren, die assistive Technologien möglicherweise für Webinhalte haben, werden nicht angewendet.

• Wenn Sie die WAI-ARIA-Rolle application verwenden, tun Sie dies bitte weise - Blogbeitrag von Marco Zehe
• Die Verwendung der ARIA application-Rolle - von Léonie Watson