Accessibility Tools Konfiguration: WCAG-Feedback für Redakteure via editoria11y
editoria11y (bereits in composer.json) wird aktiviert und für WCAG 2.1 AA konfiguriert. Redakteure und Administratoren erhalten ein informatives Feedback-Panel direkt im Frontend. Admin-Chrome wird aus dem Scan ausgeschlossen. Der Dashboard-Block zeigt eine siteweite Übersicht offener Issues. Kein Publishing-Gate. Alle Einstellungen landen in config/sync/. approved · Erstellt: 2026-05-12 · Jira: P2503-103
Problem Statement
Redakteure erstellen und bearbeiten Inhalte auf der SOLCOM-Website, ohne direktes Feedback zu erhalten, ob der Content WCAG 2.1 AA-konform ist. Barrierefreiheitsprobleme (fehlende Alt-Texte, falsche Überschriftenhierarchien, unzureichende Link-Texte) werden erst spät — wenn überhaupt — erkannt und müssen dann nachträglich korrigiert werden. Für die öffentliche Corporate-Website gilt BITV 2.0 (WCAG 2.1 AA) als gesetzlicher Mindeststandard.
Solution
Das Modul editoria11y wird aktiviert und konfiguriert. Es zeigt Redakteuren und Administratoren ein Panel mit WCAG-Befunden direkt auf der gerenderten Seite — ohne Medienbruch, ohne separates Audit-Tool. Befunde werden interaktiv inline markiert. Das Feedback ist informativ: Redakteure können trotz offener Issues publizieren. Eine siteweite Übersicht offener Issues erscheint im Drupal-Dashboard.
editoria11y) ist per Projektleitungs-Entscheidung bestätigt. Dieses PRD spezifiziert ausschließlich die Konfiguration — keine Evaluation alternativer Tools.
User Stories
- Als Redakteur möchte ich bei der Erstellung von Inhalten ein direktes WCAG-Feedback erhalten, damit ich Barrierefreiheit bereits im Editor sicherstellen kann.
- Als Redakteur möchte ich sehen, welche konkreten Elemente auf der Seite ein Accessibility-Problem verursachen, damit ich gezielt korrigieren kann.
- Als Redakteur möchte ich, dass das Feedback-Panel nur für mich sichtbar ist (nicht für anonyme Besucher), damit die UX der öffentlichen Seite unverändert bleibt.
- Als Redakteur möchte ich trotz offener Accessibility-Issues publizieren können, damit der Redaktionsfluss nicht blockiert wird.
- Als Redakteur möchte ich, dass Drupal-Admin-Elemente (Toolbar, Navigation) keine Befunde erzeugen, die ich nicht kontrollieren kann.
- Als Administrator möchte ich eine siteweite Übersicht aller offenen Accessibility-Issues sehen, damit ich den Gesamtstatus des Contents beurteilen kann.
- Als Administrator möchte ich die editoria11y-Konfiguration über die Drupal-Oberfläche verwalten, damit ich Einstellungen ohne Code-Deployment anpassen kann.
- Als Entwickler möchte ich, dass alle editoria11y-Einstellungen in
config/sync/liegen, damit neue Instanzen (Staging, Produktion) keine manuelle Nachkonfiguration benötigen.
Implementation Decisions
Diese Story erfordert ausschließlich Drupal-Konfiguration — kein Custom-Modul-Code.
Permissions
| Permission | Rolle | Begründung |
|---|---|---|
view editoria11y checker | Redakteur | Zeigt das Feedback-Panel im Frontend |
administer editoria11y checker | Administrator | Konfigurationszugang |
manage editoria11y results | Administrator | Dashboard-Zugriff, Dismissals verwalten |
mark as ok in editoria11y | Administrator | False Positives für alle Nutzer unterdrücken |
editoria11y-Einstellungen (editoria11y.settings)
| Einstellung | Wert | Begründung |
|---|---|---|
content_root | leer (gesamte Seite) | Vollständige Seitenprüfung gewünscht |
ignore_elements | .toolbar, #toolbar-administration, footer, nav | Admin-Chrome und strukturelle Elemente aus Scan ausschließen — Redakteure können diese nicht ändern |
ed11y_theme | sleekTheme | Standard — passt visuell zum Admin-Theme |
panel_pin | right | Standard |
watch_for_changes | checkRoots | Standard — Live-Feedback bei Canvas/Editor-Änderungen |
ck5_table_headers | row | Standard für CKEditor 5 |
disable_live | false | Live-Feedback im Editor aktiv lassen |
Dashboard-Block
Der View-Block a11y_tools_editoria11y_results-block_a11y_alerts ist bereits im Dashboard-Config referenziert (dashboard.dashboard.welcome.yml). Nach Modulaktivierung erscheint er automatisch für Nutzer mit manage editoria11y results-Permission. Keine manuelle Konfiguration des Blocks notwendig — die bestehende Config-Referenz ist ausreichend.
Testing Decisions
Gute Tests prüfen beobachtbares Verhalten aus Nutzerperspektive — nicht interne Konfigurationswerte.
Manuelle Akzeptanztests (obligatorisch)
- Panel-Sichtbarkeit: Als Nutzer mit Redakteurs-Rolle eine Seite im Frontend besuchen → editoria11y-Panel ist sichtbar.
- Panel-Unsichtbarkeit: Als anonymer Nutzer dieselbe Seite besuchen → kein Panel sichtbar.
- Befund-Erkennung: Bild ohne Alt-Text auf einer Seite einfügen → Panel zeigt den Befund korrekt an und markiert das Element inline.
- Admin-Chrome-Ausschluss: Das Drupal-Toolbar-Element erzeugt keinen Befund im Panel.
- Config-Reproduzierbarkeit: Nach
drush cimauf einer frischen Instanz ist das Modul aktiv und die Konfiguration vollständig.
Kein Automated-Test-Setup
Für reine Konfigurationsstories ist kein PHPUnit-Test erforderlich. Drupal-Kern-Tests decken Permission-Checks bereits ab. Die Akzeptanzkriterien sind manuell verifizierbar.
Out of Scope
- Publishing-Gate (Blockieren des Publizierens bei offenen Issues)
- Custom WCAG-Tests via
editoria11y's Custom-Test-API - WCAG 2.2 AA (nur 2.1 AA)
- Automatisiertes CI/CD-Accessibility-Testing (separate Story)
- Integration mit externen Audit-Tools (axe, WAVE, Lighthouse)
- Accessibility-Schulung für Redakteure (organisatorisches Thema)
- SOLCOM-eigene Ignore-Liste für projektspezifische Komponenten (Post-Launch-Tuning)
Further Notes
- Das Modul
editoria11yv2.2 ist bereits incomposer.jsonvorhanden — keincomposer requirenotwendig. - Die Dashboard-Config referenziert bereits den a11y-Block — der Block erscheint nach
pm:enableautomatisch. ignore_elementssollte nach dem ersten produktiven Einsatz evaluiert werden: weitere Elemente (z.B. Canvas-Toolbar-Komponenten) könnten ergänzt werden.- Story-Doc mit Akzeptanzkriterien: stories/F-220-accessibility-tools-konfiguration.html
- Refinement durchgeführt: 2026-05-12 via
grill-with-docs