Vai al contenuto principale

Domande

L'applicazione generata è accessibile alle persone con disabilità?

In parte, e la risposta onesta ha tre tempi. NON è certificata WCAG e non è stata verificata da terzi: nessuna pagina di questo sito dirà il contrario. Diverse basi ci sono però per costruzione, perché l'interfaccia è scritta da un programma deterministico e non ridisegnata ogni volta — focus da tastiera visibile, movimento ridotto se il sistema lo chiede, moduli reali, nessuna finestra di dialogo nativa. A ogni generazione l'albero di accessibilità di ogni schermata viene rilevato e pubblicato in un rapporto. Ciò che manca è nominato più sotto anziché taciuto. E poiché il codice vi appartiene, una correzione di accessibilità è un lavoro ordinario, non una richiesta depositata presso un fornitore.

Ciò che è acquisito per costruzione, perché è un programma a scrivere l'interfaccia

La differenza sta in chi tiene la penna. L'interfaccia non è disegnata da un modello a ogni generazione: un costruttore deterministico la emette da una libreria di componenti comune. Una garanzia posta una volta vale quindi per tutte le schermate di tutte le applicazioni, invece di dipendere dall'ispirazione del giorno. È la proprietà più utile di questa architettura in materia di accessibilità, e non è uno slogan: si verifica schermata per schermata.

In concreto: ogni elemento interattivo prende il focus da tastiera e mostra un anello visibile tratto dalla palette dell'applicazione — non quello predefinito del browser, che sparisce su uno sfondo colorato — e lo stesso anello non compare al clic del mouse, dove non insegna nulla. Un utente il cui sistema chiede di ridurre le animazioni ottiene transizioni di durata trascurabile. Le finestre di inserimento sono moduli reali: Invio conferma, il primo campo prende il focus all'apertura e il pulsante principale è un pulsante di invio.

Nessuna finestra di dialogo nativa, e perché è una buona notizia

Un'applicazione prodotta qui non usa mai la finestra di conferma nativa del browser. Eliminare una riga avviene in due tempi, dentro la pagina: un primo clic arma l'azione, un secondo la conferma, e nel mezzo si può rinunciare. Lo stesso principio vale per disattivare un account.

Questa decisione non è stata presa per l'accessibilità — nasce da un problema di automazione e da una questione di linguaggio visivo — ma la sua conseguenza è reale e va detta. Una finestra nativa esce dal documento, interrompe il filo di lettura e non è annunciata allo stesso modo a seconda del browser e dello strumento assistivo. Una conferma posta nella pagina resta nell'ordine di tabulazione, si legge come il resto della schermata e lascia la possibilità di tornare indietro senza rispondere a una domanda modale.

Ciò che è MISURATO a ogni generazione — e ciò che la misura non promette

Prima della consegna ogni applicazione viene aperta in un browser reale e percorsa schermata per schermata. In quell'occasione non è l'immagine a essere esaminata ma l'albero di accessibilità: la struttura che attraversa uno screen reader. Vi si rilevano pulsanti, link e campi senza nome accessibile, livelli di titolo saltati, immagini senza descrizione ed etichette identiche ripetute fuori da un elenco. Una « × » di chiusura è contata come non nominata, perché uno screen reader la pronuncia « segno di moltiplicazione ».

Qui sta il punto di onestà, ed è decisivo: è un RAPPORTO, non una porta. Non c'è soglia, né verdetto, né blocco — una schermata con controlli senza nome non viene trattenuta alla consegna. La misura dice dunque ciò che si sa dell'applicazione; non promette alcun livello di conformità. Una cifra di copertura che pretendesse il contrario sarebbe esattamente il tipo di promessa che questa pagina rifiuta di fare.

Ciò che NON è fatto, e cosa potete farne

Tre mancanze, nominate. Le finestre di inserimento non intrappolano il focus: la tabulazione può uscire da un dialogo aperto, mentre la regola vuole che vi giri dentro. Nessuna regione vocale è posta: un salvataggio riuscito, un errore, un elenco aggiornato si vedono sullo schermo ma non sono annunciati a nessuno. E non esiste né certificazione WCAG né verifica indipendente — quindi se siete soggetti a un obbligo di legge, questa applicazione non ve ne dispensa e non pretende di farlo.

Ciò che potete farne è proprio ciò che distingue questa situazione da un software chiuso. Il codice vi appartiene, è recuperabile come archivio o su un repository, ed è un progetto Next.js ordinario: intrappolare il focus di un dialogo o aggiungere una regione vocale sono lavori front-end ben delimitati, quantificabili, che qualunque fornitore sa condurre. Presso un editore classico lo stesso difetto è un ticket di cui non controllate né la priorità né la data. Se rientrate in una normativa sull'accessibilità, prevedete la vostra verifica: è comunque obbligatoria, e qui le sue conclusioni sono azionabili.

Per approfondire

Domande correlate

Descrivi la tua esigenza e guarda l'applicazione prodotta