Transparenz der Barrierefreiheit

Unser Arbeitsstandard

Wir verwenden WCAG 2.1 Level AA als unseren Arbeitsstandard für die Produktzugänglichkeit. Wir übernehmen auch ausgewählte AAA-Ideen, wenn sie die Benutzerfreundlichkeit deutlich verbessern, erheben jedoch keinen Anspruch auf AAA-Konformität.

Wir behaupten nicht, dass jede Route immer perfekt ist. Wir verpflichten uns, verifizierte Hindernisse zu beheben, Änderungen zu dokumentieren und die Arbeiten zur Barrierefreiheit im normalen technischen Arbeitsablauf beizubehalten.

Richtlinie zur Unterstützung unterstützender Technologien

Wir veröffentlichen Supporterwartungen basierend auf den Kombinationen, die wir direkt überprüfen, und den Kombinationen, die wir im Rahmen geplanter Audits überprüfen. Hierbei handelt es sich um eine Support-Matrix und nicht um den Anspruch, dass sich jede Kombination aus Browser und unterstützender Technologie identisch verhält.

Wenn Benutzer ein Hindernis für eine Best-Effort-Kombination melden, untersuchen wir dies trotzdem. Wenn sich das Problem auf die Kernsemantik, das Tastaturverhalten oder gemeinsame Komponenten auswirkt, behandeln wir es als Produktfehler, selbst wenn die genaue Paarung nicht im primär verifizierten Satz enthalten ist.

Einstellungs- und Änderungsrichtlinie

• Wir stellen die Unterstützung für eine Kombination aus verifiziertem Browser und unterstützender Technologie nicht absichtlich ein, ohne die Änderung zuvor auf dieser Seite zu veröffentlichen.
• Wenn die Unterstützung einer verifizierten Kombination aufgrund von Anbieter-, Plattform- oder Sicherheitsbeschränkungen nicht mehr möglich ist, streben wir eine Benachrichtigung in mindestens einem vierteljährlichen Zyklus an, bevor sie in den Best-Effort-Status übergeht.
• Jede Einstellungsmitteilung sollte die betroffene Kombination, den Grund für die Änderung, das Datum des Inkrafttretens und die nächstgelegene unterstützte Alternative enthalten.

Wenn sich eine gemeldete Barriere auf eine Kombination auswirkt, die wir derzeit direkt überprüfen, wird das Problem anhand dieser Supporterwartung beurteilt und nicht als optional behandelt.

Überprüfung der Zugänglichkeit von Abhängigkeiten Dritter

Die meisten geprüften PayCal-Interaktionen verwenden Erstanbieter-UI-Code. Wenn browserseitiger Code von Drittanbietern vorhanden ist, verfolgen wir dessen Auswirkungen auf die Barrierefreiheit separat, damit bei Upgrades die Tastatur-, Semantik- oder CSP-Erwartungen nicht umgangen werden.

• Genehmigt: zur aktuellen Nutzung zugelassen, wobei die Auswirkungen auf die Barrierefreiheit verstanden und dokumentiert sind.
• Bedingt: Dies ist nur in begrenztem Umfang zulässig, während Überprüfungs-, Austausch- oder Eindämmungsarbeiten noch offen sind.
• Blockiert: Die Nutzung der neuen Benutzeroberfläche ist erst zulässig, wenn die Barrierefreiheitsanforderungen erfüllt sind.

Jede neue browserseitige Abhängigkeit, die Benutzeroberfläche, Fokusbehandlung, Dialogverhalten, eingebettete Medien oder benutzerdefinierte Widgets hinzufügt, sollte vor der Einführung überprüft und vor größeren Versions-Upgrades erneut überprüft werden.

Was ist jetzt vorhanden?

• Die Kernnavigation unterstützt die Verwendung der Tastatur, das Überspringen von Links und dokumentierte Einzeltastenkürzel für wichtige Ziele.
• Für die Hauptanwendungsrouten sind Einzeltastenkürzel (C, R, S, E, A, H, N, P, ?) dokumentiert.
• Verknüpfungen werden nicht ausgelöst, während Eingaben eingegeben werden oder wenn Dialoge geöffnet sind.
• Hilfe- und Transparenzrouten bieten mehr als eine Möglichkeit zur Navigation, einschließlich Breadcrumbs, wenn dies nützlichen Kontext hinzufügt.
• Geprüfte Routen verwenden semantische Orientierungspunkte, klare Überschriften, direkte Beschriftungen und Statusmeldungen, wenn die Interaktion Feedback erfordert.
• Kontrast- und Fokus-Token-Prüfungen werden im gesamten aktuellen Themenkatalog automatisiert und die veröffentlichte Matrix wird in unserem Barrierefreiheits-Backlog-Workflow verfolgt.
• Zu den Einstellungen gehört eine Legasthenie-freundliche Typografieeinstellung mit zugänglichen Abständen und Fallback-Stack-Unterstützung.
• Barrierefreiheitsberichte können jetzt auf dieser Seite beginnen und mit den vorab ausgefüllten Schlüsseldetails in den sicheren Kontaktablauf übergehen.

