Trasparenza dell'accessibilità

Il nostro standard di lavoro

Utilizziamo WCAG 2.1 Livello AA come standard di lavoro per l'accessibilità dei prodotti. Adottiamo anche idee AAA selezionate quando migliorano chiaramente l'usabilità, ma non rivendichiamo la conformità AAA.

Non pretendiamo che ogni percorso sia perfetto in ogni momento. Ci impegniamo a correggere le barriere verificate, a documentare le modifiche e a mantenere il lavoro sull'accessibilità nel normale flusso di lavoro tecnico.

Politica di supporto delle tecnologie assistive

Pubblichiamo le aspettative di supporto in base alle combinazioni che verifichiamo direttamente e alle combinazioni che esaminiamo durante gli audit programmati. Questa è una matrice di supporto, non un'affermazione secondo cui ogni associazione di browser e tecnologia assistiva si comporta in modo identico.

Quando gli utenti segnalano un ostacolo su una combinazione di massimo sforzo, continuiamo a indagare sulla questione. Se il problema riguarda la semantica principale, il comportamento della tastiera o i componenti condivisi, lo consideriamo un difetto del prodotto anche quando l'abbinamento esatto non è presente nel set primario verificato.

Politica di deprecazione e modifica

• Non interrompiamo intenzionalmente il supporto per una combinazione verificata di browser e tecnologia assistiva senza prima pubblicare la modifica su questa pagina.
• Quando una combinazione verificata diventa impraticabile da supportare a causa di vincoli di fornitore, piattaforma o sicurezza, riceviamo almeno un avviso con ciclo trimestrale prima che passi allo stato di massimo sforzo.
• Qualsiasi avviso di deprecazione deve includere la combinazione interessata, il motivo della modifica, la data di entrata in vigore e l'alternativa supportata più vicina.

Se una barriera segnalata influisce su una combinazione che attualmente verifichiamo direttamente, il problema viene valutato in base alle aspettative di supporto e non trattato come facoltativo.

Revisione dell'accessibilità delle dipendenze di terze parti

La maggior parte delle interazioni PayCal controllate utilizzano il codice dell'interfaccia utente di prima parte. Laddove esiste codice lato browser di terze parti, ne monitoriamo l'impatto sull'accessibilità separatamente in modo che gli aggiornamenti non ignorino la tastiera, la semantica o le aspettative CSP.

• Approvato: consentito per l'uso corrente, con l'impatto sull'accessibilità compreso e documentato.
• Condizionale: consentito solo in un ambito limitato mentre il lavoro di revisione, sostituzione o contenimento rimane aperto.
• Bloccato: non consentito per il nuovo utilizzo dell'interfaccia utente finché non vengono soddisfatti i requisiti di accessibilità.

Qualsiasi nuova dipendenza lato browser che aggiunge interfaccia utente, gestione del focus, comportamento dei dialoghi, contenuti multimediali incorporati o widget personalizzati deve essere rivista prima dell'adozione e riesaminata prima degli aggiornamenti principali della versione.

Cosa c'è adesso

• La navigazione principale supporta l'uso della tastiera, i collegamenti per saltare e le scorciatoie a tasto singolo documentate per le principali destinazioni.
• Le scorciatoie a tasto singolo (C, R, S, E, A, H, N, P, ?) sono documentate per i principali percorsi applicativi.
• Le scorciatoie non si attivano durante la digitazione di input o quando le finestre di dialogo sono aperte.
• I percorsi di aiuto e trasparenza forniscono più di un modo per navigare, inclusi i breadcrumb laddove ciò aggiunge un contesto utile.
• I percorsi controllati utilizzano punti di riferimento semantici, titoli chiari, etichette dirette e messaggi di stato laddove l'interazione necessita di feedback.
• I controlli dei token di contrasto e messa a fuoco sono automatizzati nel catalogo dei temi corrente e la matrice pubblicata viene tracciata nel nostro flusso di lavoro del backlog di accessibilità.
• Le impostazioni includono una preferenza tipografica adatta alla dislessia con spaziatura accessibile e supporto dello stack di fallback.
• I report sull'accessibilità possono ora iniziare da questa pagina e continuare nel flusso di contatti sicuri con i dettagli chiave precompilati.

