di A11yGuard (LX AI)

Contrasto e ARIA nelle app con codice di vibrazione

Le interfacce utente con codice di vibrazione falliscono l'accessibilità in due punti che i scanner raramente rilevano insieme: la matematica del contrasto e i nomi accessibili. Un componente può superare un'audit di colore e ancora essere inutilizzabile quando il suo ruolo è errato o il suo nome è vuoto. Entrambi si rompono di nuovo sulla rigenerazione, quindi la correzione appartiene a una checklist, non a una modifica una tantum.

Come si rompe effettivamente la matematica del contrasto nei temi generati

Quando un modello inventa una palette, di solito copia una mood board: testo in slate morbido, chip pastello, carte traslucide. Ciò sembra fine sul monitor di un designer e fallisce i rapporti in WCAG 2.2 nel momento in cui arriva il contenuto reale. Il testo del corpo a livello AA necessita di un rapporto di contrasto di 4,5: 1 rispetto allo sfondo (criterio di successo 1.4.3). Il testo grande può utilizzare 3: 1. I generatori non eseguono quella matematica; scelgono valori esadecimali che "sembrano secondari."

Un secondo modo di fallimento è lo sfondo che non si vede nell'esportazione di Figma. Il testo su un'immagine eroe, un lavaggio del gradiente o un pannello di glassmorphism necessita dello sfondo renderizzato, non del token denominato bg-surface. Campiona il pixel sotto il glifo o spedirai un token di audit e ancora spedirai una copia illeggibile. I grafici e l'inchiostro dei dati hanno la stessa trappola; l'articolo di Smashing Magazine sul contrasto del grafico mostra come le soglie standard di progettazione visiva cambino senza trasformare ogni grafico in un arcobaleno (standard di accessibilità per la progettazione del grafico).

Il contrasto non testuale è il gemello silenzioso

Il criterio di successo 1.4.11 (Contrasto non testuale) chiede 3: 1 sui confini dei componenti dell'interfaccia utente, oggetti grafici necessari per comprendere il contenuto e stati come indicatori di focus. Un bordo leggero di 1 px che sembra "premium" spesso fallisce. Un anello di focus impostato su outline: 2px solid rgba (15,118,110,.35) fallisce anche quando il testo dell'etichetta supera 4,5: 1. I controlli icona-solo che si affidano a un glifo grigio chiaro su bianco sono lo stesso tipo di bug. Tratta i colori del bordo, dell'icona e del focus come token di prima classe con rapporti pubblicati, non come decorazioni dopo il fatto. Il riferimento rapido WCAG 2.2 è il posto più veloce per verificare nuovamente quali criteri si applicano ad AA.

I token battono le patch esadecimali one-off

La soluzione duratura è noiosa: definisci token di colore semantici (testo-principale, testo-sfumato, bordo-forte, anello-di-focus) con rapporti misurati contro ogni sfondo consentito, quindi vieta al modello di inventare stringhe esadecimali nei file dei componenti. Metti la regola di vietare nel prompt e nel CI. Se la rigenerazione può riscrivere il colore: #94a3b8 in un'etichetta del pulsante, il tuo "fix" non è mai stato un fix. Accoppia i token con uno strato di variabili CSS in modo che la modalità scura e i temi di marketing ereditino gli stessi vincoli.

I nomi accessibili non sono etichette visibili

I lettori dello schermo annunciano il nome accessibile di un controllo, non i dati del percorso SVG. Un pulsante icona che mostra un glifo del cestino senza contenuto testuale, senza aria-etichetta e senza etichetta associata <label> diventa "pulsante" senza scopo. Quello è un fallimento di denominazione, non un fallimento di contrasto, ed è il motivo per cui le verifiche dei colori rimangono verdi mentre gli utenti della tastiera si bloccano.