Wir bevorzugen zunächst semantisches HTML und verwenden ARIA, wenn es dabei hilft, Namen, Beziehungen oder Live-Statusänderungen klarer darzustellen.

Schnellzugriffstasten

PayCal veröffentlicht Tastenkombinationen für wichtige Ziele, sodass häufige Routen ohne wiederholte Zeigerbewegungen erreichbar bleiben. Der aktuell dokumentierte Satz umfasst Kalender, Organisationen, Einstellungen, Einnahmen, Verwaltung, Hilfe, Notizen, Zahlungsperioden und Hilfe zu Tastenkombinationen.

Diese Verknüpfungen sind nur dann Teil des Barrierefreiheitsvertrags, wenn sie vorhersehbar und dokumentiert sind und sicher ignoriert werden können. Benutzer können weiterhin mit Standardlinks, Schaltflächen, Sprunglinks und Orientierungspunkten navigieren, ohne auf das Auswendiglernen von Verknüpfungen angewiesen zu sein.

Fokus Sicherheit

Fokussicherheitsregeln verhindern, dass Shortcut-Handler und die Skript-Benutzeroberfläche den Fokus stehlen, während jemand in einem Modal tippt oder arbeitet. Verknüpfungen werden nicht innerhalb bearbeitbarer Steuerelemente ausgelöst und Dialoginteraktionen behalten den Fokusbereich, bis der Dialog geschlossen wird.

Diese Richtlinie reduziert versehentliche Navigation, schützt die Formulareingabe und sorgt dafür, dass das Tastaturverhalten mit der Regressionsabdeckung auf Routenebene in Einklang steht, die wir in Playwright und Lightpanda ausführen.

Was wir aktiv überprüfen

• WCAG-Scans auf Routenebene werden auf Kernseiten durchgeführt, einschließlich strenger Routen-Sweeps auf Verstöße und strengerer Kontrastprüfungen.
• Überschriften- und Formularregressionen werden überprüft, damit Orientierungspunktstruktur, Beschriftungen und Wiederherstellungsnachrichten nicht unbemerkt abweichen.
• Die Reflow- und Textabstandsabdeckung überprüft Kernrouten bei kompakten Ansichtsfensterbreiten, um horizontale Überläufe und Abstandsfehler zu erkennen.
• Navigationspfad- und Shortcut-Regressionstests überprüfen Breadcrumbs, alternative Pfade, Feedback-Übergabe, Shortcut-Sicherheitsverhalten und Tastaturkürzel-Richtlinienabdeckung.
• Prüfungen auf Suite-Ebene kombinieren Playwright, PHPUnit und die Browser-Matrix-Abdeckung, sodass Zugänglichkeitsansprüche weiterhin testgestützt bleiben.

Das bedeutet, dass unsere öffentlichen Erklärungen zur Barrierefreiheit an die tatsächliche Regressionsabdeckung gebunden sind und nicht nur an der Absicht.

Aktuelle Verbesserungen

