Toegankelijkheid Transparantie

Onze werkstandaard

We gebruiken WCAG 2.1 Niveau AA als onze werkstandaard voor producttoegankelijkheid. We nemen ook geselecteerde AAA-ideeën over als deze de bruikbaarheid duidelijk verbeteren, maar we claimen geen AAA-conformiteit.

Wij beweren niet dat iedere route altijd perfect is. We verbinden ons ertoe geverifieerde barrières op te lossen, wijzigingen te documenteren en toegankelijkheid binnen de normale engineeringworkflow te houden.

Beleid voor ondersteunende technologie

We publiceren ondersteuningsverwachtingen op basis van de combinaties die we rechtstreeks verifiëren en de combinaties die we beoordelen tijdens geplande audits. Dit is een ondersteuningsmatrix, en niet een bewering dat elke combinatie van browser en ondersteunende technologie zich identiek gedraagt.

Wanneer gebruikers een barrière melden bij een best-effort-combinatie, onderzoeken we dit nog steeds. Als het probleem van invloed is op de kernsemantiek, het toetsenbordgedrag of gedeelde componenten, beschouwen we dit als een productdefect, zelfs als de exacte koppeling niet in de primaire geverifieerde set voorkomt.

Beëindigings- en wijzigingsbeleid

• We stoppen niet opzettelijk de ondersteuning voor een geverifieerde combinatie van browser en ondersteunende technologie zonder de wijziging eerst op deze pagina te publiceren.
• Wanneer een geverifieerde combinatie onpraktisch wordt om te ondersteunen vanwege leveranciers-, platform- of beveiligingsbeperkingen, streven we ernaar ten minste één kwartaalaankondiging te doen voordat deze de status van beste inspanning krijgt.
• Elke beëindigingskennisgeving moet de betrokken combinatie vermelden, waarom deze is gewijzigd, de ingangsdatum en het dichtstbijzijnde ondersteunde alternatief.

Als een gerapporteerde barrière een combinatie beïnvloedt die we momenteel rechtstreeks verifiëren, wordt het probleem beoordeeld op basis van die ondersteuningsverwachting en niet als optioneel behandeld.

Toegankelijkheidsbeoordeling van afhankelijkheid van derden

De meeste gecontroleerde PayCal-interacties maken gebruik van eigen UI-code. Als er browsercode van derden bestaat, houden we de impact ervan op de toegankelijkheid afzonderlijk bij, zodat upgrades de verwachtingen op het gebied van toetsenbord, semantiek of CSP niet omzeilen.

• Goedgekeurd: toegestaan voor huidig gebruik, waarbij de impact op de toegankelijkheid wordt begrepen en gedocumenteerd.
• Voorwaardelijk: alleen toegestaan in een beperkte reikwijdte terwijl de evaluatie-, vervangings- of inperkingswerkzaamheden open blijven.
• Geblokkeerd: niet toegestaan voor nieuw gebruik van de gebruikersinterface totdat aan de toegankelijkheidsvereisten is voldaan.

Elke nieuwe afhankelijkheid aan de browserzijde die een gebruikersinterface, focusafhandeling, dialooggedrag, ingebedde media of aangepaste widgets toevoegt, moet vóór adoptie worden beoordeeld en opnieuw worden beoordeeld vóór grote versie-upgrades.

Wat is er nu aanwezig

• Kernnavigatie ondersteunt toetsenbordgebruik, links overslaan en gedocumenteerde sneltoetsen met één toets voor belangrijke bestemmingen.
• Sneltoetsen met één toets (C, R, S, E, A, H, N, P, ?) zijn gedocumenteerd voor de belangrijkste toepassingsroutes.
• Snelkoppelingen worden niet geactiveerd tijdens het typen van invoer of wanneer dialoogvensters geopend zijn.
• Hulp- en transparantieroutes bieden meer dan één manier om te navigeren, inclusief broodkruimels waar dat nuttige context toevoegt.
• Gecontroleerde routes maken gebruik van semantische oriëntatiepunten, duidelijke koppen, directe labels en statusberichten waarbij de interactie feedback nodig heeft.
• Contrast- en focustokencontroles zijn geautomatiseerd in de huidige themacatalogus, en de gepubliceerde matrix wordt bijgehouden in onze toegankelijkheidsachterstandworkflow.
• Instellingen omvatten een dyslexievriendelijke typografievoorkeur met toegankelijke spatiëring en ondersteuning voor fallback-stack.
• Toegankelijkheidsrapporten kunnen nu vanaf deze pagina beginnen en doorgaan naar de beveiligde contactstroom, waarbij de belangrijkste details vooraf zijn ingevuld.

