Standards zur Barrierefreiheit #

Diese Seite richtet sich an Entwickler, die Templates erstellen oder prüfen, und an Administratoren, die für eine Beschaffung, ein Audit oder ihre eigenen Benutzer die Frage „Ist Exponential barrierefrei?“ beantworten müssen. Sie führt die Standards zur Barrierefreiheit auf, die für ein Web-Content-Management-System gelten, sagt zu jedem, was Exponential 6.0.x tut, verweist auf die Dateien und Tests, die es belegen, und benennt die Lücken ehrlich.

Hinweis Exponential ist Software. Ob eine damit erstellte Website barrierefrei ist, hängt auch von ihrem eigenen Design, ihren Templates und den Inhalten ab, die ihre Redakteure veröffentlichen. Die folgenden Aussagen betreffen die Teile, die mit Exponential ausgeliefert werden.

Zusammenfassung #

WCAG 2.2 #

Was es ist #

Die Web Content Accessibility Guidelines 2.2 sind eine W3C-Empfehlung (erstmals im Oktober 2023 veröffentlicht), herausgegeben von der W3C Web Accessibility Initiative. Stufe AA ist die Stufe, die Gesetze und Beschaffungsregeln üblicherweise verlangen. WCAG 2.2 fügt WCAG 2.1 neun Erfolgskriterien hinzu, darunter 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements und 2.5.8 Target Size (Minimum).

Wie Exponential sie erfüllt #

Die Arbeit konzentriert sich auf das Administrationsdesign admin4 (design/admin4/) und seine Layoutvariante admin4l (design/admin4l/). Sie ist in das Design admin4 und in der Referenz für Mitwirkende admin4-Styling beschrieben. Die Design-Tests laufen ohne Datenbank in der Testsuite design von phpunit.xml (tests/tests/design/), die der PHPUnit-Workflow (.github/workflows/phpunit.yml) mit jeder Suite von phpunit.xml ausführt.

Das Hilfesystem folgt denselben Regeln: ein h1 pro Seite, benannte Navigations-Landmarks, beschriftete Suchfelder, ein sichtbarer Fokusring, ein Hinweis bei Links, die ein neues Fenster öffnen, und Suchergebnisse, die Screenreadern angesagt werden (Hilfesystem: Sprachen und Barrierefreiheit).

Eine Zählung der ARIA-Attribute in design/admin4/templates/ (Oktober 2026) gibt eine Vorstellung von der Abdeckung: etwa 400 Verwendungen von aria-labelledby, 390 von aria-hidden, 380 von aria-label, 215 von aria-describedby, 110 von aria-current und 65 von aria-live.

