---
schema_version: "1"
id: a961c1c710d7ea794af56622e4573a44f0c3a9cc6f28760b5316c94f18f3b335
title: Barrierefreiheit und inklusives Design – Muster
collection: architect
version: current
locale: de-de
portal_url: https://docs.salesforce.com/architect/current/de-de/well-architected/guides/fairness-accessibility-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/de-de/well-architected/guide/fairness-accessibility-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 87ed405e8899fca31f87a4829e7410fd3625e3fbc09e00e09184dd7dca60df76
products:
  - Gut strukturiertes Framework
  - Architect Site Content Repo
---
# Barrierefreiheit und inklusives Design – Muster

<br>

Weitere Informationen zu [Fairness](/docs/architect/de-de/well-architected/guide/fairness.html) → [Zugänglichkeit mit Lightning](/docs/architect/de-de/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud) und Experience Cloud

## WCAG 2.2 AA-Konformität

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| Designstandards               | ✅ WCAG 2.2 Level AA ist die minimale Barrierefreiheitsleiste für benutzerdefinierte Arbeiten (Experience Cloud, LWCs, benutzerdefinierte Themen), die vom Bauteam überprüft wird                                                |
| Plattform \| Designstandards               | ✅ Wahrnehmbares Prinzip: Für Bilder und Symbole gibt es Textalternativen. Untertitel begleiten Videos   |
| Plattform \| Designstandards               | ✅ Funktionsprinzip: Alle Funktionen sind über die Tastatur allein bedienbar, ohne Maus oder Berührung – Sprachsteuerung und Technologien für den Umschaltzugriff basieren auf demselben Tastatur-/Fokusmodell             |
| Plattform \| LWC                            | ✅ Standardmäßige Lightning Webkomponenten werden wie vorgesehen verwendet und bieten automatischen Basiszugriff                                         |
| Plattform \| LWC                            | ✅ Benutzerdefinierte Komponenten implementieren expliziten barrierefreien Zugriff, der durch Tests mit Bildschirmleseprogrammen validiert wurde                                               |
| Plattform \| Testpläne                     | ✅ Barrierefreiheitstests sind in allen Testphasen enthalten (nicht ad hoc oder optional)                                                               |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| Designstandards               | ⚠️ WCAG 2.2 Level AA wird als optional oder "nice to have" und nicht als Mindestanforderung behandelt                           |
| Plattform \| Designstandards               | ⚠️ Bilder und Symbole ohne Textalternativen; Videos ohne Titel                                                        |
| Plattform \| Designstandards               | ⚠️ Funktionen erfordern Maus- oder Touchinteraktion ohne Tastaturalternative                              |
| Plattform \| LWC                            | ⚠️ Benutzerdefinierte Komponenten werden ohne Implementierung oder Validierung des barrierefreien Zugriffs erstellt                                       |
| Plattform \| LWC                            | ⚠️ Benutzerdefinierte Eingabekomponenten verwenden Div-Elemente und CSS-Stil ohne semantische Bedeutung oder Tastaturzugriff          |
| Plattform \| Testpläne                     | ⚠️ Barrierefreiheitstests sind ad hoc, optional oder werden nur vor der Markteinführung durchgeführt (nicht während der gesamten Entwicklung)              |

## Screenreader-Architektur

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| LWC                            | ✅ In benutzerdefinierten Lightning Webkomponenten werden semantische HTML-Elemente (Kopfzeile, Navigation, Haupt-, Neben-, Fußzeile, Artikel, Abschnitt) verwendet                      |
| Plattform \| LWC                            | ✅ ARIA-Landmarken, -Rollen und -Eigenschaften werden dort angewendet, wo semantische HTML allein kein Oberflächenverhalten vermitteln kann                                 |
| Plattform \| LWC                            | ✅ Dynamische Inhaltsaktualisierungen verwenden Arien-Live-Bereiche, in denen Änderungen für Bildschirmleseprogramm-Benutzer angekündigt werden                                                      |
| Plattform \| LWC                            | ✅ Benutzerdefinierte interaktive Komponenten weisen explizite Rollendefinitionen auf, die ihrem Verhalten entsprechen                                                         |
| Plattform \| LWC                            | ✅ Formularbezeichnungen werden explizit mit allen Formulareingaben verknüpft, indem richtige Bezeichnungselemente oder Attribute vom Typ aria-labelledby verwendet werden                         |
| Plattform \| LWC                            | ✅ Lightning-Eingabekomponenten werden mit erforderlichen Bezeichnungsattributen konfiguriert, die eine integrierte Bezeichnungszuordnung bieten                                |
| Plattform \| Testpläne                     | ✅ Die Tests werden mit tatsächlichen Bildschirmleseprogrammen durchgeführt: JAWS und NVDA unter Windows, VoiceOver unter macOS und iOS, TalkBack unter Android                   |
| Plattform \| Testpläne                     | ✅ Manuelle Tests mit echter Hilfstechnologie werden von Personen durchgeführt, die verstehen, wie Bildschirmleseprogramm-Benutzer navigieren                         |
| Plattform \| Designstandards               | ✅ Platzhaltertext wird niemals als einzige Bezeichnung verwendet, da Platzhalter nicht im Fokus stehen und Bildschirmleseprogrammen nicht genügend Kontext zur Verfügung steht |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| LWC                            | ⚠️ Div-lastige Markup-Streifen, was bedeutet, dass Benutzer von Bildschirmleseprogrammen in der Inhaltshierarchie gezwungen werden, linear zu navigieren |
| Plattform \| LWC                            | ⚠️ ARIA wird nicht verwendet, wenn semantische HTML allein kein Oberflächenverhalten vermitteln kann                             |
| Plattform \| LWC                            | ⚠️ Dynamische Inhaltsaktualisierungen verwenden keine aria-live-Bereiche. Bildschirmleseprogramm-Benutzer verpassen wichtige Änderungen        |
| Plattform \| LWC                            | ⚠️ Benutzerdefinierte interaktive Komponenten enthalten keine expliziten Rollendefinitionen; Bildschirmleseprogramme kündigen sie falsch an  |
| Plattform \| LWC                            | ⚠️ Formulareingaben weisen keine explizite Bezeichnungszuordnung auf; Platzhaltertext wird als einzige Bezeichnung verwendet                     |
| Plattform \| Testpläne                     | ⚠️ Es werden ausschließlich automatisierte Tools für den barrierefreien Zugriff verwendet. Manuelle Bildschirmleseprogramme werden nicht getestet       |
| Plattform \| Testpläne                     | ⚠️ Die Tests werden von sehbehinderten Benutzern durchgeführt, die mit der tatsächlichen Navigation von Bildschirmleseprogramm-Benutzern nicht vertraut sind         |

