Schreiben barrierefreier Komponenten

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

• Bestimmen der im Lightning-Komponenten-Framework enthaltenen Komponentengruppen
• Auflisten der Schritte zum Entwickeln barrierefreier Komponenten
• Bestimmen der Schritte zum Erstellen benutzerdefinierter Webkomponenten

Einführung

Das Lightning-Komponenten-Framework bietet Ihnen eine Reihe voll funktionsfähiger Komponenten. Diese basieren alle auf den neuesten SLDS-Komponentenentwürfen, die den relevanten Leitlinien für Barrierefreiheit folgen. Nutzen Sie nach Möglichkeit diese vorhandenen Komponenten. Sie wurden hinsichtlich Barrierefreiheit geprüft und ersparen Ihnen eine Menge zusätzlicher Arbeit. In der Referenz zu Komponenten erfahren Sie mehr zu diesen Komponenten. 

Verwenden von Komponenten

Die Referenz zu Komponenten enthält Informationen zu zwei Arten von Komponenten, nämlich Aura-Komponenten und Lightning-Webkomponenten. Die aufgeführten Aura-Komponenten gehören zu vielen verschiedenen Namespaces. Komponenten in den Namespaces ui und force wurden entwickelt, um einer älteren ARIA-Spezifikation zu entsprechen, und sind nicht mehr die verfügbaren Komponenten mit der größten Barrierefreiheit. 

Lightning-Webkomponenten sind die bevorzugte Methode zur Erstellung von Benutzeroberflächen mit Salesforce. Wechseln Sie zum Modul Migrieren von Aura zu Lightning-Webkomponenten, um zu erfahren, wie Sie Lightning-Webkomponenten verwenden und aktuelle Webstandards einhalten können. Falls Sie mehr Informationen über Aura benötigen, sehen Sie sich das Entwicklerhandbuch zu Lightning Aura-Komponenten oder die Dokumentation zu Aura-Komponenten an. 

Lightning-Webkomponenten mit dem Präfix lightning entsprechen dem neuesten ARIA-Standard und folgen den neuesten SLDS-Komponentenentwürfen. Verwenden Sie nach Möglichkeit diese Komponenten anstelle älterer Alternativen. 

Wenn Sie Lightning-Komponenten einsetzen, müssen Sie Barrierefreiheit weiterhin im Auge behalten. Wenn Sie z. B. ein Informationssymbol mit <lightning-icon> platzieren, müssen Sie weiterhin einen geeigneten Wert für alternative-text angeben, damit Benutzer den Zweck des Symbols verstehen. Wenn Sie <lightning-input> verwenden, müssen Sie weiter label angeben, um die resultierende <input> (Eingabe) programmgesteuert mit <label> (Bezeichnung) zu verknüpfen. Durch Festlegung von required="true" wird die Eingabe auf barrierefreie Weise erforderlich gemacht.

Viele Lightning-Komponenten haben auch Attribute, um ARIA-Eigenschaften festzulegen. Obwohl diese für Barrierefreiheit vielleicht nicht erforderlich sind, führen wir sie auf, falls Sie diese Werte festlegen müssen. 

Erstellen von Komponenten

Wenn Sie die von Ihnen benötigte Komponente nicht in unserer Komponentenreferenz finden, müssen Sie möglicherweise Ihre eigene Lightning-Komponente entwickeln. Wenn Sie dies tun, gehen Sie wie folgt vor, um sicherzustellen, dass Barrierefreiheit gegeben ist.

1. Beginnen Sie stets mit den SLDS-Komponentenentwürfen. Erkunden Sie aufmerksam das Markup und die ARIA-Rollen, -Zustände und -Eigenschaften. Notieren Sie alle erforderlichen Attribute und Attribute, die sich ändern, wenn ein Benutzer mit Ihrer Komponente interagiert.
2. Implementieren von Tastaturinteraktionen. Denken Sie daran, dass ARIA Rollen eine Zusicherung an Ihre Benutzer sind. Diese Zusicherung umfasst die Bereitstellung der Tastaturfunktionalität, die Benutzer für die von Ihnen angegebene Rolle erwarten. Unsere Komponentenentwürfe enthalten Anweisungen für die Tastaturnavigation.

