top of page

Guido Giuliani

—

2 luglio 2026

Come rendere un sito web accessibile

L'accessibilità web è un obbligo di legge ed è pertanto necessario raggiungerla: vediamo come

Due mani scrivono su una tastiera a simboleggiare l'accessibilità web

Introduction

This Privacy Notice aims to clearly and transparently explain which personal data we collect when you visit our website, why we collect it, how we use it, and what Your rights are.

We process your personal data in accordance with Regulation (EU) 2016/679 (GDPR) and applicable national data protection laws. We are committed to ensuring that all processing activities are carried out in accordance with the principles of lawfulness, fairness, transparency, data minimization, integrity, and confidentiality.

Specifically, in this notice you will find information about:
 

  • which data we collect about you and for what purposes;

  • the legal bases on which we process such data;

  • who we may share your data with;

  • how long we retain your data;

  • your rights and how to exercise them.
     

While we sometimes need Your data for example, to respond to your requests or improve our website), we do so with respect, care and only when truly necessary.

Our Privacy Promises
 

  • We deeply value your privacy, and for this reason, we guarantee that:

  • We treat your data as if it were our own.

  • We use your data only for the purposes outlined in this notice.

  • We retain your data only for as long as strictly necessary.

  • We do not share your data with third parties without a valid legal basis or your explicit consent.
     

1. Who Processes Your Personal Data

The Data Controller — that is, the entity that determines the purposes and means of the processing of Your personal data — is AccessiWay S.a.S., with registered office at 7 Rue du Général Henrion Bertier, 92200 Neuilly-sur-Sein registered with the Nanterre Trade and Companies Register under number 914 022 595.

AccessiWay is part of the team.blue group and, in certain cases, acts as joint controller together with team.blue NV, with registered office at Skaldenstraat 121, 9042 Ghent, Belgium. In this context, Your personal data may be shared within the group for statistical, administrative, operational, and service improvement purposes.

AccessiWay and team.blue have defined their respective roles and responsibilities under a joint controllership agreement pursuant to Article 26 of the GDPR, ensuring full compliance with data protection regulations.

For more information regarding joint controllership or to exercise Your rights, you may contact AccessiWay via email at the following email addresses:

📧 legal.fr@accessiway.com or info@accessiway.com.

2. Who This Privacy Notice Applies To

This notice applies to:
 

  • users who browse the website www.accessiway.com,

  • individuals who contact us through the form available on the website or via email;

  • users who interact with tools we have implemented (e.g. widgets, cookies);

  • individuals who, through the website or other channels, access external platforms or third-party entities through which they may submit a job application (e.g. recruiting portals or employment agencies).

  • In such cases, the privacy notices of the third parties involved — independent from AccessiWay — also apply.
     

3. What Data We Process

To manage your interaction with our website, we may process the following categories of personal data:
 

  • Identification and contact details such as name, surname, company, job title, email address, and phone number.

  • These data may be partially processed through our customer relationship management (CRM) system.

  • Data relating to your interaction with our services such as information collected via the website or through Hubspot, such as communication history, preferences, requests, and commercial or technical notes.

  • Technical data such as IP address, device type, operating system, browser, access times, and other data automatically recorded by our systems or servers.

  • Browsing data and preferences such as collected via cookies or similar technologies, in accordance with the choices expressed through the cookie consent banner.

  • Application data such as personal information included in your CV or other documents submitted through third-party platforms (e.g. professional experience, education, contact details).

  • These data are processed by AccessiWay only after being transmitted by the third party, which remains autonomous in the initial processing.
     

4. Purposes and Legal Basis of Processing

We process Your personal data in compliance with Regulation (EU) 2016/679 (GDPR) and applicable national data protection laws. Your data may be processed for the following purposes:
 

  • Technical operation of the website
     

We process technical data, using technical cookies and similar tools, to allow You to access the site, view it correctly, and ensure it functions properly (e.g. browsing, content loading, storing preferences).

📌Legal basis: this processing is necessary to provide a service requested by the user, pursuant to Article 6(1)(b) of the GDPR. Your consent is not required for these cookies.
 

  • Handling contact or support requests
     

When you send us a request — via the contact form or by email — we process your data to respond and provide the information requested.

📌 Legal basis: this processing is necessary to take steps at your request prior to entering into a contract, pursuant to Article 6(1)(b) of the GDPR.
 

  • Compliance with legal obligations
     