Automatisierte Prüfungen mit der axe-Engine werden bei Reviews von Hand ausgeführt, nicht in der CI. Ihre Ergebnisse sind im Changelog 6.0.15 festgehalten: zum Beispiel „axe meldet im Seitenrahmen auf 10 klassischen Seiten bei 1440 px und bei 960 px mit 200 % Zoom keinen schwerwiegenden Befund“ (klassischer Admin, #522), 13 schwerwiegende Befunde im Standard-Inhaltsbearbeitungsformular behoben, ein Fehler bei der Zielgröße und ein Kontrastfehler bei erzwungenen Farben behoben.

Status #

Teilweise erfüllt. Die Administrationsoberfläche admin4 und admin4l ist nach den Kriterien von WCAG 2.2 AA gestaltet und mit Regressionstests abgesichert. Das ist nicht dasselbe wie eine Konformitätserklärung: Es gibt kein vollständiges Audit jeder Seite, kein Testprotokoll mit assistiven Technologien, und mehrere Teile des Produkts wurden nicht geprüft (siehe unten).

Bekannte Lücken #

• Öffentliche Website-Designs sind nicht geprüft. design/standard, design/base, design/plain, design/mysite und die Website-Designs, die als Pakete kommen (ezwebin, die Medien-Themes, Starter-Websites), haben nur gezielte Korrekturen erhalten (das Standard-Inhaltsbearbeitungsformular). Ihre Barrierefreiheit liegt in der Verantwortung dessen, der die Website erstellt.
• Die klassische Administrationsoberfläche (design/admin) und admin3 haben Korrekturen bei Beschriftungen und für schmale Fenster erhalten, werden aber nicht von den Kontrast-, Landmark- und Formularfehlertests abgedeckt, die admin4 absichern.
• Online-Editor. Die Integrationen von TinyMCE 8 und TinyMCE 3 (extension/ezoe) wurden nicht auf WCAG geprüft; die Barrierefreiheit der Editor-Engine selbst ist die des TinyMCE-Projekts. Nicht geprüft.
• Extensions, die als separate Pakete ausgeliefert werden (Layout-Editor, Newsletter, Shop), werden einzeln geprüft; einige Korrekturen sind im Changelog festgehalten, eine Gesamtaussage gibt es nicht.
• Keine automatisierte Engine zur Barrierefreiheit in der CI. Die Tests lesen Template- und Stylesheet-Quellen; sie rendern keine Seiten in einem Browser. axe-Läufe erfolgen manuell.
• Kein veröffentlichter Konformitätsbericht (WCAG-EM-Evaluierung, VPAT oder Accessibility Conformance Report).
• Inhalte. Alternativtext, Überschriftenreihenfolge und Linktext in veröffentlichten Inhalten hängen von den Redakteuren ab. Die Bild-Datentypen bieten ein Feld für Alternativtext; nichts zwingt Redakteure, es auszufüllen.

WAI-ARIA 1.2 und die ARIA Authoring Practices #

Was es ist #

Accessible Rich Internet Applications (WAI-ARIA) 1.2 ist eine W3C-Empfehlung (Juni 2023), die Rollen, Zustände und Eigenschaften für assistive Technologien definiert. Der ARIA Authoring Practices Guide (APG), eine Note des W3C WAI, zeigt, wie man damit gängige Widgets (Reiter, Menüs, Aufklappelemente, Dialoge) baut.

Wie Exponential sie erfüllt #

• Reitermuster: Knotenreiter in admin4 (design/admin4/javascript/node_tabs.js), abgesichert durch tests/tests/design/AdminKeyboardTest.php.
• Aufklapp-Navigation: Das optionale Mega-Menü (menu.ini [TopAdminMenu] MegaMenuTabs[]) belässt den Reiter als Link und fügt daneben eine Schaltfläche mit aria-expanded hinzu (tests/tests/design/AdminMegaMenuTest.php).
• Menü: Die Kontextmenüs (ezpopupmenu.js) haben Rollen und Tastaturunterstützung (tests/tests/design/AdminContextMenuTest.php).
• Umschaltflächen: aria-pressed für die Engine-Umschaltung des Editors und segmentierte Bedienelemente (TinyMCE 8).
• Live-Regionen: Toasts und Ergebnisse der Hilfesuche (aria-live).
• Erste Regel von ARIA: Native Elemente werden bevorzugt. Der Test für Formularbeschriftungen akzeptiert keinen title als Namen, und aria-label darf keine sichtbare Beschriftung mit Text ersetzen (AdminFormLabelsTest.php).

Status #

Teilweise erfüllt für admin4 und admin4l, wo die Muster an den Template-Quellen getestet werden. Nicht verifiziert an anderer Stelle; klassische Designs enthalten noch ältere JavaScript-Widgets.

Bekannte Lücken #

• Die Tests prüfen das Markup und die Ansatzpunkte, die die Skripte verwenden, nicht das Laufzeitverhalten in einem Screenreader.
• Kein Test gleicht jedes Widget mit seinem APG-Muster ab.

EN 301 549 #

Was es ist #

EN 301 549 „Accessibility requirements for ICT products and services“, v3.2.1 (2021-03), herausgegeben von ETSI, CEN und CENELEC. Sie ist die harmonisierte Norm der EU-Richtlinie über den barrierefreien Zugang zu Websites (2016/2102) und die Referenz für den European Accessibility Act (2019/882). Ihr Abschnitt 9 (Web) übernimmt WCAG 2.1 Stufe AA; Abschnitt 11 (Software) und Abschnitt 12 (Dokumentation und Support) gelten auch für Autorenwerkzeuge.

Wie Exponential sie erfüllt #

Die Arbeit an WCAG 2.2 AA für admin4 deckt die Kriterien von WCAG 2.1 AA ab, die Abschnitt 9 verlangt (WCAG 2.2 ist eine Obermenge, außer bei 4.1.1 Parsing, das 2.2 gestrichen hat). Die Dokumentation des Hilfesystems folgt denselben Regeln.

Status #

Nicht geprüft. Es wurde keine Evaluierung nach EN 301 549 durchgeführt, und Abschnitt 11.8 (Autorenwerkzeuge, zum Beispiel, dass das Werkzeug Autoren hilft, barrierefreie Inhalte zu erstellen) wurde nicht geprüft.

Bekannte Lücken #

• Keine Vorlage für eine Erklärung zur Barrierefreiheit für Websites, wie sie die Richtlinie über den barrierefreien Zugang zu Websites von öffentlichen Stellen verlangt.
• Abschnitt 11.8 (Unterstützung durch das Autorenwerkzeug: Aufforderungen zu Alternativtext, barrierefreie Ausgabe von Rich Text) nicht bewertet.

Section 508 #

Was es ist #

Section 508 des US Rehabilitation Act verpflichtet Bundesbehörden, barrierefreie IKT zu beschaffen. Die Revised 508 Standards (US Access Board, 2017) übernehmen WCAG 2.0 Stufe AA per Verweis. Anbieter dokumentieren die Konformität üblicherweise in einem VPAT (Voluntary Product Accessibility Template), aus dem ein Accessibility Conformance Report entsteht.

Wie Exponential sie erfüllt #

Inhaltlich durch die oben beschriebene WCAG-Arbeit; WCAG 2.0 AA ist eine Teilmenge dessen, wogegen admin4 getestet wird.

Status #

Nicht geprüft. Es gibt kein VPAT und keinen Accessibility Conformance Report für Exponential.

Für Template-Autoren #

• Folgen Sie dem admin4-Styling: gemeinsame Komponenten (.a4-btn, .a4-card, .a4-sr-only), nur Tokens, ein dunkler Wert für jedes neue Farb-Token, kein Inline-CSS.

• Führen Sie nach einer Template-Änderung die Design-Tests aus:

  php vendor/bin/phpunit --testsuite design

• Prüfen Sie eine geänderte Seite im hellen und dunklen Modus, bei 1440 px und bei 960 px mit 200 % Zoom sowie allein mit der Tastatur.

Verwandte Seiten #

• Sicherheitsstandards, Datenschutzstandards, Standards der Webplattform
• Das Design admin4
• Sprachen mit Schreibrichtung von rechts nach links
• Tastenkürzel