## Tastaturnavigation

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| Designstandards               | ✅ Die vollständige Funktion ist über die Tastatur zugänglich, ohne dass eine Maus- oder Touchinteraktion an einem beliebigen Punkt der Benutzer-Journeys erforderlich ist                       |
| Plattform \| LWC                            | ✅ Die logische Fokusreihenfolge folgt dem visuellen Layout und dem Interaktions-Flow                                                                                     |
| Plattform \| LWC                            | ✅ Wenn dynamische Inhalte geladen oder Modalfenster geöffnet werden, wird der Fokus programmgesteuert verwaltet, um Tastaturbenutzer zu neuen Inhalten zu führen                                |
| Plattform \| LWC                            | ✅ Modal- und Popover-Komponenten verschieben den Fokus auf den Modaltitel oder das erste interaktive Element beim Öffnen; Schaltfläche zum Zurückgeben des Fokus auf Auslöser beim Schließen               |
| Plattform \| Designstandards               | ✅ Sichtbare Fokusindikatoren zeigen jederzeit deutlich an, welches Element den Tastaturfokus aufweist                                                                |
| Plattform \| Designstandards               | ✅ Fokusindikatoren erfüllen die 3:1-Kontrastanforderung gegenüber umgebenden Inhalten                            |
| Plattform \| LWC                            | ✅ Benutzer können in und aus allen Komponenten navigieren, ohne in die Falle zu geraten                                                    |
| Plattform \| LWC                            | ✅ Modale Dialoge fangen den Fokus im Modalfenster ein, während es geöffnet ist (verhindert den Zugriff auf verdeckte Inhalte), veröffentlichen jedoch den Fokus auf "Schließen"                            |
| Plattform \| Designstandards               | ✅ Tastenkombinationen für häufige Aktionen vermeiden Konflikte mit Bildschirmleseprogramm-Verknüpfungen und Browser-Verknüpfungen                                         |
| Plattform \| Designstandards               | ✅ Tastenkombinationen mit einem Buchstaben werden nur aktiviert, wenn bestimmte Komponenten im Fokus stehen (nicht global), um Konflikte mit Bildschirmleseprogramm-Navigationsbefehlen zu vermeiden |
| Plattform \| Dokumentation                  | ✅ Alle benutzerdefinierten Tastenkombinationen werden in den barrierefreien Hilfeinhalten dokumentiert                                                                            |
| Plattform \| Testpläne                     | ✅ Testschritte beinhalten die reine Tastaturnavigation durch alle Benutzer-Journeys ohne Maus oder Touch                                                 |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| Designstandards               | ⚠️ Für die Funktion ist eine Maus- oder Touchinteraktion erforderlich. Benutzer mit ausschließlicher Tastatur können keine wichtigen Aufgaben ausführen           |
| Plattform \| LWC                            | ⚠️ Die Fokusreihenfolge folgt nicht dem logischen visuellen Layout; Benutzer tippen in unerwarteter Reihenfolge durch Elemente       |
| Plattform \| LWC                            | ⚠️ Modale werden ohne Fokusverwaltung geöffnet; Tastaturbenutzer sind auf der nun ausgeblendeten Auslöserschaltfläche gestrandet             |
| Plattform \| LWC                            | ⚠️ Beim Schließen des Modalfensters wird der Fokus nicht auf die Auslöserschaltfläche zurückgegeben. Benutzer müssen nach ihrer Position auf der Seite suchen           |
| Plattform \| Designstandards               | ⚠️ Fokusindikatoren werden aus ästhetischen Gründen unterdrückt. Benutzer können nicht sehen, welches Element den Fokus aufweist            |
| Plattform \| Designstandards               | ⚠️ Fokusindikatoren weisen unzureichenden Kontrast auf (<3:1)                            |
| Plattform \| LWC                            | ⚠️ Benutzer werden in Schnittstellenbereichen ohne Escape-Mechanismus (Tastaturfallen) gefangen                        |
| Plattform \| LWC                            | ⚠️ Eingebetteter Inhalt (iframes, Drittanbieter-Widgets) erfasst dauerhaft den Tastaturfokus                        |
| Plattform \| Designstandards               | ⚠️ Tastenkombinationen mit einem einzelnen Buchstaben werden global aktiviert, was mit Navigationsbefehlen mit einem einzelnen Buchstaben im Bildschirmleseprogramm in Konflikt steht |
| Plattform \| Dokumentation                  | ⚠️ Benutzerdefinierte Tastenkombinationen sind undokumentiert; Benutzer können sie nicht entdecken                                     |