In certain cases, we may need to process your data to comply with legal obligations, such as tax, accounting, or IT security requirements.

📌 Legal basis: this processing is based on compliance with a legal obligation, pursuant to Article 6(1)(c) of the GDPR.

  • Statistical analysis and website improvement
     

We use analytical tools (e.g. analytical cookies) to collect aggregated data in order to understand how the website is used and to improve its content and functionality.

📌 Legal basis: we process this data only with your freely given and specific consent, pursuant to Article 6(1)(a) of the GDPR.

  • Marketing and Profiling
     

If you authorize us to do so, we may use your data to send you promotional communications or provide personalized content (e.g. through profiling cookies).

📌 Legal basis: this processing is carried out only with your explicit consent, pursuant to Article 6(1)(a) of the GDPR. You may withdraw your consent at any time without affecting the lawfulness of processing based on consent before its withdrawal.
 

  • Management of job applications through third parties
     

We may receive job applications via third-party platforms (e.g. job portals) or through recruitment agencies. In such cases, we process the submitted data to assess your suitability for the proposed role.

📌 Legal basis: this processing is necessary to take steps at your request prior to entering into a contract, pursuant to Article 6(1)(b) of the GDPR.

Note: the privacy policies of the third-party platforms or agencies involved also apply, independently of AccessiWay.

5. Cookies and Tracking Tools

This website uses a cookie management system provided by iubenda, which allows you to:
 

  • view a full and transparent list of the cookies in use;

  • modify or withdraw your consent at any time;

  • access the complete Cookie Policy, integrated in the cookie widget.
     

You can manage your preferences by clicking on the cookie widget icon located at the bottom left corner of every page on the site.

Technical cookies are necessary and therefore enabled by default. Other non-essential cookies (analytical, profiling) are only enabled with your consent.

For more information, please refer to the full Cookie Policy accessible from the cookie widget.

6. Use of accessWidget

This website integrates accessWidget, an automated accessibility tool developed by accessiBe Ltd. and distributed by AccessiWay. The widget allows users to personalize their browsing experience based on their needs.

When the user activates the widget, their IP address is technically transmitted, but:
 

  • it is not stored, tracked, or associated with identifiable individuals;

  • it is anonymized via a proxy located in the European Union;

  • it is not used for profiling or marketing purposes.
     

📌 Legal basis: provision of a service requested by the user (Article 6(1)(b) of the GDPR).

7. Data Security

We adopt appropriate technical and organizational measures to ensure the security, integrity, and confidentiality of the personal data we process. These measures are designed to prevent unauthorized access, loss, disclosure, or alteration of your data. In particular, we implement:
 

  • secure connections via HTTPS (SSL/TLS);

  • authentication systems and access control;

  • access limitation and internal access tracking mechanisms;

  • regular audits and verification procedures;

  • continuous updates to systems and security measures according to the level of risk.
     

8. Data Retention

Your personal data is stored only for the time strictly necessary to achieve the purposes for which it was collected. Specifically:
 

  • Contact data: up to 10 years if relevant for contractual or legal purposes;

  • Technical and browsing data: according to what is outlined in the Cookie Policy;

  • Marketing data: until consent is withdrawn.
     

9. Your Rights (Data Subject Rights)

As a data subject, you may exercise the rights provided under Articles 15–22 of the GDPR at any time. In particular, you have the right to:
 

  • Obtain confirmation as to whether or not your personal data is being processed and access such data (right of access);

  • Request the rectification of inaccurate personal data or the completion of incomplete data (right to rectification);

  • Request the erasure of your data, if the conditions set out in the GDPR are met (right to erasure);

  • Obtain restriction of processing where applicable (right to restriction);

  • Object to the processing of your data, in whole or in part, under certain circumstances (right to object);

  • Receive your data in a structured, commonly used, and machine-readable format, and, where technically feasible, have it transmitted directly to another controller (right to data portability);

  • Withdraw your consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal.
     

📧 You can exercise Your rights at any time by contacting us at: legal.fr@accessiway.com.

🔗 If you are located in France and believe that the processing of your personal data violates applicable law, you have the right to lodge a complaint with the French Data Protection Authority (Commission Nationale de l’Informatique et des Libertés – CNIL) via the website: www.cnil.fr.

*If you have difficulty accessing our form, please feel free to contact us. Send an e-mail to info@accessiway.com

