Barrierefreiheit

Diese Seite orientiert sich an WCAG 2.1 Level AA, EN 301 549 und der EU-Richtlinie 2019/882 (European Accessibility Act). Als Forschungsprototyp sind wir nicht rechtlich verpflichtet — wir tun es, weil Barrierefreiheit zum Projektanspruch gehört.

Der European Accessibility Act (Richtlinie 2019/882) verpflichtet ab Juni 2025 Unternehmen, digitale Produkte und Dienstleistungen barrierefrei zu gestalten. moiree.eu fällt als nicht-kommerzieller Forschungsprototyp nicht in den Anwendungsbereich — die Anforderungen dienen uns dennoch als Orientierung.

Barrierefreiheit ist ein fortlaufender Prozess. Wenn du auf eine Barriere stößt, die hier nicht dokumentiert ist, oder wenn eine der beschriebenen Funktionen bei dir nicht wie erwartet funktioniert, melde dich bei uns.

Kontakt: info@moiree.eu

Was wurde geprüft

Alle Text-Hintergrund-Kombinationen wurden mit dem WebAIM Contrast Checker und axe DevTools geprüft — in beiden Farbmodi (dunkel und hell). Geprüft wurden Fließtext, Überschriften, Links, Badges, Tabellentext und Platzhalter.

Warum das für moiree.eu wichtig ist

Die Plattform verwendet eine dunkle Primärpalette mit Akzentfarbe #7A5AB5. Kontrast ist hier besonders kritisch, weil viele Texte auf dunklem Hintergrund stehen — eine Kombination, bei der Lesbarkeit schnell leidet.

Was der Stand der Technik verlangt

WCAG 2.1 AA verlangt ein Mindestverhältnis von 4,5:1 für Fließtext und 3:1 für großen Text (ab 18pt oder 14pt fett). Diese Schwelle basiert auf Forschung zur Lesbarkeit bei eingeschränkter Sehfähigkeit.

Ergebnis

Die Primärfarbe #7A5AB5 erreicht 5,1:1 auf weißem Hintergrund — bewusst über dem Minimum, um auch unter ungünstigen Bedingungen (Sonnenlicht, ältere Displays) lesbar zu bleiben. Alle weiteren Text-Kombinationen erreichen mindestens 4,5:1. Im Dunkel-Modus wurden die Textfarben entsprechend angepasst.

Was wurde geprüft

Alle interaktiven Elemente — Links, Buttons, Formulare, Dropdowns, Modals, Karussell, Akkordeons — wurden ausschließlich mit der Tastatur durchgetestet: Tab, Shift+Tab, Enter, Escape, Pfeiltasten.

Warum das für moiree.eu wichtig ist

Die Plattform enthält komplexe Interaktionsmuster: aufklappbare Sektionen, Filter-Dropdowns auf dem Dashboard, modale Fallansichten in der Datenbank. Jedes dieser Elemente muss ohne Maus bedienbar sein.

Was der Stand der Technik verlangt

WCAG 2.1.1 verlangt, dass alle Funktionen per Tastatur erreichbar sind. WCAG 2.1.2 stellt sicher, dass der Tastaturfokus nicht in einem Element gefangen wird (außer bei Modals, wo Focus-Trapping erwünscht ist).

Ergebnis

Alle interaktiven Elemente sind per Tab, Enter und Escape erreichbar. Die Tab-Reihenfolge folgt der visuellen Leserichtung. Kein Element fängt den Fokus unbeabsichtigt.

Was wurde geprüft

Alle fokussierbaren Elemente wurden auf sichtbare :focus-visible-Stile geprüft — Links, Buttons, Formularfelder, Akkordeon-Trigger, Navigation.

Warum das für moiree.eu wichtig ist

Auf dunklem Hintergrund sind Standard-Browser-Fokusringe oft schlecht sichtbar. moiree.eu verwendet eigene Fokus-Stile, die in beiden Farbmodi funktionieren müssen.

Was der Stand der Technik verlangt

WCAG 2.4.7 verlangt einen sichtbaren Fokusindikator. WCAG 2.4.11 (Level AAA, in 2.2 auf AA herabgestuft) definiert einen Mindestkontrast für den Fokusring selbst.

Ergebnis

Alle interaktiven Elemente zeigen einen sichtbaren :focus-visible-Ring. Der Stil nutzt outline mit offset, sodass der Fokus auch auf dunklem Hintergrund klar erkennbar ist.

Was wurde geprüft

