Test di disponibilità interfaccia

1) Perché e cosa riteniamo «pronto»

• sono stati soddisfatti i criteri WCAG 2. 1/2. 2 livelli AA per le piattaforme di destinazione
• interfaccia completamente passata dalla tastiera
• Operazioni corrette con gli schermati
• contrasti conformi alle norme
• Tutti gli stati/errori/stati sono disponibili fuori vista e senza mouse;
• presa in considerazione localizzazione, RTL, reduce motion e caratteristiche mobili.

2) Strategia di test (piramide A11y)

1. Auto/Linter (copertura rapida fino al 40-60% delle classi di problemi).
2. Controllo manuale dei pattern (tastiera, focus, contenuti, logica).
3. Assistive Tech (AT) sessioni - Schermate, scalabilità, filtri di colore.
4. Test sul campo con gli utenti (se possibile).

L'obiettivo è catturare i difetti di sistema a livello di componenti/pattern, in modo che non si riproducano in fiocchi.

3) Assegno-lista controlli base (test rapido)

• Tastiera: tutto è raggiungibile con tabula/freccia; L'ordine di fuoco è logico. la trappola del trucco nei modali c'è; ESC/Enter/Space sono in esecuzione.
• L'indicatore attivo è visibile in qualsiasi argomento/sfondo.
• Contrasto: testo ≥ 4. 5:1 (normale), 3:1 (grande), icone/controlli sono leggibili.
• Semantica: tag corretti («button», «a», «label», «ul/li», «th/td»), ruoli e «aria-» solo se necessario.
• Screener - Intestazioni gerarchiche, nomi significativi di pulsanti/riferimenti, alternative per icone/immagini.
• Moduli: chiari «label», suggerimenti/errori sono associati ('aria-describedby'), i testi degli errori sono specifici.
• Altoparlanti: toast/banner/errori vengono dichiarati attraverso «aria-live» («polite »/« assistenziale»).
• Le animazioni rispettano'preferers-reduced-motion '; senza «tremare» l'interfaccia.
• Localizzazione/RTL: le schermate chiave sono allineate, i numeri/date/valute vengono formattati dagli strumenti.
• Mobilità: obiettivi di tocco 44 x 44 px, zoom non vietato, ruotare lo schermo non rompe i contenuti.

4) Ruoli, responsabilità e manufatti

Sistema di progettazione: requisiti A11y nella descrizione di ciascun componente.
Sviluppatori: automezzi, test unit/interaction con asserti A11y.
QA: script manuali + sessioni AT rapporto serio/frequente.
UX/Content: microcopy errori/stati, leggibilità ad alta voce.
Artefatti: assegni, script, screening AT, elenco dei difetti con WCAG, raccomandazioni.

5) Controlli automatizzati

Linter/analizzatori: axe, slint-plugin-jsx-a11y, pa11y, Lighthouse.
In Pipline: blocchiamo il PR in caso di violazioni critiche (rolle/label/contrasto/agguati).
Snapshot contrasto - Test visivi di argomenti/condizioni.

6) Test manuali: script

6. 1 Tastiera

Passate la pagina solo con la tastiera (Tav/Maiusc + Tav/Enter/Space/Frecce).
Verificare la visibilità, la priorità, la disponibilità di tutte le azioni, l'assenza di trappole e elementi morti.
In Modalk, attiva all'interno e torna all'iniziatore al momento della chiusura.

6. 2 Schermate (set minimo)

Desktop: NVDA/JAWS (Windows), VoiceOver (macOS).
Mobile: VoiceOver (iOS), TalkBack (Android).
Controlla le intestazioni corrette (gerarchia H), i nomi dei pulsanti/link, la lettura delle tabelle ('th '/' scope'), la dichiarazione degli stati, gli errori chiari dei moduli.

6. 3 Contenuti e microcopy

Leggiamo testi critici ad alta voce, senza ambiguità, senza «errore 400».
Errore = «cosa non è + come correggere + vincolo/formato».

6. 4 Dinamiche e regioni viventi

Il brindisi del successo è "aria-live =" polite ", l'errore è" assistenziale ".
I progressi e i download sono spiegati dal testo; lo skeleton è preferito allo spinner.

7) Moduli e errori (approfonditi)

Ogni campo ha un label collegato (non placeholder).
Gli errori sono associati al campo "aria-invalid =" true "," aria-describedy = "[id errori]" ".
Le formule dei formati (data, telefono) sono indicate in anticipo; le maschere non rompono l'input/incolla.
Striscione di riepilogo degli errori submit + scroll automatico e fuoco sul primo errore.
I testi degli errori sono specifici, senza gergo tecnico.

8) Tabelle, elenchi, grafici

Le tabelle sono intestazioni «th» con scope = «col/row», firme, curriculum.
Le liste sono reali «ul/ol/li», non divi.
Grafici: tabelle/descrizioni alternative; Le leggende sono disponibili I colori sono l'unico segnale.

9) Multimedia e animazioni

Video: sottotitoli/trascrizione; Controllo dalla tastiera senza autolavaggio (o silenzioso).
GIF/microanimazione: disattivare con «prefers-reduced-motion»; Evitate i flash.
Vibrazioni/suoni sono opzionali e duplicati visivamente/con testo.