Quasi tutti i siti web hanno barriere digitali. Secondo il report WebAIM Million 2024, il 95,9% delle home page analizzate presentava almeno un errore WCAG rilevabile automaticamente. Questa guida spiega come rendere accessibile il tuo sito web: cosa correggere, da dove iniziare e come farlo nel modo giusto.

In questo articolo

  • Come rendere accessibile il tuo sito web

  • Quali criteri WCAG 2.1 AA sono più spesso violati?

  • Quali sono i 7 strumenti per testare l'accessibilità di un sito web?

  • Come si organizza il processo di rimediazione?

  • Come si testa l'accessibilità di un sito web?

  • Domande frequenti su come rendere un sito web accessibile

Come rendere accessibile il tuo sito web

Rendere un sito web accessibile significa intervenire su aree specifiche del codice, dei contenuti e del design. Queste sono le correzioni che risolvono la maggior parte delle barriere digitali.

1-Aggiungi il testo alternativo alle immagini

  • Ogni immagine informativa ha bisogno di un attributo alt che descriva cosa mostra e perché è lì, non come appare.

  • Per le immagini decorative (separatori, sfondi, icone puramente estetiche) usa alt="". Lo screen reader le salterà.

  • Per le immagini che fungono da link, l'alt deve descrivere la destinazione del link, non l'immagine stessa.

  • Il nome del file conta: audit-accessibilita-wcag.webp è indicizzabile e leggibile. IMG_2034.webp non dice nulla a nessuno.

Scarica la nostra guida rapida per scoprire come gestire correttamente gli alt text

2-Garantisci un contrasto di colore sufficiente

Testo grigio chiaro su sfondo bianco, link colorati su sfondi colorati, placeholder nei form con contrasto appena percettibile: sono tutti problemi misurabili con precisione.

Scarica la nostra guida rapida per correggere il contrasto dei colori

3-Rendi il sito navigabile da tastiera

Apri il sito, metti via il mouse e premi Tab. Se perdi il focus dopo pochi click, se alcuni elementi non sono raggiungibili, se un modal si apre e non riesci più a uscirne hai trovato dei problemi reali.

I punti critici più frequenti:

  1. outline:none nel CSS, usato per eliminare l'anello di focus per motivi estetici, senza sostituirlo con nulla di visibile. È uno degli errori più diffusi e più impattanti per chi naviga da tastiera.

  2. I modal e i dialog devono gestire il focus in modo esplicito: quando si aprono, il focus va dentro; mentre sono aperti, non deve uscire; quando si chiudono, il focus torna all'elemento che li ha aperti.

  3. I componenti custom dropdown, accordion, slider richiedono spesso un'implementazione ARIA specifica per essere usabili da screen reader. Testali tutti, con uno screen reader reale.

4-Etichetta correttamente i campi dei form

  • Il placeholder non è un'etichetta. Scompare non appena si inizia a digitare, non viene letto in modo uniforme da tutti gli screen reader, e non supera i requisiti WCAG. Ogni campo (<input>, <select>, <textarea>) ha bisogno di un elemento <label> associato via for + id, oppure di un aria-label o aria-labelledby.

  • I messaggi di errore devono essere in testo, specifici ("Inserisci un indirizzo email valido, ad esempio nome@esempio.it") e programmaticamente collegati al campo tramite aria-describedby. Un bordo rosso non basta.

  • I campi correlati gruppi di checkbox, scelte multiple con radio button vanno raggruppati con <fieldset> e <legend>. Senza questa struttura, uno screen reader non riesce a comunicare il contesto del gruppo.

5-Scrivi testi dei link descrittivi

"Clicca qui", "scopri di più", "leggi l'articolo": queste ancore non dicono nulla a chi naviga con uno screen reader, perché i link vengono spesso letti in lista, fuori dal contesto della frase. Il testo del link deve descrivere la destinazione "Scarica le linee guida AgID in PDF" funziona. "Clicca qui" no.

Lo stesso vale per gli URL esposti come testo: un indirizzo web lungo trenta caratteri letto ad alta voce da NVDA non aiuta nessuno a capire dove va.

Basta poco tempo per rimediare: scarica la nostra guida per correggere il testo dei link