Jede Seite wurde auf das Vorhandensein eines Skip-Links geprüft, der bei Fokus sichtbar wird und direkt zum Hauptinhalt springt.

Warum das für moiree.eu wichtig ist

Die Navigation enthält mehrere Gruppen mit Dropdowns. Ohne Skip-Link müssten Tastaturnutzer*innen auf jeder Seite durch alle Navigationspunkte tabben, bevor sie den Inhalt erreichen.

Was der Stand der Technik verlangt

WCAG 2.4.1 verlangt einen Mechanismus, um wiederkehrende Inhaltsblöcke zu überspringen. Der Skip-Link ist die verbreitetste Umsetzung.

Ergebnis

Auf jeder Seite vorhanden. Visuell verborgen, bis der Link fokussiert wird — dann sichtbar positioniert. Springt zu #main.

Was wurde geprüft

Alle Seiten wurden mit VoiceOver (macOS/Safari) durchgetestet: Seitenstruktur, Landmarks, ARIA-Labels, dynamische Inhalte (Filterergebnisse, Modalöffnungen), Tabellen und Formulare.

Warum das für moiree.eu wichtig ist

Die Plattform enthält dynamische Inhalte — Filterergebnisse auf dem Dashboard, modale Fallansichten, Statistik-Counter. Diese müssen für assistive Technologien korrekt angekündigt werden.

Was der Stand der Technik verlangt

WCAG 4.1.2 verlangt, dass alle Bedienelemente Name, Rolle und Zustand programmatisch bestimmbar haben. WCAG 4.1.3 verlangt, dass Statusmeldungen über aria-live kommuniziert werden.

Ergebnis

Semantisches HTML bildet die Basis: nav, main, footer als Landmarks, korrekte Überschriftenstruktur (mit bekannter Ausnahme, siehe unten). ARIA-Labels auf Navigationselementen, Tabellen und Formularen. aria-live-Regionen für dynamische Inhalte wie Filterergebnisse und Statistiken.

Was wurde geprüft

Die Fallansicht-Modals in der Datenbank wurden auf Focus-Trapping, korrektes ARIA-Markup und Schließverhalten geprüft.

Warum das für moiree.eu wichtig ist

Die Datenbank zeigt Falldetails in modalen Overlays. Wenn der Fokus aus dem Modal herauswandert, können Tastaturnutzer*innen mit dem verdeckten Seiteninhalt interagieren — ein häufiger Barrierefreiheitsfehler.

Was der Stand der Technik verlangt

WAI-ARIA Authoring Practices empfehlen: role="dialog", aria-modal="true", Focus-Trapping innerhalb des Modals, Schließen per Escape, Fokus-Rückgabe an das auslösende Element.

Ergebnis

Focus-Trapping ist aktiv: Tab und Shift+Tab bleiben innerhalb des Modals. role="dialog" und aria-modal gesetzt. Escape schließt. Fokus kehrt zum auslösenden Element zurück.

Was wurde geprüft

Das Einreichungsformular und das Newsletter-Formular wurden auf Labels, Fehlermeldungen, ARIA-Attribute und Tastaturerreichbarkeit geprüft.

Warum das für moiree.eu wichtig ist

Das Einreichungsformular ist der zentrale Interaktionspunkt der Plattform. Wenn Eingabefelder nicht korrekt gelabelt sind, können Screenreader-Nutzer*innen keine Erfahrungsberichte einreichen.

Was der Stand der Technik verlangt

WCAG 1.3.1 und 4.1.2 verlangen programmatisch verknüpfte Labels für alle Formularfelder. WCAG 3.3.1 verlangt, dass Fehler identifiziert und als Text beschrieben werden.

Ergebnis

Alle Felder haben verknüpfte label-Elemente. Fehlermeldungen erscheinen als sichtbarer Text, nicht nur als Farbänderung. aria-invalid wird bei Validierungsfehlern gesetzt.

Was wurde geprüft

Alle klickbaren Elemente wurden auf ihre Mindestgröße geprüft — Buttons, Links, Karussell-Dots, Filter-Chips, Checkbox-Labels, Navigationseinträge.

Warum das für moiree.eu wichtig ist

Die Plattform wird auch auf Mobilgeräten genutzt. Kleine Touch-Ziele (z.B. Karussell-Dots) führen zu Fehlbedienung, besonders für Menschen mit motorischen Einschränkungen.

Was der Stand der Technik verlangt

