Zum Inhalt springen

Erklärung zur Barrierefreiheit

Alcometer.org arbeitet daran, den Rechner zur Blutalkoholkonzentration sowie Inhalte zu Kater, Erholung und Flüssigkeitszufuhr für möglichst viele Menschen zugänglich zu machen, einschließlich Menschen mit visuellen, motorischen, auditiven, kognitiven und neurologischen Unterschieden.

Konformitätsziel

Wir streben die Einhaltung der Web Content Accessibility Guidelines (WCAG) 2.2 auf Stufe AA an, veröffentlicht vom W3C. Dieses Ziel steht im Einklang mit EN 301 549 und dem European Accessibility Act; WCAG 2.1 AA gilt dabei als Mindestniveau.

Das Repository enthält eine ausführbare axe-core- und Puppeteer-Basisprüfung für die wichtigsten Alcometer-Werkzeugrouten. Weitere Korrekturen sollen bekannte Probleme beheben, ohne neue Regressionen einzuführen.

Bekannte Lücken sind unten aufgeführt und werden vor dem Launch-Gate automatisch und manuell geprüft.

Aktuelle automatische Testabdeckung

Das Projekt führt npm run test:alcometer:a11y aus: Die Website wird gebaut, Astro preview gestartet, ein kuratierter Satz von Werkzeugrouten geöffnet, axe-core über @axe-core/puppeteer injiziert und gegen die Tags wcag2aa und wcag22aa geprüft.

Die aktuelle Basis liegt in test/a11y-baseline.json; der neueste Bericht wird in reports/a11y-run.json geschrieben. Die Basis verfolgt ernsthafte und kritische Befunde, damit spätere Commits Regressionen ausschließen können.

Der Barrierefreiheits-Job in GitHub Actions bleibt bis zum finalen Launch-Gate bewusst nicht blockierend und lädt Basis sowie Bericht als Review-Artefakte hoch.

Was das praktisch bedeutet

• Interaktive Steuerelemente sollten möglichst native HTML-Elemente verwenden, mit sichtbarem Fokus und Bedienbarkeit per Tastatur.

• SVG- und diagrammartige Datenvisualisierungen sollten eine gleichwertige Text- oder Tabellenalternative bereitstellen, wenn die Grafik Informationen trägt.

• Dialoge müssen die Fokusreihenfolge bewahren und einen klaren Weg zum Abbrechen oder Schließen anbieten.

• Die Dokumentsprache wird auf jeder generierten Seite über das Attribut <html lang> deklariert.

Bekannte Einschränkungen

Die erste axe-core-Basis kann noch ernsthafte oder kritische Befunde enthalten, die in Folge-Commits bearbeitet werden. Bis zum finalen Gate blockiert der Runner Regressionen gegenüber der Basis, statt bereits Null Befunde zu behaupten.

Einige Datenvisualisierungen enthalten bereits Alternativen für Screenreader, aber Diagrammtexte und Sprachparität benötigen weiterhin eine manuelle Prüfung mit assistiven Technologien.

Rechts-nach-links-Sprachen haben noch keine eigenen RTL-Layouts; Inhalte nutzen derzeit die verfügbare LTR-Oberfläche, sofern diese Route unterstützt wird.

Wie wir testen

• Automatisch: axe-core über @axe-core/puppeteer auf Astro preview, beschränkt auf wcag2aa und wcag22aa.

• Regressionsbericht: reports/a11y-run.json.

• Eingefrorene Basis: test/a11y-baseline.json.

• Manuelle Prüfung bleibt nötig für Tastaturfluss, Screenreader-Texte, kognitive Klarheit, Zoomverhalten und visuelle Regressionen.

Automatische Werkzeuge erfassen nur einen Teil der WCAG-Konformität. Vor dem Launch ist eine menschliche Prüfung erforderlich, besonders für den Rechner, die Compliance-Abfrage und seiten mit vielen Diagrammen.

Feedback und Kontakt

Wenn Sie eine Barriere entdecken, zum Beispiel fehlende Alternativtexte, eine Tastaturfalle, ein Kontrastproblem, eine unklare Fokusreihenfolge oder eine andere Schwierigkeit, kontaktieren Sie uns bitte.

E-Mail: alcometer@wp.pl

Postanschrift: Piotr Zieminski, Kalonka 71a, Polen

Bitte nennen Sie: (1) die betroffene URL, (2) eine kurze Beschreibung der Barriere, (3) Ihre assistive Technologie, falls relevant.

Durchsetzung

Wenn Sie mit unserer Antwort nicht zufrieden sind, können Sie sich an die zuständige nationale Durchsetzungsstelle nach dem European Accessibility Act wenden. Für Polen ist dies das Urząd Komunikacji Elektronicznej (UKE, https://www.uke.gov.pl/).

Erstellung dieser Erklärung

Diese Erklärung wurde am 25. April 2026 aktualisiert, nachdem die axe-core-Basis und der nicht blockierende CI-Job zur Barrierefreiheit ergänzt wurden.

Die nächste Überprüfung ist für den 25. April 2027 geplant oder früher, wenn sich Seitentemplates, Rechneroberfläche oder Barrierefreiheitswerkzeuge wesentlich ändern.