Wij geven de voorkeur aan semantische HTML en gebruiken ARIA waar het helpt namen, relaties of live statusveranderingen duidelijker bloot te leggen.

Sneltoegangstoetsen

PayCal publiceert snelkoppelingen met één toets voor belangrijke bestemmingen, zodat frequente routes bereikbaar blijven zonder herhaaldelijke aanwijzerreizen. De huidige gedocumenteerde set omvat agenda, organisaties, instellingen, inkomsten, administratie, hulp, notities, betaalperioden en hulp bij sneltoetsen.

Deze snelkoppelingen maken alleen deel uit van het toegankelijkheidscontract als ze voorspelbaar, gedocumenteerd en veilig zijn om te negeren. Gebruikers kunnen blijven navigeren met standaardlinks, knoppen, links overslaan en oriëntatiepunten zonder afhankelijk te zijn van het onthouden van snelkoppelingen.

Focus op veiligheid

Focusveiligheidsregels voorkomen dat snelkoppelingshandlers en gescripte gebruikersinterface de focus stelen terwijl iemand in een modal typt of werkt. Snelkoppelingen worden niet geactiveerd binnen bewerkbare besturingselementen, en dialooginteracties houden de focus behouden totdat het dialoogvenster wordt gesloten.

Dit beleid vermindert onbedoelde navigatie, beschermt formulierinvoer en zorgt ervoor dat het toetsenbordgedrag consistent blijft met de regressiedekking op routeniveau die we uitvoeren in Playwright en Lightpanda.

Wat we actief verifiëren

• WCAG-scans op routeniveau worden uitgevoerd op kernpagina's, inclusief strikte routecontroles op overtredingen en strengere contrastcontroles.
• Kop- en formulierregressies worden gecontroleerd, zodat de oriëntatiepuntstructuur, labels en herstelberichten niet stilletjes verdwijnen.
• De reflow- en tekstafstanddekking controleert kernroutes bij compacte viewportbreedtes om problemen met horizontale overloop en spatiëring op te vangen.
• Navigatiepad- en snelkoppelingsregressietests verifiëren broodkruimels, alternatieve paden, overdracht van feedback, veiligheidsgedrag van snelkoppelingen en de dekking van het beleid voor sneltoetsen.
• Controles op suiteniveau combineren de dekking van Playwright, PHPUnit en browsermatrix, zodat claims op het gebied van toegankelijkheid getest blijven.

Dit betekent dat onze verklaringen over openbare toegankelijkheid verband houden met de daadwerkelijke regressiedekking, en niet alleen met de bedoeling.

Recente verbeteringen

