Prima di scegliere un chatbot WordPress, chiedete prove di accessibilità per l’esatta interfaccia del prodotto, la versione valutata e il percorso del visitatore di cui avete bisogno. Confrontate poi la dichiarazione del fornitore con il tema, il posizionamento e i riscontri locali registrati. Tenete separati ambiti non supportati da prove, prove mancanti e difetti confermati. Un badge da solo non risponde a queste domande di acquisto.
Questa guida alla valutazione dei fornitori di chatbot WordPress accessibili offre una richiesta di prove, una matrice tra dichiarazioni e versioni e condizioni per decidere l’acquisto. Non valuta la conformità di un prodotto né fornisce una conclusione giuridica. Tutte le righe di esempio sono ipotetiche, non risultati di clienti.
Autore: Achla AI, organizzazione. Revisione: 14 ottobre 2026. Preparato con l’assistenza dell’IA usando standard ufficiali, documentazione dei fornitori e fonti di prodotto esaminate. La data di revisione non è una data di pubblicazione.
Una dichiarazione di accessibilità è il punto di partenza per decidere l’acquisto
Definite esplicitamente il percorso necessario prima di confrontare i fornitori. Per un widget di risposte pubbliche, il percorso potrebbe comprendere l’apertura dell’interfaccia, una domanda su un servizio, il collegamento a una pagina di supporto alla risposta e il ritorno al sito. Un rapporto sulla dashboard degli operatori non stabilisce, da solo, se l’interfaccia dei visitatori soddisfa i requisiti.
L’esigenza è concreta: una domanda nel forum WordPress, posta da una persona che lavora nell’istruzione superiore, chiede come completare da tastiera le azioni essenziali del chatbot. Questa domanda storica segnala un bisogno del pubblico, non un difetto di ogni plugin attuale.
La domanda di acquisto è quali prove supportino l’esperienza richiesta nella configurazione prevista. Definite il requisito prima della dimostrazione commerciale. Altrimenti una demo convincente potrebbe mostrare un tema, un posizionamento o un’interfaccia diversi da quelli che intendete acquistare.
Identificare prodotto, versione e contesto del sito dietro la dichiarazione
Chiedete al fornitore di identificare il componente coperto dalla dichiarazione: widget web pubblico, SDK mobile, interfaccia amministrativa o altro. Registrate versione o build quando disponibili, data della valutazione, versione dello standard e livello dichiarato. Il titolo di un rapporto e un logo familiare sono indizi utili, ma richiedono comunque un ambito preciso.
I requisiti WCAG per le dichiarazioni di conformità specificano data della dichiarazione, versione e URI delle linee guida, livello, pagine coperte e tecnologie su cui si fa affidamento. Le WCAG trattano anche pagine intere e processi completi. La dichiarazione su un componente non dimostra quindi la conformità dell’intero sito WordPress.
Tenete separati i metadati del fornitore dalla scheda di installazione. Il fornitore può valutare una versione del widget ospitato; voi dovete identificare anche tema, editor, posizionamento, personalizzazione del marchio e pagine pubbliche. Questi campi aggiuntivi costituiscono la scheda di acquisto proposta qui, non un nuovo requisito di certificazione W3C.
| Campo dell’ambito | Prove del fornitore | Configurazione prevista |
|---|---|---|
| Interfaccia del prodotto | Componente esatto valutato | Widget visitatori o altra interfaccia richiesta |
| Versione e data | Versione o build valutata e data del rapporto | Integrazione prevista e data di revisione |
| Standard | Versione, livello e ambito del rapporto | Requisito di valutazione dell’organizzazione |
| Contesto del sito ospitante | Ipotesi, prerequisiti ed esclusioni | Tema, editor, posizionamento e personalizzazione |
| Percorso | Pagine o attività valutate | URL pubblici e intero percorso necessario |
Se il fornitore non sa identificare la versione a cui si riferisce una dichiarazione, annotate «applicabilità alla versione sconosciuta». Non associate implicitamente il rapporto alla versione più recente.
Leggere date, eccezioni e interfacce nelle dichiarazioni dei fornitori
Le pagine attuali della categoria illustrano l’importanza di queste distinzioni. Gli esempi seguenti descrivono dichiarazioni dei fornitori osservate il 14 ottobre 2026; non sono giudizi indipendenti di conformità né una classifica.
La guida all’accessibilità di LiveChat dichiara WCAG 2.2 AA per il Chat Widget e rimanda a un VPAT. Distingue i colori predefiniti dalla verifica dei colori personalizzati e identifica una limitazione relativa agli elementi di richiamo visivo predefiniti. Chiedete il rapporto applicabile alla configurazione prevista, invece di estendere il titolo a ogni funzione visiva opzionale.
La FAQ Messenger di Intercom afferma che il Web Messenger è stato valutato a gennaio 2026 e descrive un supporto ampio alle WCAG 2.2 AA con alcune aree parzialmente supportate nel VPAT collegato. Distingue questa interfaccia dalla web app e dagli SDK mobili non valutati e avverte che combinazioni di colori personalizzate possono peggiorare l’accessibilità.
La pagina di accessibilità di Zendesk elenca rapporti distinti per prodotti diversi. Al momento di questa revisione, la voce del Web Widget di messaggistica riporta settembre 2025, mentre quella del Classic Web Widget riporta dicembre 2019. Scegliete il rapporto del prodotto effettivo, non il documento che compare per primo.
Una dichiarazione chiara delle eccezioni fornisce informazioni da valutare. Non rende automaticamente inadatto un fornitore: la decisione dipende dall’impatto dell’eccezione sul percorso richiesto e dalla disponibilità di una soluzione verificata.
Inviare una richiesta di prove circoscritta prima di scegliere il widget
Usate la stessa richiesta per tutti i fornitori, Achla compreso. Chiedete prove applicabili senza presumere che tutti offrano lo stesso formato di rapporto o che un documento mancante dimostri un prodotto inaccessibile.
- Identificate il prodotto esatto e il percorso del visitatore preso in considerazione.
- Richiedete valutazione datata, versione applicabile e standard con versione e livello.
- Chiedete ambito e metodo di valutazione, informazioni sul valutatore ed eccezioni note.
- Chiedete quali impostazioni o personalizzazioni del sito ospitante possano modificare il risultato.
- Concordate chi risolverà le domande aperte e quali prove serviranno per chiuderle.
Una richiesta pratica può dire: «Intendiamo usare il widget pubblico su queste pagine WordPress, con questo tema e posizionamento. Identificate la valutazione che copre questa interfaccia, la versione interessata, le esclusioni e le prove pertinenti a queste attività».
Allegate questa scheda alla richiesta:
| Prova richiesta | Cosa deve distinguere l’acquirente |
|---|---|
| Valutatore, date e metodi | Affermazione del fornitore o riscontri documentati della valutazione |
| Prodotto, build e ambito delle pagine | Versione applicabile o altro prodotto o rapporto storico |
| Browser e tecnologie assistive | Configurazione verificata o promessa non specificata |
| Ipotesi su tema, posizione e marchio | Impostazioni predefinite coperte o comportamento personalizzato del sito ospitante |
| Eccezioni e prerequisiti noti | Ambito supportato o attività richieste ancora irrisolte |
| Contatti del fornitore e del sito | Chi risponde sul prodotto e chi gestisce le modifiche del sito ospitante |
| Condizioni e registrazione della nuova verifica | Quali cambiamenti riaprono la decisione di acquisto |
Il modello W3C di rapporto di valutazione include ambito, valutatori, processo e riscontri, e rimanda a risorse aggiornate per la rendicontazione. La panoramica sulla valutazione di conformità spiega il rapporto tra valutazione e documento: generare un rapporto non esegue la valutazione. Chiedete i riscontri effettivi alla base del documento.
Separare dichiarazioni, osservazioni e prove mancanti
Una dichiarazione del fornitore descrive l’ambito che afferma di coprire. Un riscontro locale descrive quanto osservato da un valutatore in un ambiente specifico. Una condizione di acquisto descrive ciò che richiedete prima di scegliere o distribuire il prodotto. Mantenete visibili tutti e tre gli elementi.
| Registrazione | Dichiarazione del fornitore e fonte | Collegamento a versione o configurazione | Prova locale | Responsabile e condizione di acquisto |
|---|---|---|---|---|
| Copertura dell’interfaccia | Registrare dichiarazione esatta e data | Confermare che copra il widget pubblico | Non ancora valutato | L’acquirente richiede il rapporto applicabile |
| Marchio personalizzato | Registrare i limiti dichiarati per le personalizzazioni | Registrare tema, colori e posizione scelti | Registrare i riscontri o «non verificato» | Il responsabile del sito fornisce prove circoscritte |
| Percorso richiesto | Registrare ambito supportato ed eccezioni | Registrare pagine e versione del prodotto | Registrare esito e riferimento della prova | Il responsabile risolve eventuali impedimenti pertinenti |
| Versione modificata | Conservare la dichiarazione precedente | Registrare nuova versione e impostazioni cambiate | Nuova verifica in attesa | L’acquirente riapre le condizioni interessate |
Queste righe sono strutture decisionali da compilare, non valutazioni completate. Riempitele con documenti e osservazioni reali; non trasformate «non verificato» in un esito positivo.
Usate stati distinti. Prova mancante significa che non avete ottenuto la valutazione o il riscontro locale necessario. Fuori ambito significa che il materiale fornito riguarda un’altra interfaccia o configurazione. Disallineamento significa che prova e dichiarazione non descrivono la stessa versione o esigenza. Difetto confermato richiede un riscontro reale e riproducibile. Ogni stato richiede un passo successivo diverso.
Per esempio, un rapporto sull’interfaccia amministrativa fornito per un requisito del widget visitatori è fuori ambito. Una valutazione attuale del widget senza prove locali per il tema personalizzato lascia una lacuna nelle prove locali. Sono esempi ipotetici di classificazione, non accuse verso un fornitore specifico.
Nominare il responsabile del difetto e la condizione della nuova verifica
Rendete le responsabilità abbastanza concrete da consentire un intervento. Assegnate il comportamento del prodotto a un contatto identificato del fornitore, le modifiche al template o agli stili al manutentore del sito, i riscontri al valutatore e il giudizio di acquisto all’acquirente. Un difetto condiviso può coinvolgere più persone, ma una deve coordinare la decisione successiva.
Registrate attività interessata, riferimento della prova, versione pertinente e condizione di accettazione proposta. «Il fornitore migliorerà l’accessibilità» non è una condizione verificabile. Una condizione utile identifica il percorso prima bloccato che dovrà diventare utilizzabile nell’ambiente specificato e il revisore che ne registrerà l’esito.
Le indicazioni W3C sulle dichiarazioni di accessibilità raccomandano contatti, limitazioni note e ambienti testati. Questo favorisce una comunicazione trasparente; una dichiarazione di accessibilità non è di per sé una valutazione tecnica. Usatela per trovare il contatto corretto e confrontare i limiti dichiarati con il rapporto a supporto.
Riaprite le righe pertinenti della matrice quando cambiano una versione rilevante del widget, il tema, la posizione o una personalizzazione. Conservate le prove precedenti e aggiungete il nuovo risultato anziché riscrivere la storia. Una correzione promessa, una nota di versione o lo screenshot di una pagina non pertinente non chiudono una condizione di acquisto irrisolta.
Per le procedure pratiche con tastiera, screen reader e viewport, consultate la guida all’accessibilità della barra di ricerca. Questa scheda disciplina le prove del fornitore e le responsabilità di accettazione.
Decidere se valutare, chiedere prove, sospendere o rifiutare l’ambito
Scegliete un giudizio circoscritto e motivatelo:
- Valutare: le prove fornite riguardano l’interfaccia prevista e il lavoro residuo specifico del sito ha un responsabile.
- Chiedere prove: resta aperta una domanda rilevante su ambito, data, eccezione o valutazione.
- Sospendere: un impedimento confermato interessa un percorso necessario e la sua risoluzione non è ancora verificata.
- Rifiutare l’ambito proposto: non soddisfa un requisito necessario all’acquirente, oppure il fornitore non offre una configurazione appropriata e valutabile.
Sono raccomandazioni per l’acquisto, non un sistema di punteggio della conformità. Un supporto sconosciuto resta sconosciuto. Un prezzo interessante non deve eliminare silenziosamente un percorso necessario dalla decisione.
Registrate pagine, configurazione e prove usate per decidere. Una decisione di valutazione limitata non approva tutte le versioni future o ogni pagina del sito. Fate approvare l’ambito dall’acquirente e conservate le condizioni ancora aperte.
Applicare la stessa richiesta di prove ad Achla
Esaminate il connettore WordPress e la documentazione di installazione per definire interfaccia e posizione da valutare. Achla documenta risposte con fonti dai contenuti pubblici del sito e un connettore con una sola modalità globale di posizionamento. La documentazione esaminata non dimostra un audit WCAG di Achla, una dichiarazione di conformità o una compatibilità certificata con il vostro tema.
Usate la documentazione di risoluzione dei problemi per le domande sul comportamento documentato. Esaminate i piani attuali separatamente dalle prove di accessibilità. La panoramica sulla ricerca nel sito fornisce un contesto più ampio della categoria; non sostituisce un rapporto applicabile.
Se le risposte pubbliche con fonti corrispondono al compito, usate l’onboarding per esplorare il prodotto entro le condizioni di prova definite. Mantenete selezione, valutazione e futura approvazione del lancio come decisioni esplicite con il relativo responsabile.