Erklärung zur Barrierefreiheit

Wir arbeiten daran, die Web Content Accessibility Guidelines (WCAG) 2.1, Stufe AA, zu erfüllen. Dies ist der weltweit in Barrierefreiheitsgesetzen am häufigsten geforderte Standard, und genau diesen Standard legen wir für die gesamte Plattform an – nicht nur für einige wenige Vorzeigeseiten.

Wir führen eine echte, automatisierte Prüfung durch – axe-core, gesteuert über Playwright – für eine repräsentative Auswahl der Seiten der Plattform: die öffentliche Startseite, die Seiten für Registrierung, Anmeldung und Passwort-Zurücksetzen, die öffentlichen Stellenanzeigen und rechtlichen Seiten sowie nach der Anmeldung das Dashboard, Stellenangebote, Nachweise, Einstellung, Widersprüche, Datenschutz, Assessments, Creator-Bereich, Skill-Guide, Discovery-Spiel und Admin-Seiten.

Jede Seite wird in drei Sprachen gescannt: Englisch (von links nach rechts), Arabisch (von rechts nach links – die Richtung, in der ein Fehler am ehesten sichtbar wird, den eine rein englischsprachige Prüfung übersehen würde) und Spanisch (eine zweite von links nach rechts geschriebene Sprache, um Probleme zu erkennen, die mit der Textlänge zusammenhängen und nicht speziell mit englischsprachigen Inhalten). Angemeldete Seiten werden sowohl als gewöhnliches Bewerberkonto als auch, wo relevant, als Plattform-Administrator gescannt.

Das Prüfskript ist im Code unter scripts/a11y-audit.mjs hinterlegt und läuft mit einem einzigen Befehl, npm run check:a11y, sodass es vor jeder Veröffentlichung erneut ausgeführt werden kann, anstatt sich darauf zu verlassen, dass es über die Zeit hinweg korrekt bleibt.

Zum oben genannten Datum wurden 54 Kombinationen aus Seite und Sprache geprüft (18 verschiedene Seiten × 3 Sprachen), wobei zunächst drei echte, klar abgrenzbare Mängel gefunden wurden:

Alle drei Mängel wurden direkt im Quellcode behoben: Text- und Linkfarben wurden auf Farbtöne umgestellt, die das von WCAG 2.1 AA für normal großen Text geforderte Kontrastverhältnis von 4,5:1 erfüllen, jedes betroffene Label wurde mit seinem Eingabefeld verknüpft, und beide Dropdown-Menüs erhielten einen echten, zugänglichen Namen, der beschreibt, was sie steuern.

Anschließend wurde dieselbe automatisierte Prüfung erneut über alle 54 Kombinationen aus Seite und Sprache ausgeführt und ergab keine Verstöße mehr. Genau dieses Ergebnis – nicht nur diese Erklärung – ist gemeint, wenn hier von „durch eine echte Prüfung belegt“ die Rede ist.

Wir möchten offen über die Grenzen automatisierter Tests sprechen, anstatt ein sauberes Prüfergebnis mehr bedeuten zu lassen, als es tatsächlich aussagt. Werkzeuge wie axe-core erkennen zuverlässig einen wesentlichen Teil der Barrierefreiheitsmängel – fehlende Labels, unzureichenden Kontrast, ungültiges ARIA und Ähnliches –, doch laut der Dokumentation des Werkzeugs selbst können automatisierte Prüfungen allein nur etwa ein Drittel bis zwei Fünftel der WCAG-Erfolgskriterien erfassen. Sie können nicht beurteilen, ob der Alternativtext eines Bildes es tatsächlich beschreibt, ob Inhalte für jemanden, der nur mit Tastatur oder Screenreader navigiert, in einer sinnvollen Reihenfolge vorgelesen werden, oder ob ein Tastaturnutzer in einem Teil der Seite hängen bleiben kann.

Wir haben noch keinen eigenen manuellen Durchgang mit einem Screenreader (etwa NVDA oder VoiceOver), keinen vollständigen, rein tastaturbasierten Durchlauf jedes Ablaufs und keine Tests mit Menschen abgeschlossen, die assistive Technologien im Alltag nutzen. Das sind echte, klar benannte Lücken in unserem aktuellen Prozess, die wir nicht verschweigen – sie zu schließen ist eine gesonderte Folgearbeit.

Die Seitenliste des Prüfskripts wächst mit der Plattform, und wir beabsichtigen, es vor jeder Veröffentlichung einer Änderung an einer von ihm abgedeckten Seite auszuführen. Zum Zeitpunkt dieser Erklärung ist die Ausführung ein manueller Schritt und kein automatisches Gate in einer kontinuierlichen Integration – dieses Projekt verfügt bislang über keine CI-Pipeline, was für sich genommen eine bekannte Lücke darin ist, wie wir Änderungen generell veröffentlichen, und nicht spezifisch für Barrierefreiheit ist.

Wenn Sie assistive Technologien nutzen und bei Talaskill auf etwas stoßen, das nicht wie erwartet funktioniert, möchten wir davon erfahren. Kontaktieren Sie Talaskill1@gmail.com und nennen Sie die Seite, auf der Sie sich befanden, sowie was passiert ist – wir behandeln dies als echten Fehler, mit derselben Ernsthaftigkeit wie jeden anderen auf diesem Weg gemeldeten Mangel.