6-Rendi accessibili i contenuti multimediali

  • I video con audio hanno bisogno di sottotitoli sincronizzati (criterio 1.2.2). I sottotitoli automatici di YouTube senza revisione non sono affidabili.

  • Per i contenuti solo audio (podcast, registrazioni) serve una trascrizione testuale completa.

  • Per i video con contenuti visivi non descritti nell'audio, serve un'audio descrizione.

  • I PDF richiedono un trattamento separato: la PDF Solution Suite di Accessiway copre la rimediazione di documenti inaccessibili agli screen reader.

7-Controlla animazioni e contenuti in movimento

Il criterio 2.3.1 vieta elementi che lampeggiano più di tre volte al secondo.

Il criterio 2.2.2 richiede che qualsiasi contenuto in movimento avviato automaticamente e che duri più di cinque secondi possa essere messo in pausa, fermato o nascosto dall'utente.

Se il banner è indispensabile, aggiungi un controllo di pausa visibile e funzionante da tastiera.

8-Non affidarsi solo alla formattazione visiva

  • Gli screen reader non annunciano i cambiamenti di formattazione: grassetto e colore rosso non bastano.

  • Aggiungi sempre un'etichetta testuale: "Importante:", "Attenzione:", "Campo obbligatorio:".

  • Vale per gli stati di errore, i campi obbligatori nei form, le istruzioni critiche.

📋 La checklist completa Per portare tutti questi controlli in un unico documento operativo, abbiamo preparato una checklist con tutti i criteri WCAG 2.1 AA per l'accessibilità dei siti web. Organizzata per area di intervento e con note pratiche per il team.

Quali criteri WCAG 2.1 AA sono più spesso violati?

Le Linee Guida per l'Accessibilità dei Contenuti Web (WCAG) 2.1 AA sono lo standard tecnico internazionale che definisce cos'è un sito accessibile. Se vuoi prima un quadro generale, tutto quello che c'è da sapere sui siti web accessibili è un buon punto di partenza. In Italia, le Linee Guida AgID le recepiscono come obbligatorie per la Pubblica Amministrazione. L'Atto Europeo sull'Accessibilità (EAA) le estende al settore privato dal 28 giugno 2025. Per un approfondimento sui criteri tecnici, la pagina dedicata alle WCAG è il riferimento più diretto.

I criteri di livello AA sono 50. Questi sono i più frequentemente violati nei siti che analizziamo:

1.1.1 — ogni immagine informativa deve avere un alt text descrittivo

1.2.2 — i video con audio devono avere sottotitoli sincronizzati

1.3.3 — le istruzioni non devono fare riferimento solo a caratteristiche visive ("clicca il pulsante rosso")

1.4.3 — il rapporto di contrasto tra testo e sfondo: almeno 4,5:1 per testo normale, 3:1 per testo grande

1.4.4 — il testo deve essere leggibile al 200% di zoom senza perdita di contenuto

2.1.1 — tutte le funzionalità devono essere raggiungibili e usabili solo con la tastiera

2.3.1 — nessun elemento deve lampeggiare più di tre volte al secondo

2.4.4 — il testo dei link deve descrivere la destinazione, non l'azione ("leggi le linee guida WCAG", non "clicca qui")

2.4.7 — l'indicatore di focus deve essere visibile durante la navigazione da tastiera

3.3.2 — ogni campo di un form deve avere un'etichetta associata programmaticamente

4.1.2 — tutti gli elementi interattivi devono avere nome e ruolo leggibili dagli screen reader

Una nota sul futuro dello standard: i criteri di riferimento oggi sono quelli WCAG 2.1 AA, recepiti da EN 301 549 v3.2.1, lo standard armonizzato attualmente in vigore per EAA e Direttiva europea sull'accessibilità web. È tuttavia previsto che EN 301 549 v4.1.1, che incorporerà WCAG 2.2, venga pubblicato nella Gazzetta Ufficiale dell'UE intorno a ottobre 2026, diventando così il nuovo riferimento normativo. Se stai avviando un progetto di rimediazione oggi, orientarti già a WCAG 2.2 AA ti eviterà un secondo ciclo di audit quando lo standard verrà aggiornato.

Per un quadro completo, leggi l'articolo sugli errori più comuni nell'accessibilità dei siti web.

Quali sono i 7 strumenti per testare l'accessibilità di un sito web?

Non esiste uno strumento che trovi tutto. Usane più di uno.

Scansione automatica:

  • WAVE (wave.webaim.org) sovrappone gli errori direttamente alla pagina. Il formato più leggibile per chi non è sviluppatore.

  • Axe DevTools estensione browser con spiegazioni dettagliate e link ai criteri WCAG violati.

  • Lighthouse integrato in Chrome DevTools. Utile se già lo usi per altri audit tecnici.