Tipp: Achten Sie nicht auf Betätigungsereignisse für die TAB-Taste, sondern auf den Fokus. Benutzer von Bildschirmleseprogrammen nutzen selten die TAB-Taste zum Navigieren auf einer Seite.

• Verwalten des Benutzerfokus Befolgen Sie unsere globalen Leitlinien für den Fokus, um sicherzustellen, dass interaktive Elemente fokusfähig sind.
• Programmieren Sie Automatisierung und testen Sie Ihre Komponenten manuell. 
  1. Schreiben Sie Integrationstests, um Tastaturinteraktionen zu testen. Die einzige zuverlässige Möglichkeit, Tastaturinteraktionen zu testen, ist die Verwendung eines realen Browsers. Verlassen Sie sich nicht auf die manuelle DOM-Prüfung, um Regressionen abzufangen. Schreiben Sie Tests zum Sicherstellen der Fehlerfreiheit des Markups, einschließlich:
     • der richtigen Semantik am richtigen Knoten
     • der für den richtigen Knoten festgelegten richtigen Attribute
     • der richtigen während des Lebenszyklus von Komponenten aktualisierten Attributwerte
  2. Führen Sie manuell einen Funktionstest von A bis Z mit ausschließlich der Tastatur gemäß den SLDS-Spezifikationen durch. Stellen Sie sicher, dass alle Aufgaben mithilfe der Tastatur durchgeführt werden können.

Webkomponenten

Webkomponenten sind eine Browserfunktion, die ein Standardkomponentenmodell für das Web bereitstellt. Es besteht aus mehreren Teilen, die an verschiedenen Stellen verwaltet werden: Schatten-DOM, benutzerdefinierte Elemente, HTML-Vorlagen und CSS-Änderungen (Quelle). Aus praktischer Sicht haben Webkomponenten ein benutzerdefiniertes Element als Stammkomponente. Diese benutzerdefinierten Elemente haben keinen semantischen Wert, können aber bei Hilfstechnologien direkte Abstammungsprobleme verursachen. 

Direkte Abstammungsprobleme

Wenn Sie eine ungeordnete Liste, <ul>, mit Listenelementen von Webkomponenten, <lightning-example-list-item>, erstellen, sieht Ihr Markup so aus:

<ul>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
</ul>

Dies ist allerdings nicht barrierefrei, da jedes untergeordnete Element eines <ul>-Elements ein <li>-Element sein muss. Bildschirmleseprogramm können nicht erkennen, dass dies eine Liste mit drei Elementen ist. Hier ist es besser, sich auf ARIA-Rollen statt auf semantische Elemente zu verlassen.

Anstelle von <ul> können wir mit role="list" eine andere Webkomponente verwenden. Unsere Webkomponenten für Listenelemente arbeiten dann mit role="listitem", sodass wir keine <li>-Elemente verwenden. Mithilfe des nachstehenden Codes können Bildschirmleseprogramme dies richtig als Liste mit drei Elementen identifizieren.

<lightning-example-list>
<div role="list">
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item”>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
</div>
</lightning-example-list>

Globale HTML-Attribute

Verwenden Sie keine globalen HTML-Attribute, um Attribute für die inneren Elemente festzulegen. Wenn Sie mit Lightning-Webkomponenten auf dem Host ein globales HTML-Attribut festlegen, geht unser Framework davon aus, dass Sie es auf dem Host wünschen, auch wenn Sie es nach unten weitergeben. Wenn Sie z. B. das Attribut aria-describedby für eine Eingabe-Webkomponente als API verwenden, um das Attribut für das untergeordnete Element festzulegen, legen Sie es unabsichtlich zweimal fest.

<lightning-example-input aria-describedby="foo">

Wird gerendert als:

<lightning-example-input aria-describedby="foo">
  <input aria-describedby="foo" />