WCAG 2.5.8 (Level AA in WCAG 2.2) verlangt eine Mindestgröße von 24 × 24 px. Apple und Google empfehlen 44 × 44 px. moiree.eu orientiert sich an der strengeren Empfehlung.

Ergebnis

Alle interaktiven Elemente erreichen mindestens 44 × 44 px Trefferfläche. Bei visuell kleineren Elementen (z.B. Karussell-Dots) wird die Trefferfläche über Pseudo-Elemente vergrößert.

Was wurde geprüft

Alle Seiten wurden bei 200 % Browser-Zoom auf horizontales Scrollen, abgeschnittene Inhalte und Layout-Fehler geprüft.

Warum das für moiree.eu wichtig ist

Tabellen (Datenbank), Diagramme (Dashboard) und die mehrspaltige Navigation sind besonders anfällig für Layout-Brüche bei Vergrößerung.

Was der Stand der Technik verlangt

WCAG 1.4.4 verlangt, dass Text auf 200 % vergrößert werden kann, ohne dass Inhalt oder Funktionalität verloren geht. WCAG 1.4.10 verlangt, dass bei 400 % Zoom kein horizontales Scrollen bei 320 px Breite nötig ist.

Ergebnis

Kein horizontales Scrollen bei 200 % Zoom. Tabellen erhalten horizontales Scrollen innerhalb ihres Containers. Alle Inhalte bleiben lesbar und bedienbar.

Was wurde geprüft

Die acht Dashboard-Diagramme wurden mit VoiceOver und axe DevTools auf Screenreader-Zugänglichkeit, Tastaturnavigation und alternative Datenzugänge geprüft.

Warum das für moiree.eu wichtig ist

Das Dashboard ist das analytische Herzstück der Plattform. Wenn Diagramme nicht zugänglich sind, ist die gesamte Datenauswertung für Screenreader-Nutzer*innen ausgeschlossen.

Was der Stand der Technik verlangt

WCAG 1.1.1 verlangt Textalternativen für Nicht-Text-Inhalte. Für komplexe Datenvisualisierungen empfehlen W3C-Richtlinien tabellarische Alternativen oder strukturierte Beschreibungen.

Ergebnis

Plotly.js rendert SVG-Diagramme, die für Screenreader nicht interpretierbar sind — eine bekannte Einschränkung der Bibliothek. Die Diagrammdaten sind als Tabelle auf der Datenbank-Seite einsehbar und als CSV exportierbar. Das ist ein bewusster Kompromiss zwischen visueller Komplexität und Zugänglichkeit: die Daten sind vollständig zugänglich, die visuelle Aufbereitung nicht.

Was wurde geprüft

Die Überschriftenstruktur aller Seiten wurde mit axe DevTools und der VoiceOver-Überschriftennavigation auf lückenlose Hierarchie geprüft.

Warum das für moiree.eu wichtig ist

Screenreader-Nutzer*innen navigieren häufig über die Überschriftenstruktur. Übersprungene Ebenen erschweren die Orientierung auf der Seite.

Was der Stand der Technik verlangt

WCAG 1.3.1 verlangt, dass Struktur und Beziehungen programmatisch bestimmbar sind. Eine lückenlose Überschriftenhierarchie (h1 → h2 → h3) ist Teil dieser Anforderung.

Ergebnis

Die Startseite überspringt eine Ebene (h1 → h3 ohne h2) — ein bekannter Fehler, der die Screenreader-Navigation beeinträchtigen kann. Alle übrigen Seiten haben eine korrekte Hierarchie. Die Korrektur ist für das nächste Update geplant.

Was wurde geprüft

Der DE/EN-Sprachumschalter wurde auf Tastaturerreichbarkeit, ARIA-Semantik und Screenreader-Ansage geprüft.

Warum das für moiree.eu wichtig ist

Die Plattform ist zweisprachig. Wenn der Sprachumschalter für assistive Technologien nicht korrekt erkennbar ist, können Nutzer*innen die Sprache nicht wechseln.

Was der Stand der Technik verlangt

WCAG 4.1.2 verlangt, dass benutzerdefinierte Bedienelemente Name, Rolle und Zustand programmatisch bestimmbar haben. Ein Toggle-Element benötigt mindestens role="button" oder role="switch" und ein beschreibendes aria-label.

Ergebnis

Der Umschalter ist per Tastatur erreichbar und funktional. Es fehlt ein explizites ARIA-role-Attribut — Screenreader erkennen das Element daher nicht zuverlässig als interaktives Bedienelement. Die Ergänzung von role und aria-label ist für die nächste Version geplant.