Contrasto:

  • Colour Contrast Analyser di TPGi lo standard. Funziona offline, campiona qualsiasi colore direttamente dallo schermo, più preciso degli strumenti online per i casi limite.

Screen reader:

  • NVDA su Windows con Firefox la combinazione più usata in Italia.

  • VoiceOver su Mac con Safari.

  • TalkBack su Android con Chrome.

  • Testare con uno solo non basta: si comportano in modo diverso con lo stesso codice.

Tastiera:

Nessuno strumento necessario. Tab, Shift+Tab, Enter, Spazio, tasti freccia.

Annota ogni punto dove il focus scompare o dove non riesci ad attivare qualcosa.

Un sito che supera tutti i test automatici non è necessariamente accessibile. Un sito che una persona con disabilità riesce a usare senza frustrazioni, invece, lo è.

Come si organizza il processo di rimediazione?

La rimediazione è il lavoro di correzione che segue l'audit.

Il primo passo è il triage: classificare ogni problema per impatto sull'utente, frequenza (quante pagine o componenti coinvolge) e sforzo di correzione stimato. Gli errori critici su componenti riutilizzabili — header, footer, form globali, navigazione principale — vanno in cima. Corretti una volta, si propagano su tutto il sito.

Ogni correzione ha bisogno di un owner, una stima e una scadenza. Associa ogni ticket al criterio WCAG violato: ti servirà per compilare la Dichiarazione di Accessibilità e per dimostrare progressi nel tempo. Strumenti come Jira, Linear o GitHub Issues vanno benissimo, l'importante è che il tracciamento esista e sia condiviso tra design, sviluppo e QA.

Le correzioni di accessibilità si rompono facilmente con i deploy successivi. Documentare il comportamento atteso e integrare test di accessibilità nella pipeline CI/CD è quello che separa un progetto una tantum da una pratica stabile. Per i team che vogliono formazione interna su questi processi, l'Accessiway Academy offre percorsi strutturati per sviluppatori, designer e content team.

Come si testa l'accessibilità di un sito web?

Prima di correggere le barriere, è necessario trovarle. Il test di accessibilità si articola in tre fasi:

Fase 1: Scansione automatica: strumenti come WAVE, Axe DevTools o Lighthouse analizzano il codice in pochi secondi. Coprono circa il 30–40% delle barriere reali. Il servizio di Audit & Rimediazione di Accessiway combina scansione automatica e revisione umana per coprire entrambi i livelli.

Fase 2: Test manuali: naviga il sito solo con la tastiera e attiva uno screen reader. Focus che scompare, ordini di lettura illogici e modal che intrappolano la navigazione non compaiono in nessun report automatico.

Fase 3: Test con persone con disabilità: il test più utile in assoluto. Chi usa tecnologie assistive ogni giorno individua barriere che nessuno strumento può rilevare. Il servizio di User Testing di Accessiway struttura questa fase per i team che vogliono includere persone con disabilità nel processo di verifica in modo continuativo.

Per una guida completa su come verificare se il tuo sito è conforme alle WCAG 2.1, leggi: Come verificare se un sito web è accessibile e conforme alle WCAG 2.1

Domande frequenti su come rendere un sito web accessibile

Cos'è un sito web accessibile?

Un sito web accessibile è un sito che può essere utilizzato da tutte le persone, indipendentemente da disabilità visive, uditive, motorie o cognitive, e dalle tecnologie assistive che impiegano.

Quando un sito web può essere considerato accessibile?

Un sito web è accessibile quando rispetta i criteri WCAG 2.1 livello AA, lo standard richiesto da EAA, Legge Stanca e Linee Guida AgID. Ma la conformità tecnica non basta: un sito è davvero accessibile quando una persona con disabilità riesce a usarlo senza ostacoli, indipendentemente dalla tecnologia assistiva impiegata. Per i punti fondamentali da verificare, leggi i 10 punti fondamentali di un sito accessibile.

Quali sono i 4 principi dell'accessibilità web?

I quattro principi sono definiti dalle WCAG con l'acronimo POUR:

  • Percepibile — i contenuti devono essere presentati in modi che tutti gli utenti possano percepire, anche tramite tecnologie assistive.

  • Utilizzabile — tutte le funzionalità devono essere raggiungibili e attivabili, anche solo con la tastiera.

  • Comprensibile — i contenuti e il funzionamento dell'interfaccia devono essere chiari e prevedibili.

  • Robusto — il codice deve essere interpretabile correttamente da browser, screen reader e tecnologie assistive attuali e future.

