ACCESSIBILITY.md — BFSG / WCAG 2.1 AA

WCAG 2.1 Level AA ist die unbedingte Grundlinie dieses Projekts (BFSG). Kein Rechtsrat — ob und wie das Gesetz greift, klärt der Betreiber ggf. juristisch.

Die eine Regel

Keine Komponente ist „fertig", bevor sie die WCAG-2.1-AA-Checks ihrer Atomic-Ebene besteht. Barrierefreiheit ist Teil der Definition of Done — zusammen mit Styling und Struktur, nie ein späterer Durchgang.

Checkliste je Atomic-Ebene

• Atome — zugänglicher Name, Label-Zuordnung, sichtbarer Fokus (focus-visible + Fokus-Token, nie outline:none ohne Ersatz), Kontrast (4.5:1 Text / 3:1 große Schrift & nicht-textliche UI), Zielgröße, alt.
• Moleküle — Gruppierung (fieldset/legend), Fehlerkopplung (aria-describedby), required/aria-invalid-Zustände.
• Organismen — Landmark-Rollen, korrekte Überschriften-Reihenfolge, Tastaturbedienbarkeit von Menüs/Dialogen, Fokus-Management.
• Seiten — lang, sinnvoller Title, genau ein <main>, Skip-Link, logische Fokusreihenfolge, Reflow/Zoom bis 200 %, prefers-reduced-motion.

Festgelegte Muster (Projekt)

• Aktion noch nicht möglich → aria-disabled="true" + Begründung per aria-describedby, nicht disabled. Der Button bleibt sichtbar, fokussierbar und erklärt sich (z. B. „Hochladen", solange keine Datei gewählt ist). Der Klick landet im JS und gibt dieselbe Begründung als Text aus. Kontrast: inaktive Bedienelemente sind von 1.4.3 ausgenommen.
• Drag & Drop ist nie der einzige Weg: Es gibt immer einen echten Auslöser für die Dateiauswahl (Tastatur/Screenreader) und ohne JS ein natives input[type=file]. Das Ziehen-Overlay ist rein visuell (aria-hidden); Ergebnisse werden über eine role="status"-Live-Region angesagt.
• Ausklappbares ohne Zwang zu JavaScript → <details>/<summary> (z. B. die optionalen Upload-Einstellungen). Enthält der Bereich Validierungsfehler, wird er serverseitig open gerendert, sonst wären die Meldungen unsichtbar (3.3.1).

Token-Kopplung

Kontrast, Fokusring und Zoom/Reflow hängen an resources/css/tokens.css. Bei jeder Token-Änderung Kontrast erneut prüfen.

Die Element-Ebene (--e-…) vergrößert die Prüffläche. Vorher lagen Fließtext, Überschriften, Labels, Tabellenzellen und Menütexte auf EINEM Wert: Wer den auf AA brachte, hatte alle. Jetzt ist jede Rolle einzeln einstellbar — also auch einzeln verstellbar. Zwei Folgen für jede Prüfung:

• Text gegen die Fläche prüfen, auf der er wirklich liegt. --e-on-table gegen --e-table, --e-on-nav gegen --e-nav, --e-on-menu gegen --e-menu, --e-on-button gegen --e-button — nicht alles gegen den Seitengrund. Die Paar-Benennung (X / on-X) ist genau dafür da.
• Hover-Paare mitprüfen. --e-button-hover und --e-on-button-hover sind ein eigenes Paar; ein invertierender Hover kann AA erfüllen und nach einem Eingriff des Betreibers trotzdem daneben liegen.

Der Fokusring bleibt bewusst zentral (--e-focus-ring, angewandt in app.css auf alle interaktiven Elemente) und hat keine Element-Ebene. Wer mit der Tastatur bedient, darf nicht pro Seitenbereich neu lernen, wie „hier stehe ich gerade" aussieht (WCAG 2.4.7). Ebenso ohne Element-Ebene: die vier Statusfarben — sie tragen Bedeutung, und ihre Kontraste sind knapp gerechnet (Tabelle unten).

Redaktionelle Inhalte (prose) sind seit 3.2 angebunden. Das Typography-Plugin brachte eine eigene Graupalette mit, die den Dark Mode nicht kannte: Fließtext auf den Seiten aus der Datenbank stand im dunklen Modus mit rund 2,7:1 auf Schwarz und fiel damit unter 1.4.3 durch. app.css legt die --tw-prose-*-Variablen jetzt auf die Element-Tokens; Modifier wie prose-neutral oder dark:prose-invert gehören deshalb nicht mehr ins Markup — sie setzten genau diese Variablen zurück.

Statusfarben haben deshalb zwei Rollen: --color-<tone> als Füllung (mit text-on-<tone> darauf, ~5:1 in beiden Modi) und --color-<tone>-ink als Vordergrund auf dem Seitenhintergrund. Letzteres ist im Dark Mode aufgehellt, weil die Füllfarbe auf Schwarz nur ~3,9:1 erreicht — als Text also durchfällt und optisch untergeht. Gemessen (WCAG-Kontrast, Stand der aktuellen Tokens):

Ton	hell auf Weiß	dunkel auf Schwarz (…-ink)
danger	5,4:1	9,0:1
success	5,1:1	11,9:1
warning	5,0:1	12,5:1
info	5,0:1	10,8:1

BFSG-Pflichtartefakte (öffentlich, erreichbar)

1. Barrierefreiheitserklärung — Konformitätsstatus, bekannte nicht-barrierefreie Inhalte + Begründung, Datum der Bewertung, Feedback-Weg. (Noch anzulegen; Inhalte sind Betreibersache — keine Konformität erfinden.)

2. Feedback-/Kontaktweg — erreichbare Möglichkeit, Barrieren zu melden (Formular oder E-Mail), aus der Erklärung und möglichst seitenweit verlinkt.

   Umsetzung in Fileshare: Der Kontaktweg ist eine redaktionelle Seite, keine fest verdrahtete Route. Der Betreiber legt sie unter Einstellungen → Seiten an (Slug frei wählbar, üblich kontakt) und setzt dort eine erreichbare Adresse — ein mailto:-Link reicht, ein Formular ist nicht vorgeschrieben. Die Bereinigung des Editorinhalts lässt mailto: durch; tests/Feature/EditorialContactPageTest.php sichert das ab, damit eine spätere Änderung an der Bereinigung den Feedback-Weg nicht stillschweigend kappt.

   Die Seite muss in der Fußzeile sichtbar sein (Haken „im Footer zeigen") und aus der Barrierefreiheitserklärung heraus verlinkt werden.

Ehrlichkeitsgrenze

Maschinell/Markup-Review deckt nur den prüfbaren Teil ab. Vor Release verbleiben: Tastatur-Walkthrough, Screenreader-Durchgang, Zoom/Reflow, echte Fokusreihenfolge. Nie „ist AA-konform" behaupten — nur „besteht die hier angewandten Checks".