Affianco il tuo team quando definisce percorsi, schermate e componenti. Rivediamo le scelte di accessibilità prima dello sviluppo e le traduciamo in annotazioni su Figma, specifiche e criteri di accettazione.
Affianco responsabili di prodotto, designer e sviluppatori nelle decisioni che determinano l’accessibilità. Il lavoro rende esplicito come devono funzionare i flussi e cosa il team deve realizzare e verificare.
Esamino le scelte che incidono sull’uso del prodotto e le collego a indicazioni operative. Per ogni area chiarisco cosa modificare nel progetto e cosa verificare nell’implementazione.
Rivedo sequenza dei passaggi, gerarchia delle informazioni, etichette e istruzioni. Valuto come la persona riconosce il risultato di un’azione e recupera da un errore.
Esamino contrasto, uso del colore, leggibilità, dimensione dei controlli e adattamento dei contenuti. Distinguo i problemi visibili nel prototipo dai comportamenti da provare nel browser, come ingrandimento e reflow.
Descrivo uso da tastiera, ordine e gestione del focus, nomi accessibili e cambiamenti di stato. Esamino anche caricamento, errori e conferme, per rendere esplicito il comportamento atteso.
Definiamo i riferimenti di accessibilità a partire dalle WCAG e dal contesto del prodotto. Consideriamo mercati, componenti esistenti e vincoli tecnici; le decisioni aperte restano documentate e assegnate ai referenti.
Collaboro con i referenti del progetto nei momenti in cui si prendono le decisioni. Ogni passaggio lascia materiali condivisi e responsabilità esplicite, fino al confronto con chi implementa.
Inquadramento
Raccogliamo obiettivi, attività delle persone, materiali e vincoli. Individuiamo i flussi da esaminare, i referenti e le decisioni che richiedono un confronto.
Revisione con il team
Rivedo flussi e componenti con design e sviluppo. Prepariamo le annotazioni in Figma, valutiamo le alternative e risolviamo le ambiguità prima del passaggio all’implementazione.
Passaggio allo sviluppo
Chiarisco i comportamenti attesi con chi sviluppa e con chi verifica. Il team realizza il prodotto; l’eventuale verifica dell’implementazione e il retest delle correzioni si definiscono nell’incarico.
Le indicazioni devono poter essere usate nel lavoro quotidiano. Per i flussi e i componenti concordati preparo consegne che collegano il progetto alle attività di sviluppo e QA.
Requisiti
Documento requisiti e criteri di accettazione verificabili: cosa deve poter fare la persona, come deve rispondere l’interfaccia e quali prove servono. Il team può inserirli nelle attività di sviluppo e nella definition of done.
Figma
Lavoro con i designer sui file Figma per preparare e rivedere le annotazioni di accessibilità. Affianco a schermate, componenti e varianti le indicazioni che il solo disegno non comunica, così chi sviluppa sa quale comportamento realizzare e QA sa cosa verificare.
Design system
Se il team usa un design system, collego le indicazioni ai componenti esaminati. Documentiamo stati, regole d’uso e comportamenti da mantenere nelle nuove funzionalità, verificandoli ogni volta nel contesto.
Due tavole illustrative mostrano come collegare un elemento del progetto alle indicazioni per sviluppo e QA. Sono esempi fittizi, non schermate di file Figma o lavori per clienti. Le note numerate sono disponibili anche come testo nella pagina.
Il titolo visibile «Inviare la richiesta?» dà il nome accessibile al dialog. All’apertura, lo screen reader deve riconoscere il dialog e il suo titolo.
Per questo esempio, il focus iniziale è su «Annulla». Tab e Maiusc+Tab restano nel dialog; Esc lo chiude senza inviare. Il contenuto sullo sfondo non è interattivo.
Alla chiusura senza invio, il focus torna al pulsante «Rivedi e invia», che aveva aperto il dialog. Il comportamento si verifica sul componente implementato.
«Email (obbligatoria)» resta visibile anche dopo la compilazione ed è associata al campo nel codice. Il placeholder non sostituisce l’etichetta.
L’istruzione spiega quale indirizzo inserire. Va collegata al campo, così è disponibile anche alle tecnologie assistive quando la persona lo compila.
Il messaggio descrive il problema e come correggerlo. Nel codice, errore e stato non valido sono associati al campo; il colore è accompagnato da testo e simbolo. Il valore inserito viene conservato.
Quando iniziare, come condividere i materiali e cosa si può verificare in fase di progetto.
Raccontami cosa state progettando, a che punto siete e quali decisioni sono ancora aperte. Possiamo partire da un flusso, da un componente o da un file Figma: non serve avere già scritto tutti i requisiti.