• 23-03-2026: 30+ ontwerptokens toegepast voor statusbalken, verificatiebanners, afteltimers en componenten voor de afstand tussen formulieren en dialoogvensters, waarbij alle directe kleurkoppelingen uit gedeelde stijlen zijn verwijderd en de contrastmatrix is uitgebreid om de nieuwe tokenparen te dekken (WCAG-020).
• 23-03-2026: Metagegevens voor verificatie toegevoegd (datum laatst geverifieerd, datum volgende beoordeling, bereik en bekende beperkingen) aan alle vier actieve subpagina's voor transparantie: toegankelijkheid, statistieken, belastingen en verificatiebeheer (WCAG-021).
• 23-03-2026: 31 fout- en statusreeksen vereenvoudigd voor authenticatie-, agenda- en organisatiestromen: technisch jargon (nonce-referenties) verwijderd, veldlege berichten actiegericht gemaakt en organisatiefoutmeldingen gestandaardiseerd naar een consistente 'Kan niet X. Probeer het opnieuw.' patroon (WCAG-024).
• 23-03-2026: Gepubliceerde toegankelijkheidsstandaarden op componentniveau met betrekking tot dialoogvensters, tabbladen, datagrids en formulieren met toetsenbord/ARIA-contracten en voorbeelden van wel/niet doen; gecrosslinkt vanuit PR-sjabloon en regressieworkflow (WCAG-025).
• 23-03-2026: Asserieve foutaankondigingen gescheiden van beleefde voortgangsaankondigingen op /auth/ en /settings/ om dubbele live-regio-uitvoer te verwijderen (WCAG-017).
• 23-03-2026: Gepubliceerde SLA-tabel met toegankelijkheidsdefecten met bevestigingsvensters, fixdoelen, eigenaren en escalatiepaden (WCAG-019).
• 23-03-2026: Publiceerde een formele checklist voor het resterende werk en een driemaandelijks controleboekje voor de toegankelijkheid met eigenaren, routedekking en bewijsvereisten.
• 23-03-2026: Een feedbackpad voor toegankelijkheid vanaf deze pagina toegevoegd aan het beveiligde contactformulier.
• 23-03-2026: Broodkruimels en regressiedekking toegevoegd voor meerdere navigatiepaden op belangrijke openbare routes.
• 23-03-2026: Strenge contrastblokkers op belangrijke openbare routes opgelost en deze controles in de WCAG-routesuite gehandhaafd.
• 23-03-2026: Dyslexievriendelijke typografievoorkeursdekking toegevoegd in de instellingen, met toegankelijk lettertypestapel- en spatiëringsgedrag.
• 22-03-2026: Vernieuwing op routeniveau en tekstafstanddekking toegevoegd voor kernpagina's met compacte viewportbreedtes.
• 20-03-2026: Gedocumenteerde snelkoppelingen in applicatiestijl toegevoegd met beveiliging, zodat ze niet worden geactiveerd tijdens het typen of terwijl dialoogvensters geopend zijn.
• 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.

Wat we nog steeds verbeteren

• Pakket voor externe auditgereedheid: probleemgeschiedenis, herstellogboeken en beleidsbewijs vooraf inpakken, zodat binnen één werkdag een compleet auditpakket kan worden geproduceerd (WCAG-026).

Huidig open werk

• WCAG-026: Pakket voor externe auditgereedheid: probleemgeschiedenis, herstellogboeken, bewijsartefacten en beleidsdocumenten vooraf inpakken, zodat binnen één werkdag een pakket met auditbewijsmateriaal kan worden geproduceerd.

Dit is het actieve item in onze WCAG-uitvoeringsachterstand. Ontwerptokens, metadata voor transparantie, live-regiocontracten, PR-beheer en kopieerwerk in gewone taal zijn voltooid en worden gedekt door regressiesuites om het risico op terugval te verminderen.

Toegankelijkheid Foutreactie Windows

Elk geverifieerd toegankelijkheidsdefect wordt bij de creatie geregistreerd met een ernst, eigenaar, WCAG-criterium en vervaldatum, zodat het werk operationeel blijft in plaats van informeel.

Hoe wij ARIA gebruiken

We beschouwen ARIA niet als vervanging voor semantische HTML. We gebruiken ARIA om besturingsnamen, relaties, beschrijvingen en statuswijzigingen te verduidelijken wanneer native HTML alleen niet voldoende is.

Dat betekent dat ons toegankelijkheidswerk breder is dan alleen het gebruik van ARIA. Toetsenbordgedrag, koppen, focusbehandeling, contrast, reflow en foutherstel zijn net zo belangrijk.

Normen en richtlijnen

Ons toegankelijkheidswerk wordt voornamelijk geleid door WCAG 2.1 en gerelateerde wettelijke normen die verwijzen naar de verwachtingen van niveau AA.

• WCAG 2.1 (W3C Web Content Accessibility Guidelines) — Internationale standaard voor webtoegankelijkheid
• Sectie 508 (Amerikaanse federale wet) — Komt overeen met WCAG 2.0 niveau AA
• EN 301 549 (Europese norm) — Komt overeen met WCAG 2.1 niveau AA
• AODA (Accessibility for Ontarios with Disabilities Act) — Verwijzingen naar WCAG-gerichte toegankelijkheidsverwachtingen in Canada