Barrierefreiheit und inklusives Design – Muster
Weitere Informationen zu Fairness → Zugänglichkeit mit Lightning und Experience Cloud
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) |
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 |
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 |
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 |
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 |