Preferiamo prima l'HTML semantico e utilizziamo ARIA dove aiuta a esporre più chiaramente nomi, relazioni o modifiche allo stato in tempo reale.

Tasti di accesso rapido

PayCal pubblica scorciatoie a tasto singolo per le principali destinazioni in modo che i percorsi frequenti rimangano raggiungibili senza spostamenti ripetitivi del puntatore. L'attuale set documentato copre calendario, organizzazioni, impostazioni, guadagni, amministrazione, guida, note, periodi di pagamento e guida per le scorciatoie da tastiera.

Queste scorciatoie fanno parte del contratto di accessibilità solo quando sono prevedibili, documentate e si può ignorarle con sicurezza. Gli utenti possono continuare a navigare con collegamenti, pulsanti, collegamenti salta e punti di riferimento standard senza fare affidamento sulla memorizzazione dei collegamenti.

Focus sulla sicurezza

Le regole di sicurezza della messa a fuoco impediscono ai gestori di scorciatoie e all'interfaccia utente con script di rubare la messa a fuoco mentre qualcuno sta digitando o lavorando all'interno di una modale. Le scorciatoie non vengono attivate all'interno dei controlli modificabili e le interazioni della finestra di dialogo mantengono l'ambito attivo fino alla chiusura della finestra di dialogo.

Questa policy riduce la navigazione accidentale, protegge l'immissione di moduli e mantiene il comportamento della tastiera coerente con la copertura di regressione a livello di percorso che eseguiamo in Playwright e Lightpanda.

Cosa verifichiamo attivamente

• Le scansioni WCAG a livello di percorso vengono eseguite sulle pagine principali, inclusi controlli rigorosi del percorso per violazioni e controlli di contrasto più severi.
• Le regressioni di intestazioni e moduli vengono controllate in modo che la struttura dei punti di riferimento, le etichette e i messaggi di ripristino non si muovano silenziosamente.
• La copertura del riflusso e della spaziatura del testo controlla i percorsi principali con larghezze di visualizzazione compatte per individuare gli errori di overflow e spaziatura orizzontale.
• I test di regressione del percorso di navigazione e delle scorciatoie verificano i breadcrumb, i percorsi alternativi, il trasferimento del feedback, il comportamento di sicurezza delle scorciatoie e la copertura dei criteri delle scorciatoie da tastiera.
• I controlli a livello di suite combinano la copertura di Playwright, PHPUnit e della matrice del browser in modo che le dichiarazioni di accessibilità rimangano supportate dai test.

Ciò significa che le nostre dichiarazioni sull’accessibilità pubblica sono legate alla copertura effettiva della regressione, non solo alle intenzioni.

Miglioramenti recenti

