Zum Hauptinhalt springen

Syncanto Accessibility Audit

Syncanto Accessibility Audit

Stand: 2026-08-10

Zielbild​

WCAG 2.2 Level AA ist die Qualitätsbaseline für neue und wesentlich überarbeitete Syncanto-Oberflächen. Dieses Dokument ist eine technische Audit-Notiz und keine Behauptung formaler Konformität.

Leitissue: #716

Langfristige Accessibility-Richtlinien​

Barrierefreiheit wird nicht als einmaliges Reparaturprojekt behandelt, sondern als dauerhafte Produkteigenschaft.

Definition of Done​

Neue oder wesentlich überarbeitete UI muss mindestens:

  • ohne Maus vollständig bedienbar sein,
  • sinnvolle Accessible Names besitzen,
  • Formulare programmatisch beschriften,
  • Fehler und dynamische Statusänderungen assistiv verfügbar machen,
  • Informationen nicht ausschließlich über Farbe vermitteln,
  • Fokus sichtbar und logisch halten,
  • unter Zoom/Reflow nutzbar bleiben.

Keine Drag-and-Drop-Pflicht​

Drag & Drop darf eine komfortable Bedienmöglichkeit sein, aber niemals die einzige Möglichkeit, eine fachlich notwendige Aktion auszuführen. Das gilt insbesondere für Kanban, Setlisten, Reihenfolgen, Bühnenplanung und Inventar. Es muss eine alternative Bedienmöglichkeit ohne präzise Zeigerbewegung geben, z. B. Verschieben nach oben/unten, Auswahl eines Zielbereichs oder gleichwertige Controls.

Systemeinstellungen respektieren​

Syncanto baut keinen separaten „Barrierefreiheitsmodus“ als Ersatz für eine zugängliche Standardoberfläche. Browser- und Betriebssystempräferenzen werden möglichst nativ respektiert, insbesondere Zoom, Textvergrößerung, prefers-reduced-motion und etablierte assistive Technologien.

Komponenten vor breiter Nutzung prüfen​

Neue UI-Komponenten und Drittanbieterbibliotheken werden vor breiter Verwendung auf Tastaturbedienung, Fokusführung, Accessible Names, Screenreader-Semantik und relevante Kontrast-/Zoomzustände geprüft. Accessibility-Probleme sollen möglichst an zentralen Flux-/Blade-Komponenten behoben werden statt in jeder einzelnen View.

Musikalische Nutzerinhalte vs. Syncanto-Oberfläche​

Von Nutzern hochgeladene oder eingebundene Inhalte wie Noten, PDFs, Bilder, Audio oder externe Medien können Einschränkungen besitzen, die Syncanto nicht vollständig kontrollieren kann. Die Syncanto-Oberfläche zum Finden, Verwalten, Abspielen, Herunterladen und Organisieren dieser Inhalte muss trotzdem zugänglich sein. Syncanto soll keine formale Barrierefreiheit fremder Inhalte versprechen, die es nicht selbst erzeugt oder kontrolliert.

Accessibility-Feedback​