</lightning-example-input>

Schreiben Sie stattdessen den API-Namen Ihrer Webkomponente in gemischter Groß-/Kleinschreibung wie im folgenden Beispiel:

<lightning-example-input ariaDescribedby="foo">

Dies wird entsprechend gerendert:

<lightning-example-input>
  <input aria-describedby="foo" />
</lightning-example-input>

Weitere Informationen zu Eigenschafts- und Attributnamen, einschließlich Verwendung gemischter Groß-/Kleinschreibung, finden Sie im Abschnitt "Ressourcen".

Schatten-DOM

Webkomponenten mit aktiviertem Schatten-DOM stellen zusätzliche Probleme für die Barrierefreiheit dar. Viele Aspekte der Barrierefreiheit im Web beruhen auf Verweisen auf Komponenten-IDs, die verschiedene Elemente auf der Seite miteinander verbinden. Ein einfaches Beispiel hierfür ist das Bezeichnen von Formulareingaben.

<label for="foo">First Name</label>
<input type="text" id="foo" />

In dem oben gezeigten Codebeispiel verbindet die ID "foo" die Bezeichnung "First Name" mit der Texteingabe. Wenn die Bezeichnung und die Eingabe dann aufgrund von des Schatten-DOM in getrennten Webkomponenten abgelegt würden, wäre diese Beziehung in der Barrierefreiheitsstruktur des Browsers nicht mehr vorhanden.

<lightning-example-label>
     <label for="foo">First Name</label>
</lightning-example-label>
<lightning-example-input>
     <input type="text" id="foo" />
</lightning-example-input>

In diesem Szenario sind Bezeichnung und Eingabe nicht mehr miteinander verbunden, weshalb das Formular nicht mehr barrierefrei ist. Die Lösung besteht hier darin, Elemente nicht in verschiedene benutzerdefinierte Elemente aufzuteilen, wenn eine ID-Verweisbeziehung erforderlich ist.

<lightning-example-input>
     <label for="foo">First Name</label>
     <input type="text" id="foo">
</lightning-example-input>

Wenn Sie Ihre eigenen benutzerdefinierten Webkomponenten erstellen, untersuchen Sie die SLDS-Entwürfe und ARIA-Designspezifikationen. Ermitteln Sie HTML- und ARIA-Eigenschaften, die von ID-Verweisen abhängen, und trennen Sie diese Elemente niemals in separate ShadowRoots.

Eine Gruppe des W3C entwickelt das Accessibility Object Model, einen Ansatz, der Möglichkeiten bietet, Rollen und Eigenschaften zuzuweisen, Zustände zu aktualisieren und Beziehungen ohne Abhängigkeit von HTML-Attributen und ID-Verweisen zu erstellen. Obwohl sich dieses Modell noch im Entwurfsstadium befindet, wird es, sobald es von Browsern, Hilfstechnologien und der Entwickler-Community angenommen wurde, mehr Kontrolle über die Barrierefreiheit von Webkomponenten bieten.

Zusammenfassung

Sie haben sich mit den Grundlagen der Erstellung barrierefreier Benutzeroberflächen vertraut gemacht. Wenn Sie bereit sind, mit dem Entwerfen und Testen von Barrierefreiheit zu beginnen, finden Sie auf Trailhead weitere Ressourcen. Schließen Sie sich außerdem in der Salesforce Trailblazer Community unserer großen Community von Administratoren und Entwicklern an, um Ideen auszutauschen, Gruppen beizutreten, Erfolgsgeschichten zu lesen und vieles mehr. 

Ressourcen

• Dokumentation: W3C-Standards und -Entwürfe
• Referenz für Salesforce-Entwickler: Lightning-Webkomponenten
• Referenz für Salesforce-Entwickler: Property and Attribute Names (Eigenschafts- und Attributnamen)
• Documentation (Dokumentation): Accessibility Object Model
• Salesforce-Hilfe: Komponentenentwürfe
• Dokumentation: Spezifikation von Webkomponenten des W3C