## Visuelles Design und Kontrast

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| Designstandards               | ✅ Mindestens 4,5:1 Kontrastverhältnis für normalen Text unter 18pt oder 14pt fett                                                                |
| Plattform \| Designstandards               | ✅ Minimales Kontrastverhältnis von 3:1 für großen Text und für aussagekräftige Benutzeroberflächenkomponenten und Grafiken (Formrahmen, Informationssymbole); rein dekorative und deaktivierte Elemente sind ausgenommen                      |
| Plattform \| Experience Cloud               | ✅ Benutzerdefinierte Themen und Experience Cloud-Sites mit Branding enthalten eine explizite Kontrastvalidierung mit Browser-Entwicklertools oder automatisierten Überprüfungen |
| Plattform \| Designstandards               | ✅ Die Textgröße auf 200 % wird ohne Verlust von Inhalt oder Funktionalität unterstützt (WCAG-Anforderung)                                        |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| Designstandards               | ⚠️ Textkontrastverhältnisse fallen unter 4,5:1 (normaler Text) oder 3:1 (großer Text und Benutzeroberflächenkomponenten)    |
| Plattform \| Experience Cloud               | ⚠️ Benutzerdefinierte Themen werden ohne Kontrastvalidierung bereitgestellt. Benutzer mit eingeschränktem Sehvermögen können Inhalte nicht lesen |
| Plattform \| Designstandards               | ⚠️ Textgrößenänderungen über 200 % brechen Layouts ein, wodurch Inhalte oder Funktionen verloren gehen                       |

## Tests und Validierungen für den barrierefreien Zugriff

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Plattform \| CI/CD                          | ✅ Der Axe-Core- oder Lighthouse-Scan für den barrierefreien Zugriff ist in CI/CD-Pipelines integriert, um strukturelle Probleme bei jeder Bereitstellung zu erfassen       |
| Plattform \| CI/CD                          | ✅ Builds schlagen fehl, wenn wichtige Probleme beim barrierefreien Zugriff erkannt werden                                                                           |
| Plattform \| Testpläne                     | ✅ Manuelle Tests mit Bildschirmleseprogrammen, reiner Tastaturnavigation und Browserzoom auf 200 % werden während der Entwicklung regelmäßig durchgeführt  |
| Plattform \| Testpläne                     | ✅ Testen zeigt Interaktionsprobleme auf, einschließlich verwirrender Ankündigungsreihenfolge, Fehlern bei der Fokusverwaltung und Tastaturfallen            |
| Plattform \| Unternehmen                       | ✅ Benutzer mit Behinderungen werden während des gesamten Designprozesses in Benutzerfreundlichkeitstests einbezogen                                                   |
| Plattform \| Unternehmen                       | ✅ Usability-Tests zeigen praktische Barrieren auf, die bei automatisierten und manuellen Expertentests fehlen                                            |
| Plattform \| Testpläne                     | ✅ Automatisierte Tests (ca. 57 % der Volumenprobleme), manuelle Tests (Interaktionsprobleme) und Benutzertests (reale Barrieren) werden durchgeführt |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Plattform \| CI/CD                          | ⚠️ Der barrierefreie Scan ist nicht in CI/CD-Pipelines integriert                                          |
| Plattform \| CI/CD                          | ⚠️ Builds werden trotz kritischer Probleme mit dem barrierefreien Zugriff fortgesetzt                                                   |
| Plattform \| Testpläne                     | ⚠️ Manuelle Tests mit Hilfstechnologie werden nicht durchgeführt, es wird nur automatisiertes Scannen verwendet             |
| Plattform \| Unternehmen                       | ⚠️ Benutzer mit Behinderungen werden nicht in Benutzerfreundlichkeitstests einbezogen                                          |
| Plattform \| Testpläne                     | ⚠️ Der automatische Scanner für den barrierefreien Zugriff wird einmal vor dem Start ausgeführt und die Barrierefreiheitsprüfung gilt als abgeschlossen |