Intervista a Valeria Malacasa

Valeria Malacasa è una web designer e UX/Ul designer torinese.

Dal 2016 progetta e sviluppa siti wèb e interfacce web, sia per brand privati sia per enti della Pubblica Amministrazione italiana.

Nel 2026 ha creato la newsletter Switch su Linkedin, attraverso cui condivide approfondimenti su accessiblità web, inclusività, web design, usabilità web e ottimizzazione delle web performance, è autrice del libro "Switch on - Accessibilità".

1. Valeria, partiamo semplice: perché un libro sull’accessibilità web proprio adesso? C’è stato un episodio, un progetto o una frustrazione professionale che ti ha fatto dire: “Ok, questa cosa va messa in ordine”?

Qui (su LinkedIn ndr.) ho iniziato a pubblicare contenuti educativi e divulgativi sull’accessibilità web verso inizio 2026, e ho trovato subito un bel riscontro. 

In particolare, un mio follower ha commentato così un post sullo skip link: “Sto imparando più da te che in tanti corsi che ho seguito”. Altri mi hanno scritto, privatamente e non, che con il mio linguaggio semplice riuscivo a spiegare concetti anche complessi senza renderli noiosi.

Questo mi ha dato la spinta che serviva!

Ho capito di avere delle cose da dire e che serviva uno strumento che avvicinasse i professionisti all’accessibilità web, in un format “entry level”, che andasse dritto al punto.

2. Switch On: Accessibilità è il tuo primo libro. Cosa ti ha spinta a trasformare competenze, esempi e checklist in una guida strutturata?

Lavoro su progetti della Pubblica Amministrazione da inizio 2022, e in questi anni ho capito che sull’accessibilità web ci sono ancora molti pregiudizi e barriere, che scoraggiano designer e developer.

Primo fra tutti: l’idea che l’accessibilità web sia difficile, sia da studiare che da applicare.

In realtà, molte delle best practice sono semplici, più di quanto si pensi!

Ma se per studiare l’accessibilità si parte dalla documentazione ufficiale di W3C o da un manuale di 350 pagine su normative, storia dell'accessibilità digitale e spiegazione completa delle WCAG (gli standard internazionali dell’accessibilità web), è chiaro che ci si può scoraggiare e lasciar perdere l’argomento, delegando a figure specializzate.

È soprattutto per questo che ho voluto creare una guida pratica, ben strutturata, agile e focalizzata solo su ciò che serve realmente nel lavoro quotidiano di web designer e web developer, perché una volta arrivati all’ultima pagina i lettori pensino: “Allora, non è poi così complicato fare un sito web accessibile!”.

3. A chi hai pensato mentre lo scrivevi: designer, sviluppatori, agenzie, freelance, clienti finali? Chi vorresti che lo tenesse aperto accanto al monitor mentre lavora?

Principalmente è scritto per web designer, o comunque per chi si occupa della progettazione grafica e dello sviluppo di siti web.

Ho scritto il libro portando la mia esperienza di web designer e ho seguito esattamente il processo di lavorazione dei miei progetti, partendo da una panoramica sull’accessibilità, per poi arrivare al progetto grafico, allo sviluppo, alla creazione dei contenuti tramite linguaggio inclusivo, e infine al test.

4. Molti trattano l’accessibilità come una verifica finale, quasi una revisione da fare quando il sito è già finito. Perché secondo te è un errore?

L’idea che un prodotto o servizio debba poter essere utilizzato da tutte le persone, indipendentemente dalle loro condizioni fisiche e mentali, dalla presenza o meno di disabilità, deve entrare nel progetto fin dall’inizio.

Trattarla solo a fine progetto porta principalmente due svantaggi:

1. livello di accessibilità basso o inesistente;
2. maggiore investimento per la revisione.

Un esempio concreto: gli scivoli dei marciapiedi.

Se un marciapiede non ha uno scivolo che consenta un passaggio agevole a persone in carrozzina, persone con ridotta capacità motoria o persone che portano un passeggino, che si fa? I due scenari, di solito, sono:

1. nel peggiore dei casi, il marciapiede rimane così, e con esso la barriera architettonica;
2. nel migliore dei casi, il marciapiede viene spaccato e viene aggiunto lo scivolo, con un costo per la collettività in termini pecuniari e di tempistiche.

Se, invece, quel marciapiede fosse stato realizzato fin da subito con gli scivoli adeguati, il problema non si sarebbe posto, le tempistiche e i costi di realizzazione sarebbero stati pressoché identici e la barriera architettonica non si sarebbe mai presentata.

Ho un po’ semplificato, ma il concetto vale anche per l’accessibilità web.

Rimettere mano al codice e alla grafica di un’interfaccia può costare settimane di sviluppo, con conseguenti costi che verrebbero praticamente azzerati se invece si includesse l’accessibilità fin da subito.

Spesso, sono proprio questi costi di rifacimento a bloccare, e le interfacce rimangono non accessibili.

5. Qual è il falso mito più duro da smontare sull’accessibilità web? Quello che senti ripetere più spesso e che ti fa venire voglia di lanciare un validatore WCAG dalla finestra.

Ce ne sono parecchi e la reazione è più o meno quella!

Probabilmente, quello che mi dà più fastidio - e che ho incluso anche nel libro - è che l’accessibilità web riguardi solo poche persone.

Sono due gli aspetti di questo falso mito che bisogna smontare.

