di A11yGuard (LX AI)

Checklist WCAG 2.2 per UI generati da AI

Le interfacce utente generate da LLM falliscono l'accessibilità in modi prevedibili: testo alternativo mancante, div utilizzati come pulsanti, controlli non etichettati e stati di focus che scompaiono sotto header sticky. La WCAG 2.2 ha aggiunto criteri di successo che colpiscono questi problemi di interfacce generate. Eseguire un primo passaggio automatizzato, quindi verificare la checklist manualmente prima di pubblicare.

Cosa WCAG 2.2 ha cambiato per l'interfaccia utente generata

WCAG 2.2 si basa su 2.1 e aggiunge nove criteri di successo rivolti alle esigenze mobili, di bassa visione e di mobilità. È diventato una Raccomandazione W3C nel mese di ottobre 2023; mantieni il testo normativo aperto mentre esegui l'audit (w3.org/TR/WCAG22). Per i team che consegnano componenti generati da AI, le aggiunte che contano di più sono Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) e Accessible Authentication (3.3.8). La maggior parte delle organizzazioni di prodotto si concentra sul livello AA. Le pagine fondamentali di WAI continuano a spiegare perché queste regole esistono oltre al "superare lo scanner" (WAI Accessibility Fundamentals).

I generatori falliscono qui perché ottimizzano per la densità visiva e la pulizia della demo di clic. Riducono le aree di hit degli icona, inventano bacheche kanban solo trascinabili, impilano chrome appiccicoso che copre i campi focalizzati e spargono ruoli ARIA che non corrispondono al comportamento. La checklist seguente è ordinata per un passaggio del giorno di rilascio: elementi misurabili per primi, elementi di giudizio per secondi.

Flusso di lavoro passo dopo passo prima di consegnare

- Congela il ramo generato. Non continuare a rigenerare mentre misuri. - Esegui uno scan di accessibilità automatizzato (axe, Lighthouse o il tuo gate CI) e archivia ogni hit di contrasto / nome mancante / ARIA non valido. - Passa i filtri di riferimento rapido WCAG 2.2 per il livello AA e marca i criteri esclusivi 2.2 come righe esplicite nel tuo biglietto. - Passaggio solo con tastiera su ogni percorso utente primario (iscrizione, pagamento, attività principale). - Controllo spot dello screen reader (NVDA su Windows o VoiceOver su macOS) sui pulsanti degli icona e sui dialoghi. - Registra il rischio residuo: ciò che lo scanner non può vedere, ciò che hai differito, chi è il proprietario del follow-up.

A11yGuard è costruito per il primo passaggio misurabile. La conformità legale e le decisioni di giudizio richiedono ancora un proprietario di QA umano. Se il tuo prodotto utilizza l'AI nel processo di assunzione o in flussi di decisione simili, leggi anche le linee guida degli Stati Uniti sugli algoritmi e la discriminazione delle disabilità in modo che l'esclusione dell'interfaccia utente non venga trattata come un bug cosmetico (ADA.gov linee guida sull'AI).

Contrasto che puoi calcolare, contrasto che non puoi

Il contrasto del testo è il fallimento più facile da rilevare: il testo del corpo richiede un rapporto di 4,5:1 con lo sfondo; il testo di grandi dimensioni richiede un rapporto di 3:1 (criterio 1.4.3). I temi generati spesso includono sfondi grigi su grigi o gradienti di placeholder che non soddisfano i requisiti. Misurare contro lo sfondo renderizzato, comprese immagini e sovrapposizioni.

Il contrasto non testuale (1.4.11) è la regola gemella: i confini dei componenti dell'interfaccia utente, le icone necessarie per comprendere il controllo e gli indicatori di focus devono raggiungere un rapporto di 3:1 con i colori adiacenti. Un pulsante disegnato con un solo bordo debole o un anello di focus impostato su un contorno a bassa opacità non supera il test anche se il testo dell'etichetta passa. Le interfacce utente dei grafici e dei dashboard colpiscono lo stesso muro; Smashing Magazine documenta come gli standard di accessibilità ridisegnino la progettazione visiva dei grafici senza richiedere rumore decorativo (standard di accessibilità per la progettazione dei grafici).

Checklist — contrasto

- Copia del corpo ≥ 4,5:1 su ogni tema (incluso il modo scuro) - Testo di grandi dimensioni / grandi numeri ≥ 3:1 - Anello di focus ≥ 3:1 contro la superficie dietro di esso - Affordances con sola icona ≥ 3:1 quando il glifo trasporta il significato - Nessuna dipendenza dal colore solo per lo stato di errore o di successo (abbinare con testo o icona)

Dimensione del bersaglio e trascinamento dopo WCAG 2.2

La dimensione minima del bersaglio (2.5.8) richiede bersagli interattivi di almeno 24×24 pixel CSS al livello AA, con eccezioni limitate per i collegamenti in linea e determinati casi di spaziatura. I layout dell'AI producono comunemente pulsanti di icona di 16 pixel senza padding. Ciò è ora un problema di conformità, non un dibattito di gusto. Il padding, la larghezza/minima altezza o un'area di hit più grande intorno al glifo visibile contano se il bersaglio del puntatore soddisfa le dimensioni.

I movimenti di trascinamento (2.5.7) significano che qualsiasi interazione di trascinamento — pollice di uno slider, carta kanban, scrubber di intervallo — necessita di un'alternativa a un singolo puntatore come pulsanti delle frecce, un input numerico o un clic per impostare. Se un utente non può completare il compito senza trascinare, il modello non è conforme. I generatori amano le demo di trascinamento perché sembrano interattive in un GIF; spediscono il controllo alternativo nello stesso PR.

Checklist — accesso al puntatore