• 23.03.2026: Über 30 Design-Tokens für Statusleisten, Verifizierungsbanner, Countdown-Timer und Formular-/Dialogabstandskomponenten angewendet, alle direkten Farbkopplungen aus gemeinsamen Stilen entfernt und die Kontrastmatrix erweitert, um die neuen Token-Paare abzudecken (WCAG-020).
• 23.03.2026: Verifizierungsmetadaten (Datum der letzten Verifizierung, Datum der nächsten Überprüfung, Umfang und bekannte Einschränkungen) wurden allen vier aktiven Transparenz-Unterseiten hinzugefügt: Zugänglichkeit, Kennzahlen, Steuern und Verifizierungs-Governance (WCAG-021).
• 23.03.2026: 31 Fehler- und Statuszeichenfolgen in Authentifizierungs-, Kalender- und Organisationsabläufen vereinfacht: Fachjargon (Nonce-Referenzen) entfernt, feldleere Nachrichten umsetzbar gemacht und Organisationsfehlermeldungen auf ein konsistentes „Konnte nicht X. Bitte versuchen Sie es erneut“ standardisiert. Muster (WCAG-024).
• 23.03.2026: Veröffentlichte Barrierefreiheitsstandards auf Komponentenebene für Dialoge, Registerkarten, Datenraster und Formulare mit Tastatur-/ARIA-Verträgen und Do/Don't-Beispielen; vernetzt aus PR-Vorlage und Regressionsworkflow (WCAG-025).
• 23.03.2026: Durchsetzungsfähige Fehlermeldungen von höflichen Fortschrittsankündigungen in /auth/ und /settings/ getrennt, um doppelte Live-Region-Ausgaben zu entfernen (WCAG-017).
• 23.03.2026: SLA-Tabelle für Barrierefreiheitsdefekte mit Bestätigungsfenstern, Fixzielen, Eigentümern und Eskalationspfaden veröffentlicht (WCAG-019).
• 23.03.2026: Veröffentlichung einer formellen Checkliste für verbleibende Arbeiten und eines vierteljährlichen Zugänglichkeitsaudits mit Eigentümern, Streckenabdeckung und Nachweisanforderungen.
• 23.03.2026: Dem sicheren Kontaktformular wurde ein Pfad zur Eingabe von Feedback zur Barrierefreiheit von dieser Seite hinzugefügt.
• 23.03.2026: Breadcrumbs und Regressionsabdeckung für mehrere Navigationspfade auf wichtigen öffentlichen Routen hinzugefügt.
• 23.03.2026: Strikte Kontrastblocker auf zentralen öffentlichen Routen wurden behoben und diese Überprüfungen wurden in der WCAG-Routensuite beibehalten.
• 23.03.2026: Legasthenie-freundliche Typografie-Präferenzabdeckung in den Einstellungen hinzugefügt, mit zugänglichem Verhalten bei Schriftartstapel und -abständen.
• 22.03.2026: Reflow- und Textabstandsabdeckung auf Routenebene für Kernseiten bei kompakten Ansichtsfensterbreiten hinzugefügt.
• 20.03.2026: Es wurden dokumentierte Tastenkombinationen im Anwendungsstil mit Schutzmaßnahmen hinzugefügt, sodass sie nicht während der Eingabe oder während geöffnete Dialoge ausgelöst werden.
• 2026-04-12: Added aria-label to the read-only current email input in change-email dialogs on settings and profile pages; replaced four hardcoded English labels in the Data Portability section with i18n-backed strings.

Was wir noch verbessern

• Externes Audit-Bereitschaftspaket: Problemhistorie, Korrekturprotokolle und Richtliniennachweise werden vorab zusammengestellt, sodass innerhalb eines Werktages ein vollständiges Audit-Paket erstellt werden kann (WCAG-026).

Aktuelle offene Arbeit

• WCAG-026: Externes Audit-Bereitschaftspaket – Paketierung von Problemhistorien, Korrekturprotokollen, Beweisartefakten und Richtliniendokumenten, damit innerhalb eines Werktages ein Audit-Beweispaket erstellt werden kann.

Dies ist das aktive Element in unserem WCAG-Ausführungsrückstand. Design-Tokens, Transparenz-Metadaten, Live-Region-Verträge, PR-Governance und Klartext-Kopierarbeiten wurden abgeschlossen und werden durch Regressions-Suites abgedeckt, um das Rückfallrisiko zu reduzieren.

Windows zur Reaktion auf Barrierefreiheitsdefekte

Jeder verifizierte Barrierefreiheitsmangel wird bei der Erstellung mit einem Schweregrad, einem Besitzer, einem WCAG-Kriterium und einem Fälligkeitsdatum abgelegt, sodass die Arbeit betriebsbereit und nicht informell bleibt.

Wie wir ARIA nutzen

Wir betrachten ARIA nicht als Ersatz für semantisches HTML. Wir verwenden ARIA, um Steuerelementnamen, Beziehungen, Beschreibungen und Statusänderungen zu klären, wenn natives HTML allein nicht ausreicht.

Das bedeutet, dass unsere Arbeit zur Barrierefreiheit über die alleinige Nutzung von ARIA hinausgeht. Ebenso wichtig sind Tastaturverhalten, Überschriften, Fokushandhabung, Kontrast, Reflow und Fehlerbehebung.

Standards und Richtlinien

Unsere Arbeit zur Barrierefreiheit orientiert sich in erster Linie an WCAG 2.1 und verwandten rechtlichen Standards, die sich auf die Erwartungen der Stufe AA beziehen.

• WCAG 2.1 (W3C Web Content Accessibility Guidelines) – Internationaler Standard für Web-Barrierefreiheit
• Abschnitt 508 (US-Bundesgesetz) – Entspricht WCAG 2.0 Level AA
• EN 301 549 (Europäische Norm) – Entspricht WCAG 2.1 Level AA
• AODA (Accessibility for Ontariors with Disabilities Act) – Verweist auf WCAG-konforme Barrierefreiheitserwartungen in Kanada