10) Disponibilità mobile

Interazioni ≥ 44 x 44 px, intervalli sufficienti.
Non è possibile ridimensionare (meta viewport senza «user-scalable = no»).
Forma/tastiera: i tipi corretti («tel», «email», «number») non nascondono le funzionalità di sistema.
Controlla il tema oscuro e i caratteri di sistema «più grandi».

11) Localizzazione, numeri e RTL

Stringhe tramite chiavi i18n con contesto; le lingue lunghe (DE/TR) non rompono il layout.
I formati data/valuta sono strumenti, non righe.
Modalità RTL: mirroring delle icone di navigazione, controllo dell'ordine di fuoco e carrozza, input bidirezionale.

12) Specificità dei flow critici (iGaming)

Pagamenti/conclusioni

Istruzioni chiare, limiti/tempi/commissione - testo.
Gli errori del provider vengono dichiarati esplicitamente, senza codici; c'è un'alternativa all'azione.
Conferma operazione: attiva su CTA logico, possibilità di annullamento.

CUS/convalida

Suggerimenti dettagliati su foto/documenti; il progresso e l'ETA.
Gli errori «offuscato/riflesso/ritagliato» sono esempi di correzione.
Tono neutrale, niente umorismo.

13) Valutazione della gravità dei difetti

Blocker: impossibile completare l'attività chiave (tastiera/schermata).
Critical - Funzioni critiche funzionano, ma con seri ostacoli.
Maggiore è un ostacolo, c'è una via di fuga.
Minor - Trucco/non corrispondenza di hyde senza influire sull'attività.

Ogni difetto è un riferimento al criterio WCAG e allo script riprodotto.

14) Criteri di accettazione (Definition of Done, A11y)

Lo script di tastiera senza mouse passa al 100%.
axe/Lighthouse: nessun disturbo critico/elevato.
Contrasto AA in tutti i temi/stati.
Screener-test dei percorsi chiave (navbar, moduli, moduli, toast).
Documentazione A11y per i nuovi componenti/fic (modello di ruolo, aria, fuoco, esempi).
La regressione dei test A11y è verde in CI.

15) Processi e automazione

Prima di sviluppare: criteri A11y nelle attività, layout con stati di focus/errore.
In progettazione: linter/ahe durante l'assemblaggio locale; snapshot visivi dei contrasti/focolai.
In CI: pa11y/axe-scan per pagine critiche; la caduta del biglietto di Blocker/Critical.
Dopo la release: verifiche trimestrali, monitoraggio delle denunce utente tramite il tag A11y.

16) Anti-pattern

Playsholder invece di label.
al posto di button/a.
Anelli «per la bellezza» disattivati.
Il colore è l'unico supporto di stato.
Modalka senza focus trap/ESC.
Non si può scalare sul mobile.
«Errore 400/500» senza spiegazione umana.

17) Modelli di script di test

Script 1 - Navigazione tastiera (pagina modulo)

1. Tag al primo campo, immettere i dati.
2. Maiusc + Taib indietro - Verificare l'ordine corretto.
3. Richiama convalida (sottomit) - L'attivazione viene spostata al primo errore.
4. Chiudete la modalina con il tasto ESC e il trucco è tornato all'iniziatore.

Script 2 - Screener (pagina di pagamento)

1. Passare all'intestazione della pagina (h1) e ascoltare le sezioni.
2. Aprite la selezione del metodo - Si sente la dichiarazione dei ruoli/stati.
3. Commettere deliberatamente un errore di importo - il messaggio è stato letto e collegato al campo.
4. Un brindisi di successo sul pagamento è stato dichiarato «polite».

Script 3 - Altoparlanti

1. Avvia l'operazione in attesa> 3 c - c'è il testo relativo al processo/ETA.
2. In caso di errore di rete, il banner «assistenziale» è disponibile dalla tastiera e c'è il percorso «ripeti/aiuto».

18) Micro modelli utili

Ruoli/aria per brindisi

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

Collega un errore a un campo

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Modalka (attributi di significato)

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19) Piano rapido per l'implementazione delle pratiche A11y

1. Controllo dei componenti/pattern correnti (contrasto/fuoco/semantica di ruolo).
2. Modifica del sistema di progettazione - Aggiunge una sezione A11y a ogni componente.
3. Gli strumenti sono personalizzare i linter/axe/pa11y/Lighthouse in locale e CI.
4. Formazione: scorciatoie per designer/sviluppatori/copiatori.
5. Pilota: riparare i 3-5 difetti più frequenti (moduli, moduli, toast).
6. Regolamento: DoD con criteri A11y; Un controllo trimestrale.

Scorciatoia finale

Controlla tastiera, trucco, contrasti, schermata, dinamica.
Dichiara gli stati attraverso aria-live; errori - associati ai campi.
Rispetto reduce motion, non vietare il ridimensionamento.
Pensa alla semantica (tag/ruoli) invece di «come appare».
Automatizza i controlli, ma aggiungi sempre quelli manuali.
Registra i difetti con riferimento a WCAG, serietà e script di riproduzione.