BARRIEREFREIHEIT

Barrierefreiheit ist ein zentrales Prinzip des MATE Design Systems. Wir gestalten und entwickeln Komponenten und Muster so, dass digitale Produkte für alle Menschen zugänglich sind – unabhängig von Einschränkungen, Hilfsmitteln, Alter oder Situation.

Um dies zu gewährleisten ist Barrierefreiheit fester Bestandteil unserer technischen Anforderungen für alle UI-Funktionen. Dabei wird darauf geachtet, dass alle benutzerseitigen Funktionen gemäß den Kriterien der WCAG 2.1 Stufe AA erstellt werden.

Struktur

Klares Design

Mit jeder weiteren Komponente wächst die Komplexität der Anwendung. Eine klare Struktur hilft, Inhalte verständlich zu halten und Nutzenden eine schnelle Orientierung zu ermöglichen.

Unsere Patterns und Pagetypes sind so gestaltet, dass sie eine barrierefreie Grundstruktur sowie die Einhaltung visueller und semantischer Anforderungen gewährleisten. Wenn du sie nutzt, profitierst du automatisch von einer zugänglichen und konsistenten Basis. Achte außerdem auf:

• Eine klare visuelle Hierarchie
• Sofort erkennbare wesentliche Informationen
• Möglichst wenige Schritte für Benutzeraufgaben.

Visuelle und semantische Hierarchie

Barrierefreiheit beginnt bereits in der Konzeptphase – nicht erst im Design oder in der Entwicklung.
In der Entwicklung solltest du folgende Punkte besonders beachten:

• Definiere eine logische Lesereihenfolge.
• Übertrage die visuelle Hierarchie in eine saubere semantische Struktur mit Überschriften und Abschnitten.
• Überprüfe die Lesereihenfolge mit Screenreadern.

Eine enge Abstimmung zwischen Konzept, Design und Entwicklung stellt sicher, dass die visuelle und technische Struktur für alle Nutzenden zugänglich bleibt.

Tastaturnavigation

Alle Kernfunktionen müssen vollständig über die Tastatur erreichbar sein – insbesondere mit Tab, Shift + Tab, Pfeiltasten, Enter und Leertaste. Übliche Tastenkonventionen:

• Tab / Shift+Tab: Zwischen Hauptinteraktionselementen navigieren.
• Pfeiltasten: Innerhalb von Komponenten navigieren (Menüs, Listen, Tabellen).
• Enter / Space: Links oder Buttons aktivieren, Formulare absenden.

Fokusreihenfolge

Die Reihenfolge des Tastaturfokus entspricht standardmäßig der Reihenfolge im Quellcode. Unsere Komponenten halten diesen Standard ein . Bei individuellen Abläufen kann es nötig sein, die Fokusreihenfolge anzupassen und anschließend zu überprüfen.

Definition von User Flows

• Initialer Fokus: Der Fokus liegt immer zuerst auf der primären Aktion (z. B. Suchfeld auf einer Suchseite).
• Komponentenfokus: Die interne Fokusreihenfolge für Dialoge oder Karten wird immer durch die Hauptaktion definiert.
  
  • Beim Öffnen springt der Fokus auf das erste interaktive Element.
  • Beim Schließen kehrt der Fokus zum auslösenden Element zurück.

Farbe & Kontrast

Farbe im Designsystem

Unsere Farb- und Kontraststandards sind im Designsystem fest verankert. Das bedeutet: Wer die vordefinierten Farb-Tokens und Komponenten nutzt, sorgt automatisch dafür, dass die zugehörigen Anforderungen an die Barrierefreiheit eingehalten werden.

Farbe ist ein wesentliches Design Element: Sie schafft visuelle Hierarchie, vermittelt Inhalte verständlich und führt Nutzende gezielt durch eine Anwendung.

Unsere Farbpalette unterstützt Markenidentität, Benutzerfreundlichkeit und Barrierefreiheit gleichermaßen. Auch wenn viele Anforderungen bereits durch das Designsystem abgedeckt sind, ist es wichtig, einige zentrale Regeln zu beachten, damit alle Nutzenden unsere Interfaces problemlos verstehen und bedienen können.