- L'area di hit di ogni pulsante di icona ≥ 24×24 pixel CSS - I bersagli adiacenti hanno abbastanza spaziatura o condividono un'eccezione conforme - Ogni gesto di trascinamento ha un percorso non di trascinamento documentato nell'interfaccia utente - Le aree di hit del tocco funzionano ancora quando le dimensioni del testo del sistema operativo aumentano

Ordine di focus, chrome sticky e 2.4.11

Focus Not Obscured (Minimo) richiede che quando un controllo riceve il focus della tastiera, non sia completamente nascosto dal contenuto creato dall'autore. Le intestazioni sticky, le barre di navigazione inferiori, i banner dei cookie e i widget di aiuto "AI" galleggianti sono i soliti colpevoli nelle app codificate con vibe. Passa alla pagina con questi strati aperti. Se il campo focalizzato si trova sotto una barra sticky di 72 px, correggi il padding di scorrimento o lo stacking, non la vista dell'utente.

Conferma anche 2.4.7 (Focus Visibile): ogni elemento interattivo mostra un indicatore di focus visibile. I generatori spesso rimuovono i contorni "per estetica." Ripristina un anello ad alto contrasto che soddisfi 1.4.11.

Checklist — focus

- Focus visibile sui link, pulsanti, input, widget personalizzati - L'ordine di focus corrisponde all'ordine di lettura per i flussi principali - I modali intrappolano il focus e lo restituiscono all'invocatore alla chiusura - L'interfaccia utente sticky/fissa non copre mai completamente il controllo focalizzato (2.4.11) - Il collegamento di salto è presente e funziona nelle pagine con molti contenuti

ARIA: HTML semantico prima, ARIA seconda

I generatori inventano ruoli ARIA che non corrispondono al comportamento o aggiungono role="button" a elementi che sono già link. Preferisci elementi nativi: <button>, <a>, <nav>, <main>, controlli del modulo. ARIA riempie le lacune; non sostituisce la semantica. I ruoli non corrispondenti confondono i lettori di schermo e possono nascondere l'azione reale. Tratta ogni attributo aria-* generato come una richiesta di verifica.

Quando hai veramente bisogno di un widget personalizzato, segui un modello pubblicato dalla Guida alle pratiche di authoring ARIA e controlla i ruoli/stati contro WAI-ARIA 1.2. Copiare e incollare una stringa di ruolo da una risposta al chat senza supporto per la tastiera è come rendere il markup "accessibile" in un comportamento inaccessibile.

Perché i controlli automatizzati coprono solo una parte dell'immagine

La pratica industriale e la documentazione dei fornitori collocano comunemente la copertura automatizzata nel range del 30-40% delle problematiche di accessibilità del mondo reale. Gli strumenti trovano il testo alternativo mancante, molti fallimenti di contrasto e ARIA non valido. Tuttavia, non possono giudicare completamente se l'ordine di focus corrisponde all'ordine di lettura, se esistono alternative al trascinamento o se il nome di un pulsante icona è comprensibile. Questa lacuna è il motivo per cui un punteggio Lighthouse pulito non è la prova della conformità a WCAG 2.2. Combinare un primo passaggio automatizzato con test da tastiera e una revisione manuale del markup generato.

Errori comuni che i team fanno con l'interfaccia utente AI

- Rigenerare dopo correzioni manuali senza bloccare token o primitivi, in modo che il contrasto e i nomi scompaiano - Fidarsi della registrazione della demo (solo mouse) come prova che il percorso della tastiera funziona - Impilare ARIA per silenziare un linter invece di correggere il tipo di elemento - Spedire gradienti di marketing che non sono stati misurati sul DOM live - Chiamare un build CI verde "compliant" nei deck di vendita — questo linguaggio esagera

Criteri di decisione: AA ora o dopo

Rilasciare i blocchi per la maggior parte delle app B2B a livello AA:

- Nomi accessibili vuoti sulle azioni principali - Testo del corpo inferiore a 4,5:1 sul tema predefinito - Nessun percorso da tastiera attraverso il checkout o il compito principale - Focus completamente nascosto da UI sticky sui campi obbligatori - Azioni critiche solo con trascinamento senza alternativa

Rinviare solo con un proprietario e una data: animazioni decorative secondarie, grafici non critici con un'alternativa di tabella dei dati già presente, rifinitura del widget di aiuto che non blocca i compiti. Rinviato non significa dimenticato.

Cosa non è questo

Questa checklist non è un'audit completa WCAG, non è un VPAT e non è un consiglio legale. Non afferma che A11yGuard (o qualsiasi strumento) garantisce la conformità, la conformità ADA o che le scansione automatiche "non perdono" problemi. Non pubblichiamo metriche dei clienti inventate o miglioramenti di conversione prima/dopo. Il prodotto automa il primo passo misurabile; avete ancora bisogno di un test di QA umano per i criteri di giudizio e per il linguaggio di firma utilizzato con i clienti o i regolatori.

Chiusura

Stampa le tabelle, blocca il ramo, esegui lo scanner, poi esegui il passaggio della tastiera e del naming. Mantieni aperto il testo normativo WCAG e la Guida rapida mentre discuti dei casi limite. Quando il modello rigenera uno schermo, ri-esegui la stessa lista — il debito di accessibilità nelle app con codice vibe è un ciclo, non un progetto una tantum.

Riferimenti

- WCAG 2.2 - Guida rapida WCAG 2.2 - Fondamenti di accessibilità WAI - Guida alle pratiche di authoring ARIA (APG) - WAI-ARIA 1.2 - Smashing Magazine — standard di accessibilità e progettazione dei grafici - ADA.gov — linee guida sull'intelligenza artificiale e la discriminazione delle disabilità