Per molti negozi online, il passaggio al pagamento è la parte più vulnerabile del sito quando si tratta di accessibilità. Mentre le pagine dei prodotti spesso funzionano ancora ragionevolmente bene con uno screen reader, il processo si blocca non appena il cliente deve pagare: pulsanti senza etichetta chiara, messaggi di errore non annunciati, o un widget di pagamento di un fornitore esterno che non può essere utilizzato senza il mouse. Non è una coincidenza. Il passaggio al pagamento contiene gli elementi più dinamici dell'intero sito, e gli elementi dinamici sono proprio il punto in cui gli screen reader e la navigazione da tastiera si bloccano più facilmente.
Non si tratta di un piccolo dettaglio. Il passaggio di pagamento è soggetto agli stessi requisiti EN 301 549 del resto del sito, e questo passaggio viene completato da un utente nel momento preciso in cui vuole effettivamente acquistare qualcosa. Uno screen reader che si blocca lì esclude un cliente nel momento decisivo. Questo è anche il motivo per cui in axessia includiamo il passaggio di pagamento per impostazione predefinita nella scansione completa, e non solo nella scansione rapida gratuita delle pagine principali.
Dove le cose vanno male nella pratica
I problemi più comuni sono sorprendentemente ricorrenti. Un pulsante per "passaggio successivo" o "paga ora" che contiene solo un'icona senza testo che uno screen reader possa leggere. Un messaggio di errore relativo a un campo di codice postale compilato in modo errato che appare visivamente, ma non viene annunciato perché manca il collegamento tecnico appropriato. Un indicatore di avanzamento ("passaggio 2 di 3") che è visivamente chiaro ma rimane invisibile per uno screen reader. E il fornitore di pagamenti stesso: i widget iDEAL o carta di credito di terze parti sono spesso integrati in modo isolato e hanno il loro proprio livello di accessibilità, sul quale un negozio online ha poco controllo ma rimane comunque responsabile.
Anche l'ordine della messa a fuoco è un problema ricorrente. Dopo l'invio di un modulo con un errore, l'attenzione dell'utente dovrebbe passare al messaggio di errore. Se ciò non accade, chi utilizza la tastiera o uno screen reader rimane a cercare cosa sia andato storto, senza alcun punto di partenza.
Perché una scansione automatizzata non rileva pienamente questo
Una scansione automatizzata è brava a segnalare etichette mancanti, pulsanti vuoti e problemi strutturali nel codice sorgente. Ciò che una scansione non riesce a valutare bene è il comportamento: un messaggio di errore viene effettivamente annunciato ad alta voce, lo stato attivo si sposta logicamente, e il passaggio di pagamento rimane accessibile senza mouse dopo l'immissione dei dati. Questo richiede che qualcuno percorra effettivamente il passaggio con uno screen reader. Questo è esattamente il tipo di limitazione che viene esplicitamente indicato in ogni rapporto di axessia: una scansione verifica parte dei requisiti, non tutti.
Per questo motivo la scansione completa non si concentra solo sulla home page, ma appunto anche sui passaggi che il cliente percorre davvero, inclusi l'accesso e il pagamento. Se desiderate prima un'indicazione senza impegni, potete scoprire in poche domande dove si trova attualmente il vostro sito.
Cosa questo significa per i requisiti che dovete rispettare
La norma sottostante, EN 301 549, si traduce nella pratica in WCAG 2.1 livello AA. Contiene requisiti sul nome, il ruolo e lo stato degli elementi interattivi, sui messaggi di stato che devono essere chiari anche senza richiedere attenzione visiva, e su informazioni che non vengono comunicate solo attraverso il colore o la posizione. Per la formulazione esatta e la posizione nel testo ufficiale, EUR-Lex è la fonte appropriata; traduciamo questi requisiti in situazioni riconoscibili come il passaggio di pagamento, ma non esprimiamo un giudizio sulla vostra situazione specifica. Ulteriori informazioni su come avviene questa traduzione si trovano nella pagina che spiega da dove provengono le nostre informazioni.
Come testarlo voi stessi o farlo testare
Un primo passo pratico è eseguire il processo di checkout da solo senza mouse: solo con il tasto Tab e Invio. Se non riesce a proseguire da qualche parte, è molto probabile che anche un lettore di schermo si blocchi lì. Un secondo passo è testare con un lettore di schermo gratuito come NVDA, prestando particolare attenzione a ciò che viene letto quando si verifica un errore. Per un quadro completo, incluse le parti che emergono solo con una revisione manuale, è necessario un test più esteso; axessia esegue quel test e registra i risultati in un elenco di azioni prioritizzato, ma non esegue direttamente lavori di riparazione. Questo rimane a carico dello sviluppatore o del fornitore, spesso basato esattamente sui punti che evidenziamo. Altri argomenti frequentemente posti su questo tipo di problemi concreti si trovano raccolti in la banca di conoscenze con argomenti sviluppati per ogni situazione.
Se desideri sapere il costo di un test completo del tuo processo di checkout e dell'ambiente di accesso, è chiaramente indicato in la pagina con i prezzi e cosa contiene.
Vuoi prima farti un'idea senza impegni? La scansione rapida gratuita di axessia ti fornisce un primo quadro delle tue pagine principali entro pochi minuti e il controllo di ambito ti mostra se la normativa si applica alla tua organizzazione.