Reale Barrieren sollen direkt über Syncanto gemeldet werden können (#725). Feedback wird als Qualitätsinput behandelt und kann neue Befunde im Leitissue #716 oder konkrete Folgeissues erzeugen.

Öffentliche Transparenz​

Nach Bereinigung der wesentlichen bekannten P1-Barrieren wird eine öffentliche Erklärung zur Barrierefreiheit bereitgestellt (#726). Sie beschreibt Zielbild, geprüfte Bereiche, bekannte Einschränkungen und Feedbackweg, ohne eine nicht belegte vollständige WCAG-Konformität zu behaupten.

Regelmäßiger Review​

Mindestens einmal jährlich sowie nach wesentlichen Änderungen an Navigation, Designsystem oder zentralen Interaktionsmustern wird ein Accessibility-Review durchgeführt. Der Review umfasst repräsentative Kernpfade statt nur einzelne Komponenten:

  1. öffentliche Homepage / Einstieg,
  2. Login und Registrierung,
  3. Organisation auswählen / beitreten,
  4. Termin bzw. Probe öffnen und Rückmeldung geben,
  5. Songs und Dateien nutzen,
  6. Aufgaben bearbeiten,
  7. zentrale Dialoge/Formulare und mobile Navigation.

Der Review kombiniert automatisierte Prüfungen mit manueller Tastatur-, Zoom- und Screenreader-Prüfung. Das Datum und wesentliche Ergebnisse werden in diesem Dokument oder einer nachfolgenden Audit-Dokumentation festgehalten.

Auditumfang​

Geprüft wurden bisher insbesondere:

  • öffentliche Homepage und Guest-Layout
  • Login und Registrierung
  • globales App-Layout
  • eigener Modal-Wrapper
  • Songübersicht
  • Aufgaben-Kanban
  • Umfrage-Terminübersicht
  • exemplarisch Proben-Detailansicht
  • repositoryweite Suchen nach wire:click, role="button", tabindex, aria-live, Bildern und wiederverwendbaren Interaktionsmustern

Bestätigte positive Muster​

  • Das öffentliche Kontaktformular verwendet explizite label/for-Zuordnungen.
  • Die Sternebewertung in der Songübersicht verwendet echte button-Elemente mit konkretem aria-label.
  • Auf der Proben-Detailseite verwendet der auf-/zuklappbare Infobereich einen echten Button mit aria-expanded und aria-controls.
  • Der eigene Modal-Wrapper verwendet x-trap.inert.noscroll; Fokus-Trapping/Inertness sind damit zumindest technisch vorgesehen.
  • Die öffentliche Homepage besitzt im ausgelieferten Inhalt eine nachvollziehbare Überschriftenstruktur und beschreibende Alternativtexte für zentrale Screenshots.

Bestätigte Befunde​

A11Y-01 – Nicht-semantische klickbare Elemente​

Beispiele:

  • resources/views/livewire/todos/_kanban-card.blade.php: äußeres div role="button" mit wire:click, aber ohne Fokusierbarkeit/Enter-/Space-Behandlung.
  • dieselbe Kanban-Karte: Benutzerwechsel über klickbares div.
  • resources/views/livewire/songs/index.blade.php: Navigation zu Songs über wire:click auf Tabellenzellen.
  • resources/views/livewire/surveys/dates-view.blade.php: Info/Kopieren/Bearbeiten über direkt klickbare flux:icon.*-Elemente.

Risiko: Funktionen sind mit Tastatur beziehungsweise assistiven Technologien nicht zuverlässig erreichbar oder benannt.

A11Y-02 – Auth-Formulare ohne belastbare Labels​

resources/views/auth/login.blade.php und resources/views/auth/register.blade.php verwenden bei zentralen Flux-Inputs Platzhalter, aber kein sichtbares label-Attribut beziehungsweise keine explizite zugängliche Beschriftung im Template.

Betroffen u. a.:

  • Name
  • E-Mail
  • Passwort
  • Passwortbestätigung
  • Chor-Schlüssel
  • Chorname
  • Einladungscode

Placeholder dürfen nicht die einzige Beschriftung eines Eingabefeldes sein.

A11Y-03 – Registrierungsmodus ohne Auswahlsemantik​

Die Auswahl „Mitglied beitreten“ / „Neuen Chor anlegen“ wird über zwei normale Buttons und Alpine-State umgesetzt. Der aktive Zustand ist visuell, wird aber im Template nicht mit aria-pressed, Radio-/Radiogroup- oder Tab-Semantik ausgedrückt.

A11Y-04 – Dynamische Meldungen werden nicht assistiv angekündigt​

Repositoryweite Suche findet aktuell kein belastbares aria-live-Muster.

Beispiele:

  • Kontaktformular: Erfolg nach Livewire-Submit ersetzt Formular visuell.
  • resources/views/layouts/app2.blade.php: Toast wird dynamisch eingeblendet und nach drei Sekunden wieder entfernt, ohne Live-Region/Status-/Alert-Semantik.
  • Validierungszusammenfassungen und einzelne Fehler besitzen nicht durchgängig eine Fokus-/Ankündigungsstrategie.

A11Y-05 – Formularfehler nicht durchgängig programmatisch zugeordnet​

Im öffentlichen Kontaktformular bestehen gute Labels, aber Fehlertexte werden nicht erkennbar über aria-describedby an Felder gekoppelt und die Inputs setzen keinen sichtbaren aria-invalid-Zustand im Template.

Dasselbe Muster ist für weitere Formulare systematisch zu prüfen.

A11Y-06 – Modal-Semantik unvollständig​

resources/views/components/modal.blade.php besitzt Fokus-Trapping über Alpine, aber im Wrapper sind nicht erkennbar:

  • role="dialog" beziehungsweise natives <dialog>
  • aria-modal="true"
  • standardisierte Verknüpfung eines Dialogtitels über aria-labelledby
  • explizite Strategie für initialen Fokus und Fokus-Rückgabe zum Auslöser

Der Fix sollte am gemeinsamen Wrapper erfolgen.

A11Y-07 – Informationen teilweise farbcodiert​

resources/views/livewire/surveys/dates-view.blade.php zeigt Rückmeldungen als grüne, gelbe und rote Badges mit Zahlen. In den sichtbaren Badges steht nicht zusätzlich Ja/Vielleicht/Nein. Das betrifft auch Gruppenaufschlüsselungen.

Weitere Farbstatus wie Fälligkeit, Teilnahmequote und Statusbadges müssen systematisch geprüft werden.

A11Y-08 – Icon-Buttons und dekorative Controls​

In mehreren Views werden flux:button-Elemente nur mit Icon als visuelle Dekoration verwendet, obwohl sie offenbar keine Aktion haben (z. B. Informationszeilen in der Proben-Detailansicht). Semantische Buttons ohne Aktion können unnötige Fokusziele erzeugen, falls Flux sie als echte Buttons rendert.

Umgekehrt werden an anderer Stelle direkt Icons als Aktionen verwendet. Es braucht eine klare Regel: dekoratives Icon ist nicht interaktiv; Aktion ist Button/Link mit Accessible Name.

A11Y-09 – Landmarks und Skip-Link​

Das Guest-Layout hat <main> und Navigation, aber keinen erkennbaren Skip-Link zum Hauptinhalt. Das App-Layout hat ebenfalls <main>, jedoch keinen erkennbaren Skip-Link. Bei umfangreicher Navigation erhöht das den Tastaturaufwand erheblich.

A11Y-10 – Mobile Überschriftenstruktur Auth​

Login/Registrierung enthalten ein h1 im linken Informationsbereich, dieser ist auf kleinen Displays vollständig hidden. Der sichtbare Formularbereich beginnt mit h2. Semantisch sollte pro Seite ein sinnvoller, auch mobil vorhandener Haupttitel existieren.

A11Y-11 – Cookie-Trigger als JavaScript-Link​

Das Guest-Layout öffnet das Cookie-Widget über <a href="#" onclick="...">Cookies</a>. Da dies eine Aktion und keine Navigation ist, sollte semantisch ein Button verwendet werden.

A11Y-12 – Externe Fonts / Layoutstabilität​

Nicht primär Accessibility, aber beim visuellen Audit zu berücksichtigen: unterschiedliche Layouts laden Fonts unterschiedlich. Zoom, große Schrift und Fallback-Fonts müssen getestet werden, damit Texte/Controls nicht abgeschnitten werden.

Noch manuell zu prüfen​

Diese Punkte lassen sich aus statischem Repository-Code nicht zuverlässig vollständig bewerten:

  • tatsächliche Farbkontraste aller gerenderten Zustände
  • Fokusindikatoren der Flux-Komponenten
  • Tastaturverhalten von Flux Dropdown, Tooltip, Select und Table Sort
  • tatsächliche Fokus-Rückgabe von Modals
  • Reflow bei 200 % / 400 % Zoom
  • Browser-Textvergrößerung und iOS Dynamic Type
  • Touch-Zielgrößen im realen Rendering
  • VoiceOver-Ausgabe zentraler Komponenten
  • prefers-reduced-motion
  • Fehlerverhalten nach Livewire-DOM-Updates
  • Public Homepage/Beta/Kirchenmusik bei Tastatur und Mobile

Priorisierte Umsetzung​

  1. Auth/Registrierung: Labels und Auswahlsemantik
  2. Semantische interaktive Controls / Tastaturbedienung
  3. Gemeinsames Modal-/Dialogmuster
  4. Livewire Status- und Fehlermeldungen
  5. Farbe-unabhängige Statusdarstellung
  6. Skip-Link/Landmarks/Überschriften
  7. automatisierter axe-/Browser-Regressionsschutz
  8. visueller Kontrast-/Zoom-/Reduced-Motion-Pass