Dichiarazione di accessibilità: obiettivo WCAG 2.1 AA + eccezioni
Dichiarazione di accessibilità in parole chiare: obiettivo WCAG 2.1 AA, pipeline axe-core + Lighthouse, una sola eccezione documentata sul colore del marchio. Segnala una barriera.
La maggior parte delle dichiarazioni di accessibilità in questo giro o mente apertamente ("conformità WCAG AA al 100%!") oppure incolla un testo standard che seppellisce ogni eccezione nota dietro una cortina di gergo sulla conformità. Questa è più corta, organizzata intorno a quello che ti serve davvero sapere, e onesta sull'unica eccezione documentata che accettiamo. L'ho scritta così come l'avrei voluta io, se fossi stata dall'altra parte a leggerla.
bestgirlfriend.ai è un comparatore editoriale che si occupa di app di fidanzata virtuale IA, app di fidanzato virtuale IA, siti di cam, creator di modelle reali e giochi per adulti. L'accessibilità fa parte della base editoriale, non è una funzione aggiunta al lancio. Questa pagina documenta gli standard a cui costruiamo, le tecniche che usiamo, l'unica eccezione che accettiamo e il perché, le lacune che ancora dobbiamo colmare e il canale per segnalare una barriera.
Questa dichiarazione si allinea alla Section 508 statunitense (29 U.S.C. §794d, armonizzata con le WCAG 2.0 AA tramite l'ICT Refresh del 2018), allo standard europeo armonizzato EN 301 549 v3.2.1 (richiamato dalla Direttiva sull'accessibilità del web 2016/2102 e dall'European Accessibility Act 2019/882, in vigore dal 28 giugno 2025), alle Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 del Regno Unito e all'Accessibility for Ontarians with Disabilities Act, 2005 con il suo Integrated Accessibility Standards Regulation. Siamo un editore privato, non un ente pubblico, ma ci teniamo allo stesso livello di conformità perché la soglia di legge è il punto di partenza giusto.
bestgirlfriend.ai è conforme alle WCAG?
Puntiamo alle WCAG 2.1 livello AA su ogni pagina pubblica e rispettiamo l'obiettivo su tutti i criteri di successo tranne una sola eccezione documentata: il colore del marchio #E94B6A su crema #FAF7F2 dà un contrasto di 3,46:1, sotto la soglia AA di 4,5:1 per il testo del corpo. Il corallo è limitato a pulsanti, badge, link e accenti decorativi (la superficie 3:1 secondo WCAG 1.4.11), mai usato per la prosa del corpo. Tutti gli altri criteri di successo sono rispettati, e l'eccezione è registrata con le sue misurazioni nel nostro sistema di design.
Ultima revisione: 2026
La conformità è una cosa che continui a fare, non una casella che spunti una volta sola. Il sito è costruito sulle WCAG 2.1 AA, i quattro principi (percepibile, utilizzabile, comprensibile, robusto) sono integrati nel modo in cui le pagine sono progettate, e ogni commit supera i controlli automatici prima del merge. L'unico compromesso che accettiamo è il contrasto sull'accento corallo del marchio, e lo diciamo in apertura invece di nasconderlo in una nota a piè di pagina sulla conformità parziale. Il resto di questa pagina documenta cosa significa, in concreto.
Quali standard seguiamo?
Le WCAG 2.1 livello AA sono il nostro obiettivo tecnico. Sono richiamate dalla Section 508 statunitense (ICT Refresh 2018), dallo standard armonizzato europeo EN 301 549 v3.2.1, dalla Direttiva UE sull'accessibilità del web 2016/2102, dall'European Accessibility Act 2019/882 (in vigore dal 28 giugno 2025), dalle Public Sector Bodies Accessibility Regulations 2018 del Regno Unito e dall'Integrated Accessibility Standards Regulation dell'AODA dell'Ontario.
Le WCAG 2.1 AA sono la lingua franca globale dell'accessibilità digitale [Source: W3C, Linee guida per l'accessibilità dei contenuti web 2.1, Raccomandazione W3C 5 giugno 2018 · verified 2026-05-26]. La Section 508 le richiama tramite l'ICT Refresh statunitense [Source: U.S. Section 508, standard ICT Refresh · verified 2026-05-26]. La EN 301 549 le richiama come standard europeo armonizzato [Source: ETSI EN 301 549, requisiti di accessibilità per prodotti e servizi ICT · verified 2026-05-26]. Le norme britanniche del 2018 le citano esplicitamente. L'AODA le richiama tramite l'Integrated Accessibility Standards Regulation.
Scegliere il livello AA vuol dire soddisfare tutti e cinque i regimi da un unico obiettivo tecnico. Teniamo d'occhio le WCAG 2.2 (pubblicate a ottobre 2023) e ne integriamo i criteri di successo dove non confliggono con le 2.1. Sposteremo la nostra dichiarazione pubblica di conformità alle 2.2 AA quando gli standard sugli appalti nei nostri mercati chiave le citeranno.
Il panorama degli standard converge sulle WCAG 2.1 AA come obiettivo tecnico verificabile. I cinque regimi che governano i nostri mercati, ciascuno collegato al riferimento canonico:
| Standard | Regione | Livello di conformità | Il nostro stato | Riferimento |
|---|---|---|---|---|
| WCAG 2.1 AA | Globale (W3C) | Livello AA | Obiettivo (1 eccezione documentata) | Raccomandazione W3C, 5 giugno 2018 |
| EN 301 549 v3.2.1 | Unione Europea | Standard armonizzato, AA | Obiettivo (1 eccezione documentata) | ETSI, marzo 2021; richiamato da WAD 2016/2102 ed EAA 2019/882 |
| Section 508 (ICT Refresh) | Stati Uniti | WCAG 2.0 AA armonizzata; AA | Obiettivo (con il delta WCAG 2.1 AA, 1 eccezione documentata) | 36 CFR Part 1194, U.S. Access Board 2018 |
| UK Public Sector Bodies Accessibility Regulations 2018 | Regno Unito | WCAG 2.1 AA | Obiettivo (editore privato; volontario) | SI 2018/952 |
| AODA / IASR | Ontario, Canada | WCAG 2.0 AA (IASR §14) | Obiettivo (con il delta WCAG 2.1 AA, 1 eccezione documentata) | O. Reg. 191/11, Integrated Accessibility Standards |
Quali sono le eccezioni note all'accessibilità?
Due. (1) Eccezione sul contrasto del colore del marchio: il corallo #E94B6A su crema #FAF7F2 dà 3,46:1, sotto la soglia WCAG AA di 4,5:1 per il testo del corpo. Il corallo è limitato a pulsanti, badge, link e accenti decorativi (la superficie 3:1 secondo WCAG 1.4.11), mai usato per la prosa del corpo. (2) Le immagini di condivisione Open Graph su alcune pagine elenco non hanno un testo alternativo descrittivo per i lettori di schermo quando appaiono nelle anteprime social di terze parti (problema estetico; in correzione). Il chatbot AI Concierge non ha ancora completato il suo audit completo e non verrà pubblicato finché non lo fa.
Elencare in pubblico le eccezioni note è la controparte onesta di una dichiarazione di conformità. La conformità WCAG è binaria a livello del singolo criterio di successo: una pagina o rispetta il criterio o no. Non mescoliamo una clausola di conformità parziale nel corpo della pagina; le eccezioni stanno qui, in parole chiare, con la loro motivazione e lo stato della correzione.
L'eccezione sul colore del marchio, nel dettaglio. Il nostro colore d'accento principale (#E94B6A, il corallo su pulsanti e badge) sullo sfondo editoriale (#FAF7F2, il crema caldo) dà un rapporto di contrasto di 3,46:1. Le WCAG 2.1 AA richiedono 4,5:1 per il testo normale del corpo (SC 1.4.3) e 3:1 per il testo grande, gli elementi di interfaccia e gli oggetti grafici (SC 1.4.11). Il rapporto di 3,46:1 soddisfa la soglia di 3:1 per la superficie di interfaccia e testo grande, e non arriva alla soglia di 4,5:1 per la prosa del corpo.
Abbiamo deciso di accettare il compromesso solo per la superficie d'accento del marchio. Il corallo appare sui pulsanti call-to-action, sulle sottolineature dei link, sui badge, sulla barra promozionale fissa e sugli accenti decorativi, tutte superfici dove vale la soglia di 3:1. La prosa del corpo, le intestazioni e ogni altro testo usano il quasi-nero #1A1A1A sul crema, che supera comodamente il 4,5:1. La decisione è documentata nel nostro sistema di design insieme alle misurazioni di contrasto, così il compromesso è verificabile e non invisibile.
La maggior parte dei siti di recensioni di questo giro un compromesso del genere sul marchio non lo dichiara affatto. Dichiarano piena conformità AA, e l'audit non coglie mai la falla sul colore d'accento perché l'audit non l'hanno mai fatto. Noi l'audit lo facciamo, registriamo il risultato e te lo diciamo. È questa la differenza tra una vera dichiarazione di accessibilità e un testo standard copiato e incollato.
Problemi aperti:
| ID | Problema | Gravità | Stato | Correzione prevista |
|---|---|---|---|---|
| A11Y-001 | Colore del marchio (#E94B6A) su crema (#FAF7F2) = 3,46:1, sotto la soglia AA di 4,5:1 per il testo del corpo | Eccezione accettata (solo interfaccia/accento; la prosa del corpo non è toccata) | Documentato nei token di design | Nessuna correzione prevista senza un cambio di colore del marchio |
| A11Y-002 | Testo alternativo delle immagini Open Graph nelle anteprime social delle pagine elenco | Estetico (non influisce sulla lettura sul sito) | In correzione | T3 2026 |
| A11Y-003 | Audit completo WCAG 2.1 AA del chatbot AI Concierge | Bloccante (il chatbot non verrà pubblicato finché non è risolto) | Audit in attesa prima della pubblicazione | Prima della pubblicazione |
Se incontri un problema che non è in questa lista, segnalalo. La lista viene aggiornata ogni volta che scopriamo un problema nuovo o ne chiudiamo uno esistente.
Come segnalo un problema di accessibilità?
Scrivi a [email protected] con l'URL della pagina, il tuo browser e la tua tecnologia assistiva, e una breve descrizione della barriera. Confermiamo ogni segnalazione entro 2 giorni lavorativi e puntiamo a una risoluzione o a una soluzione alternativa entro 7 giorni lavorativi per i problemi bloccanti. I problemi che non possono rientrare nell'obiettivo dei 7 giorni ricevono una mitigazione provvisoria pubblica più una data di correzione prevista nel registro dei problemi noti su questa pagina.
La casella dedicata è [email protected]. Per aiutarci a riprodurre e correggere più in fretta, includi dove possibile:
- L'URL della pagina dove hai incontrato la barriera.
- Il tuo sistema operativo e il browser (con versione).
- La tecnologia assistiva che hai usato (lettore di schermo, switch, ingranditore, controllo vocale, ecc.) e la sua versione.
- Una breve descrizione di cosa ti aspettavi e di cosa è successo invece.
- Uno screenshot o una registrazione dello schermo, se ce l'hai e ti va di condividerli.
Puoi anche chiedere questa dichiarazione, un riassunto dell'audit o una correzione specifica in un formato alternativo (stampa a caratteri grandi, email in solo testo, una richiamata telefonica) scrivendo allo stesso indirizzo. Questi dati non ci servono per indagare; servono solo ad aiutarci a riprodurre il problema.
Il tempo di risposta è volontario ed è pubblicato qui proprio per poter essere verificato. Se sforiamo la conferma di 2 giorni o l'obiettivo di 7 giorni su un problema bloccante, quello stesso ritardo è una falla documentata e la documenteremo su questa pagina. Le vie di ricorso previste dalla legge, per esempio i reclami alla UK Equality and Human Rights Commission, alla linea ADA del Dipartimento di Giustizia statunitense, o al tuo equivalente nazionale, restano disponibili a prescindere da come gestiamo la segnalazione internamente.
E il supporto ai lettori di schermo?
Testiamo con NVDA e JAWS su Windows, VoiceOver su macOS e iOS, e TalkBack su Android. Intestazioni, punti di riferimento ed elenchi vengono annunciati correttamente. I campi dei moduli hanno etichette sia visibili sia programmatiche. Le icone decorative usano alt vuoto o aria-hidden. Le immagini editoriali hanno un testo alternativo scritto dai redattori, non dagli sviluppatori, così l'alt riflette l'intento.
I lettori di schermo non vedono quello che vede chi ha la vista; leggono l'albero del documento. Per questo è l'HTML semantico, non l'ARIA, a reggere il primo peso dell'accessibilità qui da noi. L'ARIA la aggiungiamo solo dove la semantica HTML nativa non basta (live region sui contenuti dinamici, ruoli dialog sulle modali, stati expanded sui widget a comparsa), secondo la prima regola dell'ARIA: se un elemento nativo fornisce la semantica, usalo. La copertura dei lettori di schermo viene ritestata a ogni release importante, e teniamo le trascrizioni dei test in archivio.
Come è supportata la navigazione da tastiera?
Ogni elemento interattivo è azionabile da tastiera. Un link salta-al-contenuto-principale è il primo elemento attivabile su ogni pagina. L'ordine di tabulazione segue l'ordine di lettura visivo. Gli indicatori di focus rispettano il contrasto 3:1 in modalità chiara e scura. Il menu a tendina mobile e la finestra delle lingue intrappolano il focus quando sono aperti e lo restituiscono alla chiusura, così chi usa solo la tastiera non resta mai bloccato.
Il contratto della tastiera è la superficie che testiamo più a fondo, perché fa da sostituta per ogni tecnologia assistiva che emula una tastiera, inclusi gli switch e le tastiere a schermo. I link di salto soddisfano la WCAG 2.4.1 Bypass Blocks, gli indicatori di focus visibili soddisfano la WCAG 2.4.7 Focus Visible, e la regola del nessun-blocco-da-tastiera soddisfa la WCAG 2.1.2. Il comportamento del focus-trap sulle modali segue il pattern dialog della W3C ARIA Authoring Practices Guide, con il focus restituito all'elemento che ha aperto la modale alla chiusura.
Quali funzioni di accessibilità sono integrate?
Le funzioni integrate includono HTML semantico (header, nav, main, footer, article, aside), gerarchia rigorosa delle intestazioni con un solo H1 per pagina, testo alternativo descrittivo sulle illustrazioni editoriali, immagini decorative marcate con alt="", didascalie delle tabelle con intestazioni di ambito, trascrizioni su ogni video incorporato, supporto a prefers-reduced-motion e indicatori di focus visibili con contrasto 3:1 sia nel tema chiaro sia in quello scuro.
L'inventario completo delle funzioni, mappato sul criterio di successo WCAG che lo regge:
- Punti di riferimento semantici (
<header>,<nav>,<main>,<footer>,<article>,<aside>), WCAG 1.3.1 Info e relazioni. - Un solo H1 per pagina, gerarchia rigorosa H2/H3, nessun livello saltato, WCAG 2.4.6 Intestazioni ed etichette.
- Salta-al-contenuto-principale come primo elemento attivabile, WCAG 2.4.1.
- Testo alternativo descrittivo scritto dalla redazione, non generato in automatico; le immagini decorative usano
alt="", WCAG 1.1.1 Contenuti non testuali. - Le tabelle hanno
<caption>e<th scope="col" | "row">, WCAG 1.3.1. - I video incorporati usano
youtube-nocookie.com, arrivano con trascrizioni sulla pagina, non partono mai da soli, WCAG 1.2.1, 1.2.2, 1.2.3. - Movimento ridotto:
@media (prefers-reduced-motion: reduce)disattiva parallasse, caroselli a scorrimento automatico e transizioni decorative, WCAG 2.3.3 Animazione dalle interazioni. - Contrasto dei colori: 4,5:1 per il corpo, 3:1 per il testo grande e l'interfaccia in entrambe le modalità (WCAG 1.4.3 Contrasto minimo, 1.4.11 Contrasto non testuale), con l'unica eccezione documentata sull'accento del marchio segnalata sopra.
- Nessun significato affidato al solo colore, WCAG 1.4.1 Uso del colore.
- Ridimensionamento del testo fino al 200% senza perdita di contenuto, WCAG 1.4.4.
- Riflusso a 320 pixel CSS senza scorrimento orizzontale, WCAG 1.4.10.
- Etichette dei moduli, identificazione e suggerimento degli errori, WCAG 1.3.1, 3.3.1, 3.3.3.
- I titoli di pagina descrivono argomento o scopo, WCAG 2.4.2.
- La lingua della pagina è dichiarata tramite l'attributo
langdell'elemento HTML radice; le sostituzioni per sezione tramite attributilanginline, WCAG 3.1.1, 3.1.2.
Come è gestito il testo da destra a sinistra?
Le pagine in arabo (ar) ed ebraico (he-IL) sono rese con layout da destra a sinistra tramite proprietà logiche CSS (margin-inline-start, padding-inline-end) invece di valori fissi destra/sinistra. Ogni componente, compresi header, navigazione, call-to-action, footer, barra mobile fissa e finestre modali, si rispecchia correttamente. Abbiamo testato a fondo l'intera struttura su un template AR dedicato prima del lancio e abbiamo documentato il risultato nel nostro sistema di design.
Il supporto al da destra a sinistra non è una questione di traduzione; è una questione di layout. Cambiare l'attributo dir del documento in "rtl" ribalta inizio e fine inline su tutto il layout, perché ogni spaziatura, allineamento e float è espresso in proprietà logiche. I contenuti bidirezionali (URL in caratteri latini dentro prosa araba, per esempio) sono racchiusi in elementi HTML <bdi> così che l'algoritmo bidirezionale renda in modo prevedibile. Teniamo un audit completo del da destra a sinistra su una pagina di test araba dedicata e lo rieseguiamo prima di ogni release.
Come interagisce la modalità scura con l'accessibilità?
La modalità scura è un interruttore manuale nell'header e rispetta prefers-color-scheme alla prima visita. Il testo del corpo resta a 4,5:1 o più alto in entrambe le modalità; il testo grande e gli elementi di interfaccia restano sopra il 3:1 (con l'eccezione documentata sull'accento del marchio). Il colore non è mai l'unico veicolo del significato, così chi ha un deficit della visione dei colori o si trova in un ambiente monocromatico non perde nessuna informazione cambiando modalità.
Ultima revisione: 2026
La modalità scura è realizzata tramite un attributo data-theme="dark" sull'elemento radice del documento, che commuta le proprietà CSS personalizzate alla radice. L'interruttore conserva la scelta di chi naviga in localStorage, e se non ha scelto, seguiamo prefers-color-scheme. Entrambe le palette sono verificate in modo indipendente contro le soglie di contrasto WCAG 1.4.3 e 1.4.11. La modalità scura va oltre il gusto estetico. Le Apple Human Interface Guidelines e l'accessibilità di GOV.UK la riconoscono come un accomodamento per fotofobia, emicrania e condizioni di ipovisione, quindi la garanzia di contrasto vale in entrambe le direzioni.
I video sono trascritti?
Sì. Ogni video incorporato usa il dominio youtube-nocookie.com e arriva con una trascrizione scritta sulla pagina, sotto l'incorporamento. I sottotitoli sono attivi sulla sorgente YouTube. I video non partono da soli, non vanno in loop automatico e offrono comandi di pausa e stop. Dove i sottotitoli della sorgente mancano, aggiungiamo una trascrizione manuale prima della pubblicazione.
Le trascrizioni qui non sono facoltative. Servono a chi è sordo o ipoudente (il pubblico per cui sono scritte), a chi legge in ambienti senza audio come l'ufficio o i mezzi, a chi sta imparando la lingua e si appoggia al testo che rinforza l'audio, e ai motori di ricerca e ai crawler IA che possono leggere il contenuto leggibile dalla macchina che i pixel del video non espongono. Un solo artefatto, quattro ritorni.
Come gestite il movimento ridotto?
Il sito rispetta la media query CSS prefers-reduced-motion. Quando chi naviga ha attivato il movimento ridotto a livello di sistema operativo, disattiviamo parallasse, caroselli a scorrimento automatico, animazioni che partono da sole e transizioni decorative. Il movimento essenziale dell'interfaccia (indicatori di focus, apertura dei menu) viene preservato perché trasmette uno stato. Niente sul sito lampeggia più di tre volte al secondo.
La soglia dei tre lampeggi soddisfa la WCAG 2.3.1 Tre lampeggi o sotto soglia, il criterio anti-crisi epilettiche. Il rispetto del movimento ridotto risponde ai disturbi vestibolari, alla nausea indotta dal movimento e ai bisogni di accessibilità legati all'attenzione documentati nella letteratura del W3C Cognitive Accessibility task force. L'implementazione è una sola media query, applicata al livello dei token di design; non serve nessun JavaScript perché la preferenza abbia effetto.
Quanto spesso facciamo i test?
A tempo di build: axe-core gira su ogni storia di componente e ogni snapshot di pagina nella CI. Le build falliscono in presenza di violazioni gravi o critiche. Prima del merge: le pull request hanno una soglia minima di 95 nel punteggio Lighthouse Accessibility e la GitHub Action blocca i merge sotto quella soglia. I passaggi manuali con lettore di schermo (NVDA, JAWS, VoiceOver, TalkBack) vengono fatti ogni trimestre su un set rappresentativo di pagine e all'occorrenza su ogni nuovo template.
Il testing è a strati: automatico dove lo strumento è affidabile, manuale dove gli esseri umani restano l'unico segnale che conta.
- A tempo di build:
axe-coregira su ogni storia di componente e ogni snapshot di pagina nella CI. Le build falliscono in presenza di violazioni gravi o critiche. - Prima del merge: le pull request hanno una soglia minima di 95 nel punteggio Lighthouse Accessibility e la GitHub Action blocca i merge sotto quella soglia.
- Passaggi manuali con lettore di schermo: NVDA, JAWS, VoiceOver (macOS + iOS), TalkBack, ogni trimestre su un set rappresentativo di pagine, all'occorrenza su ogni nuovo template.
- Passaggio solo-tastiera: ogni nuovo tipo di pagina viene navigato dall'inizio alla fine con la tastiera prima del merge, e il verbale del test viene archiviato insieme alla modifica.
- Audit dell'ordine di lettura: l'ordine di tabulazione viene confrontato con l'ordine di lettura visivo su ogni template.
- Simulazione del daltonismo: Sim Daltonism e il pannello di rendering di Chrome DevTools simulano protanopia, deuteranopia e tritanopia su ogni palette pubblicata. L'eccezione di contrasto sul colore del marchio è registrata qui.
- Feedback degli utenti reali: ogni barriera segnalata a
[email protected]viene aperta come ticket e tracciata pubblicamente nella tabella dei problemi noti su questa pagina.
La combinazione segue le linee guida sul testing di accessibilità di GOV.UK: gli strumenti automatici colgono all'incirca il 30-40% dei problemi, e il resto salta fuori solo quando le persone usano la tecnologia assistiva in condizioni reali.
Qual è il tempo di risposta sui reclami di accessibilità?
Confermiamo i reclami di accessibilità entro 2 giorni lavorativi all'indirizzo [email protected]. Per le barriere bloccanti (una funzione inutilizzabile con la tecnologia assistiva) puntiamo a risolvere entro 7 giorni lavorativi. I problemi non bloccanti ricevono una data di correzione documentata e restano nel registro dei problemi noti finché non sono chiusi. I diritti di ricorso previsti dalla legge restano disponibili al di sotto di questo impegno volontario.
L'impegno è volontario ed è pubblicato qui proprio per poter essere verificato. Se sforiamo la conferma di 2 giorni o l'obiettivo di 7 giorni su un problema bloccante, quello stesso ritardo è una falla documentata e la documenteremo su questa pagina. Le vie di ricorso previste dalla legge, per esempio i reclami alla UK Equality and Human Rights Commission, alla linea ADA del Dipartimento di Giustizia statunitense, o al tuo equivalente nazionale, restano disponibili a prescindere da come gestiamo la segnalazione internamente.
Come gestisce l'accessibilità il chatbot AI Concierge?
Il chatbot AI Concierge (in arrivo) non verrà pubblicato finché non supera un audit completo WCAG 2.1 AA che copra l'azionabilità da tastiera, gli annunci per lettore di schermo (live region per le risposte in streaming), la gestione del focus all'apertura e alla chiusura del pannello e il rispetto del movimento ridotto. Fino ad allora, tutti i contenuti editoriali sono raggiungibili senza il chatbot tramite gli accordion FAQ sulla pagina.
Le interfacce conversazionali mettono alla prova l'accessibilità in modi che le pagine statiche non conoscono. Il testo in streaming ha bisogno di live region ARIA discrete, il focus deve spostarsi in modo prevedibile tra il pulsante che apre, il pannello e la chiusura, chi usa la tastiera ha bisogno di una via di uscita documentata, e chi ha attivato il movimento ridotto ha bisogno che le sue preferenze siano rispettate sulla transizione del pannello. L'audit del Concierge seguirà il pattern dialog della W3C ARIA APG per il comportamento del pannello e le linee guida WAI-ARIA sulle live region per le risposte in streaming. Allegheremo a questa pagina la trascrizione completa dell'audit quando il chatbot verrà pubblicato.
Cosa sono la Section 508 e l'European Accessibility Act 2025?
La Section 508 dello U.S. Rehabilitation Act (29 U.S.C. §794d, ICT Refresh 2018) impone alle agenzie federali e ai loro fornitori di acquistare e mantenere tecnologie informatiche accessibili, armonizzate con le WCAG 2.0 AA tramite il 36 CFR Part 1194. L'European Accessibility Act (Direttiva 2019/882, in vigore dal 28 giugno 2025) estende gli obblighi di accessibilità a un'ampia gamma di prodotti e servizi del settore privato, anch'essi armonizzati alle WCAG 2.1 AA tramite la EN 301 549.
Entrambi i regimi convergono sullo stesso obiettivo tecnico. Per questo una sola postura di conformità soddisfa tutti e due, ed è per questo che scegliamo la soglia applicabile più alta (WCAG 2.1 AA tramite EN 301 549 v3.2.1) e la trattiamo come il pavimento su ogni pagina pubblica del sito, non solo sulle superfici toccate da contratti federali statunitensi o da obblighi di servizio UE.
La data di applicazione dell'EAA, il 28 giugno 2025, conta per gli editori privati come noi. È il momento in cui "dichiarazione di accessibilità sul sito" smette di essere una cortesia e diventa un artefatto verificabile dal regolatore negli Stati membri che hanno recepito la direttiva. Abbiamo pubblicato questa dichiarazione con largo anticipo su quella data, con l'unica eccezione documentata qui sopra, perché preferiamo affrontare ora la conversazione sul nostro compromesso di colore del marchio, piuttosto che sentircelo chiedere dopo.
Come citare questa pagina
Se citi questa dichiarazione in un lavoro accademico, normativo o giornalistico, cita così:
Joly, A. (2026). Dichiarazione di accessibilità: obiettivi WCAG 2.1 AA, eccezioni e segnalazioni per bestgirlfriend.ai. bestgirlfriend.ai. https://bestgirlfriend.ai/it/accessibility
Un riassunto leggibile dalla macchina è pubblicato su /llms.txt per l'ingestione da parte dei crawler della ricerca IA.
Domande frequenti
Ultima revisione: 2026.
bestgirlfriend.ai è conforme alle WCAG?
Puntiamo alle Linee guida per l'accessibilità dei contenuti web (WCAG) 2.1 livello AA su ogni pagina pubblica. Rispettiamo l'obiettivo su tutti i criteri di successo tranne una sola eccezione documentata: il nostro colore del marchio #E94B6A su crema #FAF7F2 dà un rapporto di contrasto di 3,46:1, sotto la soglia AA di 4,5:1 per il testo del corpo. Usiamo il colore del marchio solo per pulsanti, badge e accenti decorativi (trattati come testo grande e interfaccia secondo WCAG 1.4.11), mai per la prosa del corpo. Il nostro allineamento agli standard corrisponde alla Section 508 degli Stati Uniti, alla EN 301 549 dell'UE, alle Public Sector Bodies Accessibility Regulations 2018 del Regno Unito e all'AODA dell'Ontario.
Quali standard seguiamo?
Le WCAG 2.1 livello AA sono il nostro obiettivo tecnico. Sono richiamate dalla Section 508 statunitense (ICT Refresh 2018), dallo standard armonizzato europeo EN 301 549 v3.2.1, dalla Direttiva UE sull'accessibilità del web 2016/2102, dall'European Accessibility Act 2019/882 (in vigore dal 28 giugno 2025), dalle Public Sector Bodies Accessibility Regulations 2018 del Regno Unito e dall'Integrated Accessibility Standards Regulation dell'AODA dell'Ontario. Seguiamo i criteri di successo delle WCAG 2.2 come traguardo di compatibilità futura, ma la nostra dichiarazione pubblica di conformità resta sulle 2.1 AA finché le 2.2 non entreranno nelle leggi regionali sugli appalti.
Quali sono le eccezioni note all'accessibilità?
Due. (1) Eccezione sul colore del marchio: il corallo #E94B6A su crema #FAF7F2 dà 3,46:1, sotto la soglia AA di 4,5:1 per il testo del corpo. Limitiamo il corallo a pulsanti, badge, link e accenti decorativi (dove vale la soglia 3:1 per interfaccia e testo grande secondo WCAG 1.4.11), mai per la prosa del corpo; il compromesso è documentato nel nostro sistema di design. (2) Alcune immagini di condivisione Open Graph nelle pagine elenco non hanno un testo alternativo descrittivo per i lettori di schermo quando appaiono nelle anteprime social di terze parti (problema estetico; in correzione). Il chatbot non verrà pubblicato finché non supera un audit completo da tastiera e con lettore di schermo.
Come segnalo un problema di accessibilità?
Scrivi a [email protected] con l'URL della pagina, il tuo browser e la versione della tecnologia assistiva, e una breve descrizione della barriera. Confermiamo ogni segnalazione entro 2 giorni lavorativi. Per le barriere bloccanti (una funzione è inutilizzabile con la tecnologia assistiva) puntiamo a risolvere entro 7 giorni lavorativi. I problemi non bloccanti ricevono una data di correzione documentata e restano nella tabella dei problemi noti su questa pagina finché non sono chiusi. I diritti di ricorso previsti dalla legge restano comunque disponibili, a prescindere dal nostro impegno interno.
E il supporto ai lettori di schermo?
Testiamo con NVDA su Windows, JAWS su Windows, VoiceOver su macOS e iOS, e TalkBack su Android. Intestazioni, punti di riferimento ed elenchi vengono annunciati correttamente. I campi dei moduli hanno etichette sia visibili sia programmatiche. Le icone decorative usano alt vuoto o aria-hidden. Le immagini editoriali hanno un testo alternativo descrittivo scritto dai redattori, non dagli sviluppatori, così l'alt riflette l'intento. L'HTML semantico è la nostra prima linea di difesa; l'ARIA è aggiunto solo dove la semantica HTML nativa non basta, secondo la prima regola dell'ARIA.
Come è supportata la navigazione da tastiera?
Ogni elemento interattivo su bestgirlfriend.ai è azionabile da tastiera. Un link salta-al-contenuto-principale è il primo elemento attivabile su ogni pagina. L'ordine di tabulazione segue l'ordine di lettura visivo. Gli indicatori di focus hanno almeno 3:1 di contrasto sia in modalità chiara sia scura. Il menu a tendina mobile e la finestra delle lingue intrappolano il focus quando sono aperti e lo restituiscono alla chiusura, così chi usa solo la tastiera non resta mai bloccato. Il comportamento del focus-trap segue il pattern dialog della W3C ARIA Authoring Practices Guide.
Come è gestito il testo da destra a sinistra?
Le pagine in arabo (ar) ed ebraico (he-IL) sono rese con layout da destra a sinistra tramite proprietà logiche CSS (margin-inline-start, padding-inline-end) invece di valori fissi destra/sinistra. Ogni componente, compresi header, navigazione, call-to-action, footer, barra mobile fissa e finestre modali, si rispecchia correttamente. Abbiamo testato a fondo l'intera struttura su un template AR dedicato prima del lancio e abbiamo documentato il risultato nel nostro sistema di design.
Come interagisce la modalità scura con l'accessibilità?
La modalità scura è offerta come interruttore manuale nell'header e rispetta la preferenza di sistema prefers-color-scheme alla prima visita. Il contrasto del testo del corpo resta a 4,5:1 o più alto in entrambe le modalità sulla superficie di prosa. Il colore non è mai l'unico veicolo del significato, così chi ha un deficit della visione dei colori o si trova in un ambiente monocromatico non perde nessuna informazione cambiando modalità. L'eccezione di contrasto per l'accento corallo del marchio vale in entrambe le modalità.
I video sono trascritti?
Sì. Ogni video incorporato su bestgirlfriend.ai usa il dominio youtube-nocookie e arriva con una trascrizione scritta pubblicata direttamente sulla pagina sotto l'incorporamento. I sottotitoli sono attivi sulla sorgente YouTube. I video non partono da soli, non vanno in loop automatico e offrono comandi di pausa e stop. Dove i sottotitoli non sono disponibili dalla sorgente originale, aggiungiamo una trascrizione manuale prima della pubblicazione.
Come gestite il movimento ridotto?
Il sito rispetta la media query CSS prefers-reduced-motion. Quando chi naviga ha attivato il movimento ridotto a livello di sistema operativo, disattiviamo parallasse, caroselli a scorrimento automatico, animazioni che partono da sole e transizioni decorative. Il movimento essenziale dell'interfaccia (indicatori di focus, apertura dei menu) viene preservato perché trasmette uno stato. Niente sul sito lampeggia più di tre volte al secondo, e così rispettiamo il criterio anti-crisi epilettiche.
Quanto spesso facciamo i test?
axe-core gira su ogni storia di componente e ogni snapshot di pagina nella CI; le build falliscono in presenza di violazioni gravi o critiche. Le pull request hanno una soglia minima di 95 nel punteggio Lighthouse Accessibility e la GitHub Action blocca i merge sotto quella soglia. I passaggi manuali con lettore di schermo su NVDA, JAWS, VoiceOver e TalkBack vengono fatti ogni trimestre su un set rappresentativo di pagine e all'occorrenza su ogni nuovo template. Ogni nuovo template viene navigato da tastiera dall'inizio alla fine prima del merge.
Qual è il tempo di risposta sui reclami di accessibilità?
Confermiamo i reclami di accessibilità entro 2 giorni lavorativi all'indirizzo [email protected]. Per le barriere bloccanti (una funzione inutilizzabile con la tecnologia assistiva) puntiamo a risolvere entro 7 giorni lavorativi. I problemi non bloccanti ricevono una data di correzione documentata e restano nel registro dei problemi noti finché non sono chiusi. Chi legge nell'UE e nel Regno Unito mantiene i propri diritti di ricorso previsti dalla legge, a prescindere da come gestiamo la segnalazione internamente.
Come gestisce l'accessibilità il chatbot AI Concierge?
Il chatbot AI Concierge (in arrivo) non verrà pubblicato finché non supera un audit completo WCAG 2.1 AA che copra l'azionabilità da tastiera, gli annunci per lettore di schermo (live region per le risposte in streaming), la gestione del focus all'apertura e alla chiusura del pannello e il rispetto del movimento ridotto. Fino ad allora, tutti i contenuti editoriali sono accessibili senza il chatbot, e le risposte equivalenti sono raggiungibili tramite gli accordion FAQ sulla pagina. L'audit seguirà il pattern dialog della W3C ARIA APG per il comportamento del pannello e le linee guida WAI-ARIA sulle live region per le risposte in streaming.
Cosa sono la Section 508 e l'European Accessibility Act 2025?
La Section 508 dello U.S. Rehabilitation Act (29 U.S.C. §794d, ICT Refresh 2018) impone alle agenzie federali e ai loro fornitori di acquistare e mantenere tecnologie informatiche accessibili, armonizzate con le WCAG 2.0 AA tramite il 36 CFR Part 1194. L'European Accessibility Act (Direttiva 2019/882, in vigore dal 28 giugno 2025) estende gli obblighi di accessibilità a un'ampia gamma di prodotti e servizi del settore privato, anch'essi armonizzati alle WCAG 2.1 AA tramite la EN 301 549. Entrambi i regimi convergono sullo stesso obiettivo tecnico, ed è per questo che una sola postura di conformità soddisfa tutti e due.
Fonti
Gli standard, le norme e le linee guida citati su questa pagina sono elencati qui sotto nell'ordine in cui appaiono, con URL stabili. Riverificati nel 2026.
- [Source: W3C, Linee guida per l'accessibilità dei contenuti web (WCAG) 2.1, Raccomandazione W3C 5 giugno 2018 · verified 2026-05-26]
- [Source: W3C, Linee guida per l'accessibilità dei contenuti web (WCAG) 2.2, Raccomandazione W3C 5 ottobre 2023 · verified 2026-05-26]
- [Source: ETSI, EN 301 549 v3.2.1, Requisiti di accessibilità per prodotti e servizi ICT (marzo 2021) · verified 2026-05-26]
- [Source: Direttiva UE sull'accessibilità del web 2016/2102 · verified 2026-05-26]
- [Source: European Accessibility Act dell'UE, Direttiva 2019/882 (in vigore dal 28 giugno 2025) · verified 2026-05-26]
- [Source: U.S. Section 508 del Rehabilitation Act, ICT Refresh (2018) · verified 2026-05-26]
- [Source: UK Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (SI 2018/952) · verified 2026-05-26]
- [Source: Accessibility for Ontarians with Disabilities Act, 2005 (AODA) e Integrated Accessibility Standards Regulation O. Reg. 191/11 · verified 2026-05-26]
- [Source: GOV.UK Service Manual, Testing for accessibility · verified 2026-05-26]
- [Source: Apple Developer, Human Interface Guidelines, Accessibility · verified 2026-05-26]
- [Source: W3C ARIA Authoring Practices Guide, pattern Dialog (Modale) · verified 2026-05-26]
- [Source: Deque Systems, axe-core, motore open-source per il testing dell'accessibilità · verified 2026-05-26]
- [Source: Google Chrome Developers, punteggio Lighthouse Accessibility · verified 2026-05-26]
- [Source: WebAIM, ricerca sull'accessibilità e test con lettori di schermo · verified 2026-05-26]
Pagine editoriali di fiducia collegate
- Pagina della metodologia, gli standard editoriali dietro ogni voto su bestgirlfriend.ai.
- Processo editoriale, come scriviamo, verifichiamo e aggiorniamo le recensioni.
- Informativa sulla privacy, quali dati raccogliamo e i tuoi diritti secondo GDPR, CCPA e norme equivalenti.
- Termini di utilizzo, il contratto che regola il tuo uso del sito.
- Informativa sull'affiliazione, come guadagniamo e perché questo non influenza le classifiche.
- Chi è Alexandra Joly, il profilo della Senior Editor, le credenziali e il contatto diretto.
- Contatti, il canale di contatto generale per le richieste che non riguardano l'accessibilità.
Avviso per giurisdizione
Ultima verifica nel 2026 · Vedi il registro errata per eventuali correzioni post-pubblicazione · Redazione: Alexandra Joly · Metodologia · Processo editoriale · Informativa sull'affiliazione