L'ordine di calcolo del nome è definito dall'albero di accessibilità: testo del contenuto, riferimenti etichettati, quindi etichette fornite dall'autore come aria-etichetta. I generatori spesso emettono il glifo e una classe Tailwind e si fermano. Inoltre, inventano nomi duplicati ("Chiudi" su ogni controllo di dismiss in uno stack di modal) o nomi che descrivono la metafora dell'icona invece dell'azione ("cestino" invece di "Elimina fattura"). Preferisci il linguaggio dell'azione che corrisponde all'affordance visibile.

Dove i nomi scompaiono dopo la rigenerazione

La rigenerazione cancella i valori aria-etichetta inline che sono stati aggiunti a mano perché il modello li tratta come rumore opzionale. Sopravvivi a ciò:

- Tenendo mappe di icone in un modulo che accoppia sempre glifo + stringa di nome - Utilizzando testo visibile accanto alle icone quando lo spazio lo consente (il nome arriva gratuitamente) - Fallire CI quando un elemento interattivo ha un nome accessibile vuoto - Rifiutare PR che introducono <div onClick> senza un ruolo e un pacchetto di nome

Il panorama fondamentale di WAI è ancora il miglior breve introduzione su perché i nomi, i ruoli e gli stati devono viaggiare insieme (WAI Accessibility Fundamentals).

Quando ARIA aiuta — e quando nasconde il bug

L'HTML nativo esprime già ruoli, comportamento della tastiera e molti stati. Un vero <button> è focalizzabile, si attiva con Invio e Spazio, e partecipa ai form. Un <div role="button" tabindex="0"> che un modello incolla ancora necessita di quei gestori di tasti, di uno stato premuto o disabilitato quando pertinente, e di un nome accessibile. Saltare qualcosa di tutto ciò e la tecnologia assistiva annuncia un pulsante che non fa nulla con Spazio. La guida alle pratiche di authoring ARIA (APG) esiste per i casi in cui si ha veramente bisogno di un widget personalizzato; non è una licenza per ridisegnare un div in ogni controllo.

Errori comuni di ARIA nel markup codificato con vibe

- Ruolo sull'elemento sbagliato: role="button" su un <a href>, o role="link" su un pulsante che invia un modulo - ARIA decorativo: aria-label che duplica il testo visibile e confonde alcune combinazioni di AT - Stato obsoleto: aria-expanded="true" lasciato indietro dopo che un rendering del client attiva o disattiva un pannello - Spam di landmark: cinque regioni role="navigation" senza nomi, quindi le liste di salti diventano rumore - Regioni live per vanità: aria-live="polite" su ogni toast in modo che la pagina chiacchieri

La raccomandazione WAI-ARIA 1.2 descrive l'ontologia dei ruoli e delle proprietà; utilizzarla quando si deve estendere oltre l'HTML, non come livello predefinito su ogni nodo (WAI-ARIA 1.2).

Percorsi della tastiera che il generatore dimentica

L'ordine di focus, il focus visibile e i collegamenti di salti vengono persi nei layout a colpo singolo. Il criterio 2.4.7 richiede un indicatore di focus visibile. Il criterio 2.4.11 (Focus Not Obscured — Minimum), nuovo in WCAG 2.2, richiede che le intestazioni fisse, i banner dei cookie e le widget di chat galleggiante non nascondano completamente il controllo focalizzato. Tab sulla pagina generata dall'alto verso il basso. Confermare che l'ordine corrisponde all'ordine di lettura. Confermare che nessun controllo è rimasto bloccato dietro un overlay. Confermare che l'anello di focus soddisfa 1.4.11 rispetto a ciò che si trova dietro di esso.

Un breve passaggio manuale della tastiera (15 minuti)