Prima di tutto, l’accessibilità web riguarda potenzialmente chiunque, non solo persone con disabilità. Pensa al contrasto colore: è utile per persone ipovedenti, ma anche per chi usa il telefono sotto il sole o con una luminosità ridotta. Un po’ come lo scivolo del marciapiede di cui parlavo prima: è fondamentale per persone in carrozzina, ma utile anche a me che porto mio figlio nel passeggino o a una persona che usa temporaneamente le stampelle.

In secondo luogo, c’è una ragione più etica per cui questo pregiudizio non ha senso.

Se le persone che possono giovare di un sito web accessibile fossero, effettivamente, poche, questa sarebbe una buona ragione per escluderle? Perché una persona cieca o sorda dovrebbe “valere meno” di cento persone non cieche e non sorde? E se quell’unica persona con disabilità fosse proprio quella giusta per il sito web, che ha bisogno di chiedere un preventivo o richiedere una demo del prodotto venduto?

Un altro vantaggio non da poco, nel web design, è che un codice HTML pulito e semantico è utile sia per gli screen reader sia per i bot dei motori di ricerca e le AI, per cui ha ripercussioni positive sulla SEO e la GEO.

6. Nel libro parli di design accessibile, contrasto cromatico, HTML semantico, ARIA, screen reader e navigazione da tastiera. Da dove dovrebbe iniziare chi oggi si sente davanti a un labirinto?

Non ti mentirò: le regole di accessibilità sono tante, alcune più semplici, altre meno, e non tutte le buone pratiche sono codificate nelle WCAG. L’accessibilità web passa da vari aspetti, visivi e non, tutti importanti allo stesso modo.

La buona notizia è che non bisogna necessariamente conoscerli tutti!

Il design è il primo passo, perché se ci sono problemi di accessibilità, questi si presenteranno anche in fase di sviluppo, ma non si può negare che usare codice HTML semantico sia alla base di un’interfaccia accessibile.

Per questo il mio libro è un buon punto di partenza, perché individua solo le regole essenziali e permette di avere una panoramica sul tema.

7. Se dovessi indicare tre errori comuni che rendono un sito meno accessibile, quali sceglieresti? Quelli piccoli, quotidiani, apparentemente innocui, ma capaci di chiudere porte in faccia agli utenti.

Sono gli errori che vedo fare più di frequente - e, tra l’altro, quelli che si risolvono anche più facilmente - :

1. rapporto di contrasto fra testo e sfondo insufficiente;
2. uso di tag HTML <button> per i link e di <a> per i bottoni;
3. mancanza dello skip link all’inizio della pagina.

Sono tre errori “piccoli”, semplici da risolvere, ma che per una persona che usa screen reader, con impedimenti visivi o con difficoltà nell’uso di mouse e trackpad, rendono la navigazione complessa e frustrante.

8. Quanto pesa l’accessibilità nella qualità complessiva di un sito? In altre parole: un sito accessibile è “solo” più inclusivo, o è anche progettato meglio?

Per me, l’accessibilità pesa tanto quanto tutti gli altri aspetti qualitativi, dall’estetica all’ottimizzazione delle conversioni.

Molte best practice di accessibilità hanno ripercussioni importanti sulla SEO, sull’usabilità e sulle conversioni.

Un sito web molto bello, ma non accessibile, probabilmente avrà un HTML sporco e non semantico, contenuti che cambiano tramite JavaScript, elementi visivi complessi da percepire e usare, e questo non è un male solo per le persone con disabilità: è un male per tutti i visitatori e una potenziale perdita di opportunità di business e branding per chi in quel sito web ha investito del denaro.

Un sito accessibile porta benefici a chiunque lo visiti, di conseguenza anche al brand che con quel sito vuole ottenere risultati concreti.

9. Cosa possono fare concretamente agenzie e team per integrare l’accessibilità nel processo senza trasformarla in una montagna burocratica?

Prima di tutto, bisogna capire cos’è l’accessibilità web e perché è importante.

È una parte imprescindibile del nostro lavoro ed è il motivo per cui ho inserito questo argomento nella prima parte del mio libro.

Bisogna abbandonare ogni pregiudizio, capire su quali principi si basa l’accessibilità e quali benefici porta, non solo ai visitatori di un sito web ma a tutti gli stakeholder.

Successivamente, si può partire dal mio libro, oppure studiare manuali più completi, ma indubbiamente a un certo punto bisogna aprire il sito web di W3C e studiare le WCAG, almeno quelle di livello A e AA e che si applicano al progetto realizzato.

Ci sono poi altri aspetti normativi da approfondire, come la dichiarazione di accessibilità e il meccanismo di feedback. Qui, affrontare la burocrazia è inevitabile nel caso in cui il sito web rientri negli obblighi previsti dalla Legge Stanca o dal recente European Accessibility Act. 

10. Se una persona finisse il tuo libro e decidesse di cambiare una sola cosa nel modo in cui progetta o sviluppa siti web, quale vorresti che fosse?

Vorrei che quella persona imparasse a farsi sempre delle domande, che poi è il motivo per cui ho creato il progetto Switch.

Se la persona che ha letto il libro iniziasse un nuovo sito web, e al momento di scrivere il codice HTML del logo in alto a sinistra si chiedesse: “Un momento, ma se lo scrivo in questo modo, poi lo screen reader lo legge correttamente?” allora avrò certamente raggiunto il mio obiettivo!

Potete conoscere meglio Valeria su LinkedIn: https://www.linkedin.com/in/valeriamalacasa/ o sul suo sito web: valeriamalacasa.it