Erstellen von Benutzeroberflächen mit semantischem Markup
Lernziele
Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
- Erklären, warum semantisches Markup notwendig ist, um Inhalte barrierefrei zugänglich zu gestalten
- Definieren der drei Typen von Attributen in ARIA
Einführung
Bei der Erstellung barrierefreier Benutzeroberflächen spielen viele Faktoren eine Rolle. Im Allgemeinen gilt: Je komplexer die Benutzeroberfläche, desto mehr Faktoren müssen berücksichtigt werden. Bei einem einfachen Blog-Post oder Nachrichtenartikel sind in Bezug auf Barrierefreiheit beispielsweise weniger Überlegungen anzustellen als bei einem Nachrichtenartikel mit Kommentaren, Funktionen für soziale Medien oder anderen interaktiven Elementen. Für eine komplexe Webanwendung, wie z. B. einen Berichts- oder Dashboard-Generator, einen Seitenlayout-Editor oder sogar eine Listenansicht im Kanban-Stil, gelten hinsichtlich Barrierefreiheit noch höhere Anforderungen.
Je komplexer die Webseite oder Anwendung ist, desto mehr müssen Sie unternehmen, um sicherzustellen, dass sie für Benutzer mit Behinderungen barrierefrei ist. Damit jedoch eine Webseite oder Anwendung barrierefrei wird, müssen wir bei den Grundlagen beginnen.
Semantisches Markup
Semantisches Markup ist die Basis sämtlicher Barrierefreiheit. Der Inhalt einer Webseite sollte mit Markup dargestellt werden, das die Art des dargestellten Inhalts abbildet. Zum Beispiel sollten tabellarische Daten mit <table>
-basiertem Markup und Listen mit <ul>
-basiertem Markup dargestellt werden. Für visuelle Überschriften sollten heading-Tags verwendet werden usw.
Semantisches Markup macht Inhalte für Computer und Software, insbesondere für Hilfstechnologien, lesbar und verständlich, was für die Barrierefreiheit von Inhalten notwendig ist. Ein blinder Benutzer kann mit einem Bildschirmleseprogramm in einem Berichtsgenerator navigieren, der mit ordnungsgemäß geformten HTML-Elementen des Typs <table>
erstellt wurde. Derselbe Benutzer kann jedoch nicht einwandfrei navigieren oder denselben Sachverhalt bei einem Markup mit <div>
-Elementen verstehen, auch wenn er für sehende Benutzer gleich aussehen mag.
Die HTML-Struktur von Webseiten und Anwendungen verleiht ihren Inhalten Bedeutung für Hilfstechnologien und Benutzer, die auf Hilfstechnologien angewiesen sind. Wir empfehlen Ihnen, nach Möglichkeit semantische HTML5-Elemente zu verwenden und Ihr Markup mit einem Prüfprogramm wie Nu HTML Checker zu überprüfen.
Erste Schritte mit ARIA
ARIA ist das Akronym von Accessible Rich Internet Applications und eine HTML-Erweiterung, die berücksichtigt, dass Webseiten für viel mehr als nur für Markup- oder Anzeigezwecke verwendet werden. ARIA versteht, dass das Web eine Plattform für die Realisierung komplexer Anwendungen ist und Optionen bietet, um Benutzern mit Behinderungen mittels Hilfstechnologien eine viel fortschrittlichere Interaktion zu ermöglichen.
Die Funktionsweise von ARIA beruht auf der Zuweisung spezieller Attribute zu HTML-DOM-Knoten. In ARIA gibt es drei Arten von Attributen: Rollen, Zustände und Eigenschaften.
Rollen
Rollen sind eine Möglichkeit, HTML-Elementen eine semantische Bedeutung zu geben, die üblicherweise keine haben, wie z. B. <div>
oder <span>
. Beispielsweise können Sie mithilfe von ARIA-Rollen verschiedene nicht semantische Elemente wie Schaltflächen oder Links oder sogar komplexere Komponenten wie Menüs, Kombinationsfelder, modale Elemente oder interaktive Raster identifizieren.
Rollen sind eine Zusicherung an Benutzer. Wenn Sie einem Element eine ARIA-Rolle hinzufügen, beispielsweise role="button"
einem <div>
-Element hinzufügen, weisen Sie das <div>
-Element an, sich selbst als Schaltfläche zu identifizieren. Dieses <div>
-Element wird nun in der Barrierefreiheitsstruktur des Browsers als <button>
(Schaltfläche) angezeigt. Die Barrierefreiheitsstruktur des Browsers ist eine Momentaufnahme der Informationen, die dem Bildschirmleseprogramm präsentiert werden. Dies bedeutet, dass Sie auch die gesamte Funktionalität, die eine Schaltfläche nativ aufweist, diesem <div>
-Element bereitstellen müssen. Dazu gehören Fokuszustände, Tastatur- und Mausinteraktivität usw. Wenn Sie ein <div>
-Element Schaltfläche nennen, es aber nicht wie eine Schaltfläche funktionieren lassen, halten Sie die Zusicherung gegenüber Ihren Benutzern nicht ein.
Zustände
Zustände sind Attribute, die den Status einer ARIA-Komponente in der Barrierefreiheitsstruktur eines Browsers beschreiben. Ein Zustand beschreibt, ob ein Dropdown-Menü aufgeklappt
ist oder nicht, ob sein Eingabetyp deaktiviert
oder schreibgeschützt
ist, ob ein Kontrollkästchen aktiviert
ist, ob ein Element in einem Listenfeld ausgewählt
ist usw. Beim Erstellen komplexer Komponenten mithilfe von ARIA ist es von entscheidender Bedeutung, die verschiedenen Zustände über einen Vorgang eines Steuerelements richtig zu aktualisieren. All dies ist Teil der Einhaltung der Zusicherung gegenüber Benutzern, die Sie bei der Verwendung eines Rollenattributs gegeben haben.
Eigenschaften
Das W3C definiert ARIA-Eigenschaften als "Attribute, die für das Wesen eines bestimmten Objekts unerlässlich sind oder die einen mit dem Objekt verbundenen Datenwert darstellen". Dies sind Attribute, die das Wesen eines Objekts beschreiben. Beachten Sie den Unterschied zwischen einem <select>
-Element mit dem Attribut multiple
und einem <select>
-Element ohne das Attribut multiple
. Ersteres ist ein Kombinationsfeld, in dem eine Mehrfachauswahl möglich ist, während bei Letzterem ein Benutzer auf den zusammengeklappten Zustand klicken muss, um das Feld zu öffnen und ein einzelnes Element auszuwählen. In diesem Fall ist multiple
eine Eigenschaft unseres nativen <select>
-Elements.
In gleicher Weise weist ARIA viele Eigenschaftsattribute auf, die zur Beschreibung von Objekten dienen, sich aber nicht unbedingt regelmäßig ändern, um den Zustand eines Objekts zu aktualisieren.
Die Fragen, welche ARIA-Attribute wann und wie verwendet werden, können schwierig zu beantworten sein. Generell sollten Sie unsere Komponentenentwürfe im Salesforce Lightning Design System (SLDS) befolgen. SLDS enthält über 900 HTML-Entwürfe mit detaillierten Leitlinien zur Barrierefreiheit von Markup, Attributen und Tastaturinteraktionen. Diese Entwürfe enthalten alle erforderlichen ARIA-Rollen, -Eigenschaften und -Zustände an den richtigen Stellen. Darüber hinaus enthalten unsere Entwürfe Informationen zur Barrierefreiheit, in denen detailliert beschrieben wird, wie Zustände und Eigenschaften der Komponenten, die Sie erstellen, richtig zugeordnet und verwaltet werden können.
ARIA in SLDS-Komponentenentwürfen wurde mit Hilfstechnologie getestet und basiert auf dem ARIA Authoring Practices Guide. Dieses Dokument wird regelmäßig aktualisiert und ist die aktuelle Informationsquelle für ARIA und viele gängige Entwurfsmuster.
In den SLDS-Komponentenentwürfen finden Sie möglicherweise nicht alle Interaktionsmuster, die Sie benötigen. Für alles, was Sie in unserem Entwurfssystem vermissen, konsultieren Sie den ARIA Authoring Practices Guide und die ARIA-Spezifikation als solche. Vertrauen Sie nichts anderem im Internet, denn dort finden Sie über lange Jahre gesammelte Ideen, Erkundungen und einfach nur schlechte, nicht barrierefreie Komponenten, die sich als moderne, barrierefreie Lösungen tarnen.
Nachdem Sie sich mit den Grundlagen der Erstellung barrierefreier Benutzeroberflächen vertraut gemacht haben, wollen wir nun die barrierefreie Navigation erkunden.
Ressourcen
- Dokumentation: ARIA Authoring Practices Guide
- Dokumentation: Accessible Rich Internet Applications (WAI-ARIA)
- Tool: Nu HTML Checker
- Salesforce-Hilfe: Salesforce Lightning Design System