- Scollegare il mouse. Aprire la pagina in un profilo pulito. - Tab dalla barra dei browser nel documento. C'è un collegamento di salto che funziona? - Raggiungere ogni azione principale senza folklore delle frecce del componente che non è mai stato implementato. - Aprire e chiudere ogni modale con Escape. Il focus torna all'invocatore? - Attivare l'intestazione fissa e il banner dei cookie. È possibile ancora vedere il controllo focalizzato? - Colpire ogni pulsante di icona con un lettore di schermo (NVDA o VoiceOver). Il nome corrisponde all'azione?

Quel passaggio cattura ciò che Lighthouse non farà. Gli strumenti automatizzati sono un primo filtro; non sono un certificato di conformità. Per gli strumenti di assunzione e le decisioni automatizzate, le linee guida statunitensi ricordano inoltre ai costruttori che le funzionalità AI possono creare rischi di discriminazione per disabilità se le interfacce escludono le persone che utilizzano la tecnologia assistiva (ADA.gov linee guida AI). L'interfaccia utente del prodotto non è esente da quel pensiero solo perché un modello ha scritto il JSX.

Assicurarsi che il controllo sopravviva alla rigenerazione

Poiché la rigenerazione cancella le patch manuali, il controllo duraturo sembra infrastruttura:

- Token di design con contrasto misurato, verificato in un test unitario o plugin stylelint - Primitivi di componenti (IconButton, TextField) che emettono sempre stili di nome e focus - Gate di accessibilità CI (axe o equivalente) sulle richieste di pull, che falliscono su nomi vuoti e contrasto - Vincoli di prompt che vietano l'esadecimale grezzo e vietano div-as-button senza una flag di eccezione esplicita - Passaggio della tastiera umana su ogni verticale prima del rilascio, registrato come un elemento di controllo, non un'atmosfera

Trattare il markup generato come output di bozza non attendibile. Revisionarlo nello stesso modo in cui si revisiona una richiesta di pull di un junior che arriva da un hackathon di un weekend: supporre nomi mancanti, supporre ARIA teatrale, supporre testo pastello.

Criteri di decisione: correggere nei token, primitivi o codice di pagina?

Utilizzare questo ordine quando arriva un rapporto di bug:

- Se molte pagine condividono il colore di testo smussato errato, correggere il token e rimisurare i rapporti. - Se un tipo di controllo manca di nomi (tutti i pulsanti dell'icona), correggere il primitivo e cancellare le patch locali. - Se un singolo eroe di marketing fallisce su una foto, correggere il overlay o il trattamento di testo della pagina. - Se ARIA è stato incollato sull'elemento errato, sostituirlo con un controllo nativo prima di scrivere ulteriori attributi.

Le patch di ARIA a livello di pagina sono le meno durature. Sono anche quelle che le sessioni di vibe-coding amano emettere. Spingere le correzioni verso l'alto.

Cosa questo non è

Questo articolo non è un certificato di conformità WCAG per il tuo prodotto. Non è un consiglio legale e non afferma che eseguire A11yGuard (o qualsiasi scanner) renda un sito "compliant ADA" o "100% accessibile." I controlli automatici di contrasto e ARIA rilevano errori misurabili; non riescono a rilevare le decisioni di valutazione sull'ordine di lettura, le alternative di trascinamento e se un nome è comprensibile. Non inventiamo loghi di clienti, aumenti di conversione o garanzie di "non perdere mai un bug di contrasto." Il ruolo onesto del prodotto è un primo passaggio veloce più una checklist che si possiede ancora.

Chiusura

La matematica del contrasto e i nomi accessibili falliscono in modo indipendente e si rigenerano insieme. Blocca i token, preferisci i controlli nativi, verifica ARIA contro APG quando devi personalizzare e mantieni un passaggio da tastiera nel rituale di rilascio. Utilizza i riferimenti qui sotto quando una richiesta su un rapporto o un criterio è in disputa — il testo della specifica vince sulla memoria di un modello di chat.

Riferimenti

- WCAG 2.2 - Riferimento rapido 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 per l'intelligenza artificiale e la discriminazione delle disabilità