• 23-03-2026: applicati oltre 30 token di progettazione per barre di stato, banner di verifica, timer per il conto alla rovescia e componenti di spaziatura di moduli/dialoghi, rimuovendo tutti gli accoppiamenti diretti di colore dagli stili condivisi ed estendendo la matrice di contrasto per coprire le nuove coppie di token (WCAG-020).
• 23-03-2026: aggiunti metadati di verifica (data dell'ultima verifica, data della prossima revisione, ambito e limitazioni note) a tutte e quattro le pagine secondarie di trasparenza attiva: accessibilità, metriche, tasse e governance della verifica (WCAG-021).
• 23-03-2026: semplificate 31 stringhe di errore e di stato nei flussi di autenticazione, calendario e organizzazioni: rimosso il gergo tecnico (riferimenti a nonce), resi utilizzabili i messaggi con campi vuoti e standardizzati i messaggi di errore dell'organizzazione in un coerente "Impossibile X. Riprova". modello (WCAG-024).
• 23-03-2026: pubblicati standard di accessibilità a livello di componente che coprono finestre di dialogo, schede, griglie dati e moduli con contratti tastiera/ARIA ed esempi di cosa fare/non fare; reticolato dal modello PR e dal flusso di lavoro di regressione (WCAG-025).
• 23-03-2026: annunci di errore assertivi separati dagli annunci di progresso educati su /auth/ e /settings/ per rimuovere l'output duplicato della regione live (WCAG-017).
• 23-03-2026: tabella SLA per difetti di accessibilità pubblicata con finestre di riconoscimento, destinazioni di correzione, proprietari e percorsi di escalation (WCAG-019).
• 23-03-2026: pubblicato un elenco di controllo formale del lavoro rimanente e un manuale di audit trimestrale sull'accessibilità con proprietari, copertura del percorso e requisiti di prova.
• 23-03-2026: aggiunto un percorso di acquisizione del feedback sull'accessibilità da questa pagina al modulo di contatto sicuro.
• 23-03-2026: Aggiunti breadcrumb e copertura di regressione per più percorsi di navigazione sui principali percorsi pubblici.
• 23-03-2026: risolti severi blocchi di contrasto sui percorsi pubblici principali e mantenuti tali controlli nella suite di percorsi WCAG.
• 23-03-2026: Aggiunta la copertura delle preferenze tipografiche adatte alla dislessia nelle impostazioni, con stack di caratteri e comportamento di spaziatura accessibili.
• 22-03-2026: Aggiunta la ridisposizione a livello di percorso e la copertura della spaziatura del testo per le pagine principali con larghezze di visualizzazione compatte.
• 20-03-2026: Aggiunti collegamenti documentati in stile applicazione con protezioni in modo che non si attivino durante la digitazione o mentre le finestre di dialogo sono aperte.
• 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.

Cosa stiamo ancora migliorando

• Pacchetto di preparazione all'audit esterno: cronologia dei problemi preconfezionati, registri di risoluzione e prove politiche in modo che sia possibile produrre un pacchetto di audit completo entro un giorno lavorativo (WCAG-026).

Lavori aperti attuali

• WCAG-026: Pacchetto di preparazione all'audit esterno: cronologia dei problemi preconfezionata, registri di correzione, elementi di prova e documenti sulle politiche in modo che un pacchetto di prove di audit possa essere prodotto entro un giorno lavorativo.

Questo è l'elemento attivo nel nostro backlog di esecuzione WCAG. I token di progettazione, i metadati di trasparenza, i contratti regionali, la governance delle PR e il lavoro di copia in linguaggio semplice sono stati completati e sono coperti da suite di regressione per ridurre il rischio di arretramento.

Finestre di risposta ai difetti di accessibilità

Ogni difetto di accessibilità verificato viene archiviato con gravità, proprietario, criterio WCAG e data di scadenza al momento della creazione, in modo che il lavoro rimanga operativo anziché informale.

Come utilizziamo ARIA

Non trattiamo ARIA come un sostituto dell'HTML semantico. Utilizziamo ARIA per chiarire nomi di controllo, relazioni, descrizioni e modifiche di stato quando il solo HTML nativo non è sufficiente.

Ciò significa che il nostro lavoro sull’accessibilità va oltre il solo utilizzo di ARIA. Il comportamento della tastiera, le intestazioni, la gestione della messa a fuoco, il contrasto, il riflusso e il ripristino degli errori sono altrettanto importanti.

Standard e linee guida

Il nostro lavoro sull'accessibilità è guidato principalmente dalle WCAG 2.1 e dai relativi standard legali che fanno riferimento alle aspettative del Livello AA.

• WCAG 2.1 (Linee guida per l'accessibilità dei contenuti Web del W3C): standard internazionale per l'accessibilità del web
• Sezione 508 (legge federale degli Stati Uniti): in linea con le WCAG 2.0 Livello AA
• EN 301 549 (standard europeo) — In linea con WCAG 2.1 Livello AA
• AODA (Accessibility for Ontarioians with Disabilities Act): fa riferimento alle aspettative di accessibilità allineate alle WCAG in Canada