Farbenblindheit

Verwende Farbe nicht als einziges Mittel, um Bedeutung zu vermitteln, sondern kombiniere sie immer mit weiteren Hinweisen wie Text, Icons oder Mustern.

Design- und Testtipp

Verwende Farbseh-Simulatoren (z.B. das Stark-Plugin für Figma) um die Barrierefreiheit zu überprüfen.

Kontrastanforderungen

Ein guter Kontrast sorgt für Klarheit und Lesbarkeit. Wenn du eigene Farben verwendest, achte darauf, dass folgende Kontrastverhältnisse eingehalten werden.

Elementtyp	Geforderte Kontrastwerte
Standardtext	≥ 4.5:1 gegenüber der Hintergrundfarbe
Großer Text	≥ 3:1 gegenüber der Hintergrundfarbe
UI-Komponenten	≥ 3:1 gegenüber der umgebenden Farbe

Benennung von Elementen

Durch eine korrekte Benennung von Elementen wird ihr Zweck auch für assistive Technologien eindeutig erkennbar. Gemeint sind dabei nicht die sichtbaren Texte im UI, sondern semantische Bezeichnungen im Code – etwa mit for‑Attributen für Formularfelder, alt‑Attributen für Bilder oder aria-label‑Attributen für interaktive Elemente.

Wann ist eine Benennung erforderlich?

Ein zugänglicher Name ist für alle interaktiven oder nicht eindeutig sichtbaren Elemente erforderlich. Beispiele:

• Alle Eingabefelder (Input-Fields) müssen einen semantischen Identifikator besitzen. Wenn keiner vorhanden ist, verwende aria-label oder aria-labelledby.
• Interaktive Icons oder Buttons ohne Text – z. B. eine Lupe als Such-Icon.
• Interaktive Bilder – z. B. klickbare Thumbnails.
• Statusanzeigen oder aussagekräftige Icons, die einen Zustand vermitteln.
• Infografiken oder erklärende Bilder, die Informationen transportieren.

Hinweis: Unsere Komponenten sind so gestaltet, dass sie bei fachgerechter Implementierung im Entwicklungsprozess die relevanten Anforderungen zuverlässig erfüllen.

Redundante Benennungen vermeiden

Statische, nicht‑interaktive Texte besitzen bereits sichtbaren Inhalt, der von Screenreadern erfasst und ausgegeben wird. Zusätzliche semantische Beschriftungen sind in diesem Fall nicht sinnvoll, denn diese können zu doppelten Screenreader-Ausgaben führen.

Richtlinien für zugängliche Namen

• Halte Benennungen kurz, präzise und auf die Funktion des Elements bezogen.
• Wiederhole den Elementtyp nicht – die Rolle wird automatisch von assistiven Technologien erkannt.
  
  • Beispiel: Verwende “Suche” und nicht “Lupen-Button”.
• Verwende konsistente Accessibility-Attribute (aria, alt, title)
gemäß den Vorgaben des Designsystems.
• Bei Komponenten mit Text sind die UX-Writing-Guidelines für klare und einheitliche Formulierungen zu beachten.

Dekorative Elemente

Dekorative Icons oder Bilder ohne zusätzliche Bedeutung sollten im Code entsprechend als dekorativ markiert werden (z. B. mit aria-hidden="true" oder einem leeren alt‑Attribut). So werden sie von Screenreadern ignoriert und nicht vorgelesen.

Rollen zuweisen

Weise allen interaktiven Elementen die passenden ARIA‑Rollen zu (z. B. role="button", role="dialog"), damit Screenreader und andere Hilfsmittel sie korrekt erkennen können.

Zusammenfassung

MATE DS stellt barrierefreie Bausteine für Farbe, Struktur, Fokus und Beschriftung bereit. Setzen Teams sie sorgfältig um, prüfen sie mit assistiven Technologien und achten auf semantische wie funktionale Integrität - entfaltet sich das volle Potenzial und es entstehen digitale Produkte, die für alle zugänglich sind.