Quanto costa rendere accessibile un sito web?

Dipende dallo stato attuale del sito, dalla sua dimensione e dalla tecnologia su cui è costruito. Un sito con pochi template e architettura coerente richiede un investimento contenuto, soprattutto se si parte dai componenti riutilizzabili. Un portale con decine di template e contenuto legacy ha costi e tempi più alti.

Come si redige la Dichiarazione di Accessibilità?

La Dichiarazione di Accessibilità è una pagina pubblica sul tuo sito in cui dichiari quanto è accessibile. Deve includere:

  • Stato di conformità — se il sito è conforme, parzialmente conforme o non conforme alle WCAG 2.1 AA

  • Barriere note — le problematiche di accessibilità ancora non risolte e le motivazioni

  • Alternative accessibili — eventuali soluzioni alternative per i contenuti non ancora accessibili

  • Contatto per segnalazioni — un canale per consentire agli utenti di segnalare problemi

  • Riferimento al meccanismo di enforcement — in Italia, AgID

Va pubblicata in una pagina dedicata del sito, con il link nel footer con la label "Dichiarazione di accessibilità", e aggiornata ogni anno entro il 23 settembre. Per la pubblica amministrazione la compilazione avviene esclusivamente sulla piattaforma form.agid.gov.it. I privati rientranti nell'ambito EAA seguono lo stesso modello, pubblicabile come pagina HTML sul proprio sito. Il modello ufficiale AgID è disponibile qui: Allegato 1 — Modello di Dichiarazione di Accessibilità.

Quanto tempo richiede una rimediazione?

Dipende dalle dimensioni del sito e da quante barriere esistono. Un sito con pochi template e architettura coerente può completare una prima rimediazione significativa in quattro-sei settimane. Un portale con decine di template e molto contenuto legacy può richiedere sei-dodici mesi. In entrambi i casi, iniziare dai componenti riutilizzabili è la scelta più efficiente: risolverli una volta significa correggere le stesse barriere su centinaia di pagine.

Qual è la differenza tra WCAG 2.1 AA e AAA?

Il livello AA è il riferimento normativo: è quello richiesto da EAA, Legge Stanca, AgID e dalla maggior parte delle normative europee. Il livello AAA è più restrittivo e include criteri non obbligatori per legge — sottotitoli per i contenuti registrati solo audio, linguaggio semplificato, audio descrizioni estese. Raggiungerlo su alcune funzionalità chiave è una scelta che ha senso per chi vuole andare oltre la conformità minima, ma non è un requisito.

Come posso verificare e migliorare l'accessibilità del sito aziendale in modo automatico?

Strumenti come Axe DevTools, WAVE o Lighthouse analizzano singole pagine in secondi e trovano circa il 30% delle violazioni WCAG. Per un sito aziendale con molte pagine e release frequenti serve un monitoraggio continuo che rilevi le regressioni dopo ogni deploy, classifichi i problemi per gravità e li assegni al team. Una piattaforma di accessibilità digitale automatizza questo processo, mentre flussi complessi e PDF richiedono in più audit manuali condotti da esperti.

Se stai organizzando il percorso di rimediazione per il tuo sito, la piattaforma Accessiway combina scansione automatica e competenza umana per mappare le barriere, assegnarle per priorità e monitorare i progressi. Puoi iniziare con un audit gratuito su accessiway.com per avere un quadro iniziale dello stato del sito.


Prenota una demo

Redazione

Il vibe coding sta cambiando lo sviluppo software. Insieme alla velocità, però, porta con sé un problema che pochi stanno ancora misurando: il codice generato dall'AI, lasciato a se stesso, produce molto spesso interfacce che escludono le persone con disabilità.

Accessibilita Digitale

Leggi l'articolo

Redazione

Cos'è il testo alternativo delle immagini, come funziona per gli screen reader, come scriverlo bene e quando lasciarlo vuoto.

Accessibilita Digitale

Leggi l'articolo

Robot androide con delle lettere dell'alfabeto che escono dalla sua testa

Author

Ecco come l'intelligenza artificiale può aiutare l'accessibilità web

Accessibilita Digitale

Leggi l'articolo

Related Articles

bottom of page