Transparence en matière d'accessibilité

Notre norme de travail

Nous utilisons les WCAG 2.1 niveau AA comme norme de travail pour l'accessibilité des produits. Nous adoptons également certaines idées AAA lorsqu'elles améliorent clairement la convivialité, mais nous ne revendiquons pas la conformité AAA.

Nous ne prétendons pas que chaque itinéraire soit parfait à tout moment. Nous nous engageons à éliminer les obstacles vérifiés, à documenter les modifications et à maintenir le travail d'accessibilité dans le flux de travail d'ingénierie normal.

Politique de soutien aux technologies d’assistance

Nous publions les attentes de support en fonction des combinaisons que nous vérifions directement et des combinaisons que nous examinons lors des audits programmés. Il s’agit d’une matrice de support, et non d’une affirmation selon laquelle chaque combinaison de navigateur et de technologie d’assistance se comporte de manière identique.

Lorsque les utilisateurs signalent un obstacle sur une combinaison au mieux, nous l’enquêtons toujours. Si le problème affecte la sémantique principale, le comportement du clavier ou les composants partagés, nous le traitons comme un défaut du produit, même si l'association exacte ne figure pas dans l'ensemble principal vérifié.

Politique de dépréciation et de modification

• Nous n'abandonnons pas intentionnellement la prise en charge d'une combinaison de navigateur vérifié et de technologie d'assistance sans publier au préalable la modification sur cette page.
• Lorsqu'une combinaison vérifiée devient impossible à prendre en charge en raison de contraintes liées au fournisseur, à la plate-forme ou à la sécurité, nous ciblons au moins un avis trimestriel avant qu'elle ne passe au statut de meilleur effort.
• Tout avis de dépréciation doit inclure la combinaison concernée, la raison pour laquelle elle a changé, la date d'entrée en vigueur et l'alternative prise en charge la plus proche.

Si un obstacle signalé affecte une combinaison que nous vérifions actuellement directement, le problème est trié par rapport à cette attente de support et n'est pas traité comme facultatif.

Examen de l'accessibilité des dépendances tierces

La plupart des interactions PayCal auditées utilisent le code d'interface utilisateur propriétaire. Lorsqu'il existe du code côté navigateur tiers, nous suivons séparément son impact sur l'accessibilité afin que les mises à niveau ne contournent pas les attentes en matière de clavier, de sémantique ou de CSP.

• Approuvé: autorisé pour une utilisation actuelle, avec un impact sur l’accessibilité compris et documenté.
• Conditionnel: autorisé uniquement dans une portée limitée pendant que les travaux de révision, de remplacement ou de confinement restent ouverts.
• Bloqué: aucune nouvelle utilisation de l’interface utilisateur n’est autorisée tant que les exigences d’accessibilité ne sont pas remplies.

Toute nouvelle dépendance côté navigateur qui ajoute une interface utilisateur, une gestion du focus, un comportement de dialogue, des médias intégrés ou des widgets personnalisés doit être examinée avant son adoption et réexaminée avant les mises à niveau majeures de la version.

Ce qui est en place maintenant

• La navigation principale prend en charge l'utilisation du clavier, les liens de saut et les raccourcis documentés à une seule touche pour les principales destinations.
• Des raccourcis à une seule touche (C, R, S, E, A, H, N, P, ?) sont documentés pour les principales routes d'application.
• Les raccourcis ne se déclenchent pas lors de la saisie d'entrées ou lorsque des boîtes de dialogue sont ouvertes.
• Les itinéraires d'aide et de transparence offrent plusieurs façons de naviguer, y compris le fil d'Ariane où cela ajoute un contexte utile.
• Les itinéraires audités utilisent des repères sémantiques, des titres clairs, des étiquettes directes et des messages d'état lorsque l'interaction nécessite un retour.
• Les vérifications des jetons de contraste et de focus sont automatisées dans le catalogue de thèmes actuel, et la matrice publiée est suivie dans notre workflow de backlog d'accessibilité.
• Les paramètres incluent une préférence typographique adaptée à la dyslexie avec un espacement accessible et une prise en charge de la pile de secours.
• Les rapports d'accessibilité peuvent désormais démarrer à partir de cette page et continuer dans le flux de contacts sécurisé avec les détails clés pré-remplis.

