In breve: per i negozi online, il testo chiave della normativa turca sull'accessibilità web è la circolare sull'accessibilità web (Circolare presidenziale 2025/10). Impone ai fornitori di servizi che svolgono attività di e-commerce ai sensi della legge n. 6563, la legge turca sul commercio elettronico, di rendere i propri siti web e le proprie app mobile conformi alla «Checklist – Livello A» del Ministero della Famiglia e dei Servizi sociali e alle WCAG 2.2 entro giugno 2027. La checklist traduce i 31 criteri di Livello A delle WCAG 2.2 in 126 domande, e ogni pagina web e ogni schermata dell'app viene valutata separatamente. La Direttiva attuativa (Yönerge) prevede una Commissione di revisione di almeno tre persone e una revisione in tre fasi: test automatici, test manuali e test con utenti con disabilità. La circolare non stabilisce sanzioni dirette. Tuttavia, i risultati del monitoraggio saranno resi pubblici e un servizio digitale non accessibile può diventare oggetto di un ricorso per discriminazione presso il TİHEK, l'organismo nazionale per i diritti umani e l'uguaglianza.
Abbiamo scritto questa guida per titolari, e-commerce manager e responsabili IT o di prodotto di aziende di vendita online che gestiscono un proprio negozio web o un'app iOS/Android. Si rivolge anche ai brand internazionali che vendono in Turchia o collaborano con partner e-commerce turchi. Le organizzazioni della prima fase, come banche e ospedali privati, il cui termine è scaduto a giugno 2026, possono seguire gli stessi passaggi. Non ci siamo basati su sintesi giornalistiche. Abbiamo letto direttamente la circolare, la checklist, la guida al logo, la Direttiva, le leggi pertinenti e le fonti del TİHEK e del W3C. Questo articolo non costituisce consulenza legale. Articolo aggiornato al 31 ottobre 2026.
Che cosa regola la normativa turca sull'accessibilità web? Quattro documenti ufficiali in una tabella
La base giuridica è la legge n. 5378 sulle persone con disabilità:
«Si garantisce che i servizi di informazione e le tecnologie dell'informazione e della comunicazione siano accessibili alle persone con disabilità.» (legge n. 5378, art. 7; traduzione nostra)
I dettagli sono definiti in quattro documenti:
| Documento | Che cosa regola? | Che cosa significa per l'e-commerce |
|---|---|---|
| Circolare 2025/10 (Resmî Gazete, Gazzetta Ufficiale turca, 21 giugno 2025) | Ambito e scadenze; Commissioni di monitoraggio, consultiva e di revisione; diritto d'uso del logo per 2 anni | Termine di 2 anni: giugno 2027 |
| Direttiva sulle procedure e i principi di attuazione (data di approvazione non indicata) | Commissioni, metodo di revisione, esenzioni, procedura per il logo | Una commissione di almeno 3 persone, test in tre fasi |
| Checklist – Livello A (V2.2.30.01, Ankara 2026) | I 31 criteri di Livello A delle WCAG 2.2, in 126 domande | Ogni pagina e ogni schermata dell'app viene valutata separatamente |
| Guida all'uso del logo di accessibilità (modificata il 14 aprile 2026) | Come si usa il logo su siti web e app mobile | Utilizzabile solo su siti e app che hanno ottenuto il diritto |
Due punti che spesso generano confusione:
- La Circolare 2026/1 non è un piano per il web. Il Piano di monitoraggio e ispezione contenuto in questa circolare, datata 21 gennaio 2026, riguarda solo edifici, spazi aperti e mezzi di trasporto pubblico. Al 31 ottobre 2026 non abbiamo trovato il Piano di monitoraggio previsto per web e mobile nelle pagine su accessibilità e normativa dell'EYHGM, la Direzione generale del Ministero per i servizi alle persone con disabilità e agli anziani. È presto per dire che «i controlli sull'e-commerce sono iniziati».
- Una guida alle WCAG 2.2 in turco non risulta ancora pubblicata. La guida annunciata nella circolare non compare nella pagina del Ministero dedicata all'accessibilità, e il W3C indica la traduzione autorizzata in turco come «prevista» (notifica di intenzione: 5 maggio 2026). Come riferimento utilizzi il testo inglese delle WCAG 2.2 del W3C.
Una nota sulla Direttiva: il Ministero elenca la Direttiva nella pagina Direttive (Yönergeler) dell'EYHGM. Il 31 ottobre 2026 il link al documento in quella pagina era vuoto, ma il testo in PDF è disponibile sul sito del Ministero. Il testo non riporta una data di approvazione; ai sensi dell'articolo 19, entra in vigore alla data in cui viene approvato. Le informazioni sulla Direttiva riportate di seguito si basano su questo testo: verifichi quindi eventuali aggiornamenti del Ministero.
Chi riguarda la circolare nell'e-commerce e sono previste sanzioni per chi non si adegua?
Ambito: chiunque abbia un proprio sito o una propria app
La circolare indica i fornitori di servizi che svolgono commercio elettronico ai sensi della legge n. 6563. Non fissa alcuna soglia dimensionale né esenzioni per le microimprese. Secondo la legge n. 6563, il fornitore di servizi è una persona fisica o giuridica che svolge attività di e-commerce, e l'ambiente di e-commerce è un sito web, un sito mobile o un'app mobile. Un brand con un proprio negozio o una propria app rientra chiaramente nell'ambito. Due situazioni sono poco chiare:
- Venditori presenti solo sui marketplace: la legge n. 6563 considera «fornitori di servizi di commercio elettronico» anche chi vende su un marketplace. Tuttavia, l'ambiente di vendita appartiene al marketplace e nessuna norma stabilisce come l'obbligo si applichi al venditore.
- Ditte individuali: la Direttiva definisce la commissione in termini di «istituzioni, organizzazioni e persone giuridiche» e di «almeno tre membri del personale», quindi non è chiaro come la norma si applichi a questi soggetti.
Su questi punti chieda un parere al Ministero o al suo consulente legale. Per le organizzazioni della prima fase, come banche, ospedali privati, istituti di istruzione privati e vettori di trasporto passeggeri, il termine di 1 anno è scaduto a giugno 2026.
Sanzioni: nessuna multa nella circolare, ma il rischio è altrove
- La circolare e la Direttiva non prevedono sanzioni amministrative. Tuttavia, il Ministro renderà pubblici i risultati del monitoraggio.
- Le sanzioni della legge n. 5378 non riguardano i siti web. Quelle dell'articolo transitorio 3 si riferiscono a edifici, spazi aperti e trasporto pubblico. La cifra di «5.000–25.000 lire turche per rilievo» citata in alcune guide è l'intervallo che questa disposizione fissa per comuni ed enti pubblici. Per le persone fisiche e le persone giuridiche di diritto privato, l'importo nominale nel testo di legge è da 1.000 a 5.000 lire turche per rilievo.
- La via del TİHEK è un rischio concreto. La legge n. 6701, che ha istituito il TİHEK, vieta la discriminazione fondata sulla disabilità e considera discriminazione la mancata adozione di accomodamenti ragionevoli. Si applica inoltre alle persone fisiche e alle persone giuridiche di diritto privato che offrono «servizi analoghi». La sanzione amministrativa prevista dall'articolo 25, comma 1, è da 17.052 a 256.357 lire turche nel 2026, e il Consiglio del TİHEK può convertirla una sola volta in un'ammonizione. Nella decisione 2024/403, il TİHEK ha accertato una violazione perché alcune parti dell'internet banking e del mobile banking di una banca non potevano essere lette con uno screen reader.
- Se vende a consumatori in Germania: il BFSG. Il BFSG è la legge tedesca che recepisce l'European Accessibility Act (direttiva (UE) 2019/882). Riguarda i servizi di e-commerce offerti ai consumatori dopo il 28 giugno 2025, e la sanzione per l'offerta di un servizio non conforme può arrivare a 100.000 euro. Sono esentate le microimprese che forniscono servizi, ossia quelle con meno di 10 dipendenti e un fatturato annuo o un totale di bilancio non superiore a 2 milioni di euro.
Come si legge la checklist di accessibilità (Livello A)?
La checklist 2026 del Ministero (V2.2.30.01) trasforma i 31 criteri di successo relativi ai quattro principi delle WCAG 2.2 in 126 domande numerate. Nel testo le indichiamo da D1 a D126. Esistono tre tipi di domanda:
- ★ (64 domande): condizione obbligatoria. Una risposta «No» significa che serve un intervento.
- ★★ (3 domande): condizione che non deve verificarsi. Una risposta «Sì» significa che serve un intervento: informazioni fornite solo tramite il colore (D52), lampeggiamenti oltre le soglie (D81) e cambio di contesto quando un componente riceve semplicemente il focus (D106).
- Senza stella (59 domande): instradamento. Per esempio, una domanda chiede se la pagina contiene un CAPTCHA, e la risposta indica a quale sezione passare.
La regola decisiva: alle domande si risponde separatamente per ogni pagina web e ogni schermata dell'app. In un negozio con migliaia di pagine prodotto, questo significa lavorare template per template: home page, categoria, scheda prodotto, carrello, fasi del checkout, account e pagine promozionali. Una correzione in un template si propaga a tutte le pagine che lo utilizzano. In base alla Direttiva, sarà la Commissione di monitoraggio a decidere come campionare le pagine durante il monitoraggio.
La checklist copre solo il Livello A. Contrasto del colore (1.4.3), focus visibile (2.4.7) e dimensione del target (2.5.8) sono criteri AA, quindi restano fuori dal minimo di legge. Le consigliamo comunque di integrarli fin dall'inizio nel suo design system: nell'analisi WebAIM 2026, il basso contrasto è l'errore più comune, rilevato sull'83,9% delle home page. La checklist non può essere riprodotta a fini commerciali, quindi ne spieghiamo la logica invece di copiare le domande. Scarichi la versione aggiornata dal sito del Ministero.
Che cosa richiede la Direttiva sull'accessibilità? Commissione, test, esenzioni e logo
Commissione di revisione: almeno tre persone del suo personale
Ai sensi dell'articolo 13 della Direttiva, ogni istituzione e persona giuridica soggetta a monitoraggio istituisce una Commissione di revisione (İnceleme Komisyonu) composta da almeno tre membri del personale, di cui almeno uno operativo nell'unità web/mobile. Il consiglio di alcune guide secondo cui «basta un team ristretto di due persone» contraddice l'articolo 13. Nell'anno in cui la sua azienda viene inserita nel Piano di monitoraggio (İzleme Planı), la commissione redige una Relazione di revisione nel formato previsto dal piano e la trasmette alla segreteria presso l'EYHGM. Segue inoltre le correzioni e prepara una relazione aggiornata per il rinnovo del logo.
Come si svolgono i test di accessibilità? Tre fasi
- Test automatici: con gli strumenti elencati sul sito del W3C. Al 31 ottobre 2026, l'elenco del W3C comprende 119 strumenti. Dispone di filtri per Android e iOS e include WAVE e axe DevTools (il W3C non avalla prodotti specifici).
- Test manuali: moduli, controlli dell'interfaccia, finestre di dialogo, conferme di inserimento dati, messaggi di errore, feedback, tastiera e contenuti non testuali come foto, video, CAPTCHA e audio.
- Test con utenti con disabilità: coinvolgendo utenti con disabilità visive (utenti di screen reader e ipovedenti), uditive (utenti sordi e ipoacusici) e motorie (uso limitato di mouse e tastiera). Sono inoltre raccomandati i test con utenti con disabilità cognitive, utenti nello spettro autistico, utenti con disturbi specifici dell'apprendimento e utenti daltonici.
Perché un overlay di accessibilità (plugin) non basta?
La checklist richiede che il collegamento tra etichette e campi dei moduli, così come la gerarchia dei titoli, sia definito «programmaticamente» nel codice. Richiede inoltre che la gestione del focus sia impostata correttamente. Un widget aggiunto a posteriori cerca di correggere questi aspetti nel browser per approssimazione. Può smettere di funzionare quando i template cambiano e non può in alcun modo raggiungere le schermate native iOS o Android. Nessuno dei quattro documenti contiene una disposizione che consideri un overlay come prova di conformità. In base alla Direttiva, i test manuali e i test con utenti con disabilità sono richiesti in ogni caso.
Tenga presenti anche i limiti dei test automatici. Secondo l'analisi WebAIM Million 2026, il 95,9% delle home page del primo milione di siti web presenta errori WCAG rilevati automaticamente. La media è di 56,1 errori per pagina, contro 66,2 nelle pagine in lingua turca e 71,0 nella categoria shopping. Una trappola da tastiera o un testo alternativo privo di significato, invece, di solito emergono solo quando sono le persone a testare il sito. Collegare i controlli automatici alla sua pipeline CI/CD aiuta a evitare che gli errori corretti si ripresentino nei nuovi rilasci.
Esenzioni: che cosa resta escluso?
- Contenuti aggiunti in modo dinamico e automatico da altre fonti: la Direttiva cita come esempi gli annunci dinamici e le recensioni d'acquisto. A essere esentato è il contenuto in sé, non il suo modulo di recensione o il componente di valutazione.
- Mappe online, purché le informazioni essenziali per la navigazione siano fornite in forma accessibile.
- Trasmissioni in diretta; tuttavia, la registrazione conservata sul sito deve essere resa accessibile entro 14 giorni.
- Video e audio registrati prima della circolare, e contenuti d'archivio che non vengono aggiornati entro un anno dall'entrata in vigore della circolare e non sono necessari per i processi amministrativi. Per i nuovi video di prodotto valgono le domande su sottotitoli, trascrizioni e audiodescrizione (D17–25).
L'interpretariato in lingua dei segni turca (TİD) non è obbligatorio per i contenuti video e audio. Se lo offre, l'interprete deve aver ottenuto almeno 70 punti all'esame di competenza TİD.
Come si ottiene il logo di accessibilità?
Non può aggiungere il logo di sua iniziativa. Può presentare domanda all'EYHGM per ottenere il diritto d'uso. La Commissione di monitoraggio concede il diritto per 2 anni, separatamente per i siti web accessibili e per le app accessibili su ciascun sistema operativo mobile. Per il rinnovo serve una Relazione di revisione aggiornata, conforme al Piano di monitoraggio in vigore. In base alla Guida, aggiornata il 14 aprile 2026, il logo può essere utilizzato solo sul sito o sull'app che ha ottenuto il diritto. Al clic deve portare alla pagina di verifica sul sito ufficiale dell'EYHGM e non può essere utilizzato per ricavarne un vantaggio commerciale.
Dalla vetrina al checkout: i problemi più comuni dei siti e-commerce
I componenti tipici di un negozio online e le relative domande della checklist (numerate come nella V2.2.30.01):
| Componente | Domande | Che cosa fare |
|---|---|---|
| Menu e blocchi ripetuti | D36–37, D65–66, D82–83 | Utilizzi <nav>. Un sottomenu che si apre con il mouse deve aprirsi anche da tastiera. Aggiunga un link «Vai al contenuto principale». |
| Slider e banner promozionale a scorrimento | D75–78 | Un pulsante di pausa per i movimenti automatici che durano più di 5 secondi. |
| Immagini di prodotto | D1–5 | Un alt significativo per le immagini che veicolano informazioni; alt="" per quelle decorative. |
| Selettore di colore e taglia | D16, D51–53 | Mostri lo stato selezionato o esaurito anche con il testo, non solo con il colore. Assegni a ogni campione di colore un nome accessibile («Blu navy»). |
| Filtri | D40–41, D107–108 | Raggruppi le opzioni con <fieldset> e <legend>. Se una selezione ricarica da sola la pagina, lo segnali in anticipo o aggiunga un pulsante «Applica». |
| Pulsanti +/− del carrello e pulsanti a icona | D15–16, D124–126 | Nomi accessibili come «Aumenta quantità» e «Aggiungi al carrello»; mantenga aggiornato programmaticamente il valore della quantità. |
| Anteprima rapida, banner dei cookie, pop-up | D61–64, D69–70 | Utilizzi role="dialog" nella finestra modale. Il focus deve spostarsi nella finestra, il tasto Esc deve chiuderla e, alla chiusura, il focus deve tornare al pulsante che l'ha aperta o a un altro punto logico. |
| Limiti di tempo della sessione e del carrello | D73–74 | Consenta agli utenti di disattivare il limite di tempo o di estenderlo ad almeno 10 volte la sua durata, oppure li avvisi almeno 20 secondi prima della scadenza e permetta loro di prolungarlo con una singola azione, almeno 10 volte. |
| Moduli | D38–39, D111–120 | Il testo segnaposto non sostituisce un'etichetta. Colleghi il testo di errore al relativo campo. Un asterisco senza spiegazione o il solo bordo rosso non bastano. |
| Indirizzo di consegna e di fatturazione | D121–122 | Un'opzione «L'indirizzo di fatturazione coincide con quello di consegna» e attributi autocomplete. |
| CAPTCHA | D10–12 | Un testo che ne spieghi lo scopo e un'alternativa che non dipenda da un solo senso. Un CAPTCHA solo visivo o solo audio non basta. |
| Assistenza live, FAQ, chatbot | D109–110 | Il link di aiuto nella stessa posizione prevedibile in ogni pagina. |
L'annuncio agli screen reader di un messaggio «Aggiunto al carrello» (WCAG 4.1.3) è un criterio AA e non figura nella checklist. Lo consigliamo comunque come prassi standard.
La fase di pagamento e 3D Secure
La schermata 3D Secure è di solito una pagina della banca o del provider di pagamento e Lei non può modificarne il contenuto. Sconsigliamo di affidarsi all'esenzione della Direttiva per i contenuti aggiunti automaticamente. Per questa esenzione la Direttiva cita esempi come annunci e recensioni d'acquisto e, a nostro avviso, un flusso di acquisto non rientra in questa descrizione. Rafforzi la parte che controlla direttamente:
- Assegni un
titlesignificativo all'iframe che contiene i campi di pagamento o la schermata 3DS. All'apertura sposti il focus al suo interno e, alla chiusura, sul messaggio di esito. - Testi con uno screen reader le pagine di esito positivo e di errore dopo il ritorno dal 3DS. In caso di errore, conservi i dati già inseriti dall'utente.
- Chieda al suo provider di pagamento informazioni scritte sull'accessibilità del modulo di pagamento e della schermata 3DS, e ne faccia un criterio al momento del rinnovo del contratto.
Per i dettagli sull'integrazione, consulti la nostra guida all'integrazione di POS virtuale (pagamento online con carta) e 3DS.
Accessibilità delle app mobile: equivalenti iOS, Android e React Native
La checklist cita API di piattaforma nei suoi esempi, e le sue app iOS e Android vengono valutate con le stesse domande, schermata per schermata. Equivalenti comuni:
| Esigenza (domanda) | Android | iOS | React Native |
|---|---|---|---|
| Nome accessibile (D3, D16) | contentDescription | accessibilityLabel | accessibilityLabel |
| Nascondere un elemento decorativo (D5) | importantForAccessibility="no" | isAccessibilityElement = false | aria-hidden={true} |
| Titolo (D28) | accessibilityHeading="true" | accessibilityTraits = .header | accessibilityRole="header" |
| Informazioni sull'elenco (D30) | CollectionInfo | accessibilityContainerType | role="list" |
| Finestra modale e focus (D62, D70) | accessibilityPaneTitle | accessibilityViewIsModal | accessibilityViewIsModal (solo iOS) |
| Un'azione al posto dello scorrimento o del trascinamento (D68, D96) | AccessibilityAction | accessibilityCustomActions | accessibilityActions |
| Compilazione automatica (D122) | autofillHints | textContentType | autoComplete |
In due punti della colonna React Native ci siamo discostati dagli esempi della checklist. «list» non è uno dei valori di accessibilityRole; il ruolo di elenco si imposta con role="list". Su Android, accessible={false} disattiva solo la possibilità di ricevere il focus; per nascondere un elemento decorativo agli screen reader su entrambe le piattaforme, utilizzi aria-hidden. La checklist non menziona Flutter; in questo caso le stesse informazioni si forniscono tramite le proprietà label, header, excludeSemantics e customSemanticsActions del widget Semantics. Aggiunga inoltre un pulsante alternativo per le azioni che funzionano solo con lo swipe, come la rimozione di un articolo dal carrello (D95–96), e un'alternativa con un interruttore di disattivazione per le funzioni basate sul movimento, come «agita per annullare» (D101–103). Colleghi i messaggi di errore al relativo campo (setError su Android). Poiché il diritto d'uso del logo viene concesso separatamente per ciascun sistema operativo mobile, pianifichi iOS e Android come prodotti distinti. Non definisca «accessibile» un'app prima di averla testata con VoiceOver e TalkBack. Descriviamo il nostro approccio allo sviluppo nativo nella pagina Sviluppo app mobile.
Una roadmap di 7 mesi verso giugno 2027, passo dopo passo
Una sequenza realistica per un team che parte a novembre 2026:
- Novembre 2026, organizzazione e inventario: costituisca la Commissione di revisione (almeno 3 persone, di cui una dell'unità web/mobile). Elenchi i template web e le schermate delle app e segnali a parte i componenti di terze parti, come gli strumenti di pagamento, per i cookie e di assistenza live.
- Dicembre 2026, misurazione di base: esegua una scansione automatica con gli strumenti dell'elenco W3C, poi percorra la checklist template per template. Trasformi i rilievi in un elenco di attività, partendo dalle voci ★★ e dal flusso di pagamento.
- Gennaio–marzo 2027, correzione dei componenti: corregga pulsanti, campi dei moduli, finestre modali, menu, slider e filtri nel design system e colleghi i test automatici alla pipeline CI.
- Marzo–aprile 2027, pagamento e app: pagamento e ritorno dal 3DS, banner dei cookie e widget di terze parti; correzioni iOS e Android.
- Aprile–maggio 2027, test manuali e test con utenti con disabilità: test con tastiera, VoiceOver e TalkBack; sessioni con utenti dei gruppi di disabilità indicati nella Direttiva; bozza della Relazione di revisione.
- Giugno 2027 e oltre: quando sarà pubblicato il Piano di monitoraggio per web e mobile, adatti la relazione al suo formato, valuti la richiesta del logo ed esegua test di regressione a ogni rilascio.
Punto decisionale: se utilizza un tema preconfezionato, alcune correzioni dipendono dai fornitori del tema e dei plugin. Richieda al fornitore un calendario scritto per l'accessibilità. Se non riesce a ottenerlo, valuti un cambio di tema o un web design su misura prima di marzo 2027. Con un design su misura, le correzioni si apportano nei componenti condivisi e si propagano a tutte le pagine che li utilizzano.
Come La aiuta Partnerfy
Risolviamo l'accessibilità alla fonte, non con un overlay. Per prima cosa facciamo l'inventario dei suoi template e delle schermate delle app e li analizziamo con gli strumenti dell'elenco W3C. Poi eseguiamo test manuali con tastiera, VoiceOver e TalkBack. Correggiamo i rilievi nei componenti del suo design system e nel codice nativo iOS, Android o React Native, e colleghiamo i controlli automatici alla sua pipeline CI. Per i test con utenti con disabilità, prepariamo gli scenari, la aiutiamo a pianificarli con associazioni e organizzazioni attive in questo campo e produciamo la documentazione tecnica per la relazione della sua Commissione di revisione. La partecipazione alla commissione e la valutazione legale restano a suo carico. Se desidera una prima valutazione della sua piattaforma e-commerce, ci contatti.
Fonti
- Resmî Gazete (Gazzetta Ufficiale turca): Circolare 2025/10 (21 giugno 2025, numero 32933), in turco
- Ministero della Famiglia e dei Servizi sociali: Checklist – Livello A (V2.2.30.01), in turco
- EYHGM: pagina Direttive e Direttiva sulle procedure e i principi di attuazione (PDF), in turco
- EYHGM: Guida all'uso del logo, Circolare 2026/1 e pagina sull'accessibilità, in turco
- Normativa: leggi n. 5378, 6701 e 6563, in turco
- TİHEK: sanzioni amministrative 2026 e comunicato stampa sulla Circolare 2025/10, in turco
- W3C: WCAG 2.2 e traduzioni delle WCAG
- W3C: elenco degli strumenti di valutazione dell'accessibilità web
- WebAIM: The WebAIM Million (2026)
- BFSG: § 1, § 2, § 3 e § 37, in tedesco
- React Native: Accessibility e Flutter: classe Semantics