Nous préférons d'abord le HTML sémantique et utilisons ARIA où il permet d'exposer plus clairement les noms, les relations ou les changements de statut en direct.

Touches d'accès rapide

PayCal publie des raccourcis à une seule touche pour les principales destinations afin que les itinéraires fréquents restent accessibles sans déplacements répétitifs du pointeur. L'ensemble documenté actuel couvre le calendrier, les organisations, les paramètres, les revenus, l'administration, l'aide, les notes, les périodes de paie et l'aide sur les raccourcis clavier.

Ces raccourcis ne font partie du contrat d’accessibilité que lorsqu’ils sont prévisibles, documentés et peuvent être ignorés en toute sécurité. Les utilisateurs peuvent continuer à naviguer avec des liens, des boutons, des liens de saut et des points de repère standard sans compter sur la mémorisation de raccourcis.

Concentrez-vous sur la sécurité

Les règles de sécurité du focus empêchent les gestionnaires de raccourcis et l'interface utilisateur scriptée de voler le focus pendant que quelqu'un tape ou travaille dans un modal. Les raccourcis ne se déclenchent pas à l’intérieur des contrôles modifiables et les interactions de boîte de dialogue conservent le focus jusqu’à la fermeture de la boîte de dialogue.

Cette politique réduit la navigation accidentelle, protège la saisie du formulaire et maintient le comportement du clavier cohérent avec la couverture de régression au niveau de l'itinéraire que nous exécutons dans Playwright et Lightpanda.

Ce que nous vérifions activement

• Les analyses WCAG au niveau de l'itinéraire s'exécutent sur les pages principales, y compris des analyses d'itinéraire strictes pour les violations et des contrôles de contraste plus stricts.
• Les régressions de titres et de formulaires sont vérifiées afin que la structure des points de repère, les étiquettes et les messages de récupération ne dérivent pas silencieusement.
• La couverture de redistribution et d'espacement du texte vérifie les itinéraires principaux dans des largeurs de fenêtre compactes pour détecter les débordements horizontaux et les échecs d'espacement.
• Les tests de régression des chemins de navigation et des raccourcis vérifient le fil d'Ariane, les chemins alternatifs, le transfert de commentaires, le comportement de sécurité des raccourcis et la couverture des politiques de raccourcis clavier.
• Les vérifications au niveau de la suite combinent la couverture de Playwright, PHPUnit et de la matrice du navigateur afin que les allégations d'accessibilité restent étayées par des tests.

Cela signifie que nos déclarations d'accessibilité publique sont liées à la couverture réelle de la régression, et pas seulement à l'intention.

Améliorations récentes

• 2026-03-23 : Application de plus de 30 jetons de conception pour les barres d'état, les bannières de vérification, les comptes à rebours et les composants d'espacement des formulaires/dialogues, supprimant tout couplage direct de couleurs des styles partagés et étendant la matrice de contraste pour couvrir les nouvelles paires de jetons (WCAG-020).
• 2026-03-23 : Ajout de métadonnées de vérification (date de la dernière vérification, date du prochain examen, portée et limitations connues) aux quatre sous-pages de transparence actives : accessibilité, statistiques, taxes et vérification-gouvernance (WCAG-021).
• 2026-03-23 : Simplification de 31 chaînes d'erreur et d'état dans les flux d'authentification, d'agenda et d'organisation : suppression du jargon technique (références occasionnelles), rendu des messages vides de champ exploitables et messages d'erreur d'organisation standardisés pour un "Impossible X. Veuillez réessayer" cohérent. modèle (WCAG-024).
• 2026-03-23 : Publication de normes d'accessibilité au niveau des composants couvrant les boîtes de dialogue, les onglets, les grilles de données et les formulaires avec des contrats clavier/ARIA et des exemples de choses à faire/à ne pas faire ; réticulé à partir du modèle PR et du workflow de régression (WCAG-025).
• 2026-03-23 : Séparation des annonces d'erreur assertives des annonces de progression polies sur /auth/ et /settings/ pour supprimer les sorties de région active en double (WCAG-017).
• 23/03/2026 : Publication du tableau SLA des défauts d'accessibilité avec les fenêtres d'accusé de réception, les cibles de correction, les propriétaires et les chemins d'escalade (WCAG-019).
• 2026-03-23 : Publication d'une liste de contrôle formelle des travaux restants et d'un manuel d'audit d'accessibilité trimestriel avec les propriétaires, la couverture des itinéraires et les exigences en matière de preuves.
• 2026-03-23 : Ajout d'un chemin de réception des commentaires sur l'accessibilité à partir de cette page dans le formulaire de contact sécurisé.
• 2026-03-23 : Ajout du fil d'Ariane et de la couverture de régression pour plusieurs chemins de navigation sur les principaux itinéraires publics.
• 2026-03-23 : Résolution des bloqueurs de contraste stricts sur les principales routes publiques et maintien de ces contrôles dans la suite de routes WCAG.
• 23/03/2026 : Ajout d'une couverture des préférences typographiques adaptées à la dyslexie dans les paramètres, avec une pile de polices et un comportement d'espacement accessibles.
• 2026-03-22 : Ajout de la redistribution au niveau de l'itinéraire et de la couverture de l'espacement du texte pour les pages principales avec des largeurs de fenêtre compactes.
• 20/03/2026 : Ajout de raccourcis documentés de style application avec protections afin qu'ils ne se déclenchent pas lors de la saisie ou lorsque les boîtes de dialogue sont ouvertes.
• 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.

Ce que nous améliorons encore

• Package de préparation à l'audit externe : historique des problèmes de pré-packaging, journaux de correction et preuves de politique afin qu'un package d'audit complet puisse être produit en un jour ouvrable (WCAG-026).

Travail ouvert actuel

• WCAG-026: Package de préparation à l'audit externe : pré-packaging de l'historique des problèmes, des journaux de remédiation, des artefacts de preuves et des documents de politique afin qu'un package de preuves d'audit puisse être produit en un jour ouvrable.

Il s’agit de l’élément actif de notre backlog d’exécution WCAG. Les jetons de conception, les métadonnées de transparence, les contrats de région en direct, la gouvernance des relations publiques et le travail de copie en langage simple ont été achevés et sont couverts par des suites de régression pour réduire le risque de retour en arrière.

Fenêtres de réponse aux défauts d’accessibilité

Chaque défaut d'accessibilité vérifié est classé avec une gravité, un propriétaire, un critère WCAG et une date d'échéance au moment de la création afin que le travail reste opérationnel plutôt qu'informel.

Comment nous utilisons ARIA

Nous ne considérons pas ARIA comme un remplacement du HTML sémantique. Nous utilisons ARIA pour clarifier les noms de contrôle, les relations, les descriptions et les changements de statut lorsque le HTML natif seul ne suffit pas.

Cela signifie que notre travail en matière d’accessibilité va au-delà de la seule utilisation d’ARIA. Le comportement du clavier, les titres, la gestion de la mise au point, le contraste, la redistribution et la récupération des erreurs sont tout aussi importants.

Normes et lignes directrices

Notre travail en matière d'accessibilité est principalement guidé par les WCAG 2.1 et les normes juridiques associées qui font référence aux attentes de niveau AA.

• WCAG 2.1 (W3C Web Content Accessibility Directives) – Norme internationale pour l'accessibilité du Web
• Section 508 (loi fédérale des États-Unis) – Conforme aux WCAG 2.0 niveau AA
• EN 301 549 (norme européenne) — Conforme aux WCAG 2.1 niveau AA
• AODA (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) — Références aux attentes en matière d'accessibilité alignées sur les WCAG au Canada