Gli errori più comuni nell'accessibilità dei siti web

Non è un segreto che il tema dell'accessibilità web sia in aumento vertiginoso. Migliaia di cause legali e decine di migliaia di lettere di richiesta notificate ai proprietari di piccole imprese (ma non solo a loro, vedi la sentenza della corte suprema di Dominos), hanno portato a un aumento di oltre il 400% nelle ricerche di Google per una soluzione conforme ad ADA e WCAG, da gennaio 2019 a dicembre 2019. Questo è dovuto ai numerosi errori nell'ambito dell'accessibilità web commessi dai proprietari dei siti.Quindi, poiché la popolarità dell'argomento aumenta in modo esponenziale, noi, come leader del settore, siamo moralmente obbligati a fornire quanti più dati possibile, per aiutare a portare avanti il ​​campo. Ad oggi, (dicembre 2019), AccessiWay ha scansionato, analizzato e corretto completamente decine di migliaia di siti web. Alcuni dei quali sono nostri clienti  (10.000 oggi) e altri sono siti Web che scansioniamo, analizziamo e ripariamo come parte della formazione della nostra IA.Tutto sommato, abbiamo appena raggiunto 10.000.000 pagine analizzate ed è ora di diffondere un po' di conoscenza e condividere i nostri dati!

Ecco come si suddivide la ricerca per scoprire gli errori sull'accessibilità:

1. ~ 85% dei siti web erano ospitati negli Stati Uniti e in Canada, il 15% in Europa e in Asia;
2. ~ 65% dei siti web erano domini di primo livello (com, net, org, ecc.). Gli altri erano di secondo e terzo livello (io, co, app, xyz, ecc.);
3. ~ L'80% dei siti web aveva meno di 1.000 pagine;
4. ~ Il 19% dei siti web aveva 1.000-100.000 pagine;
5. ~ 1% dei siti web aveva più di 100.000 pagine (abbiamo smesso di contare le pagine di un sito web dopo aver raggiunto 100.000).

Nota: abbiamo dato ai siti un "tempo più facile" e non abbiamo sempre incluso tutti gli errori WCAG. Se un errore era in qualche modo minore e non si ripeteva, non lo abbiamo incluso nei risultati. Ad esempio, per quanto riguarda la non inclusione di un aria-label per un'icona "Carrello degli acquisti". Stavamo cercando una conformità effettiva e pratica per l'accessibilità che rendesse i siti Web completamente utilizzabili con la tastiera, con uno screen reader, altre tecnologie o strumenti di assistenza e, naturalmente, utilizzabili da persone con diverse disabilità. Non eravamo alla ricerca di un immaginario tasso di successo del 100%.Inoltre, a differenza dei comuni strumenti di test automatizzati (WAVE, ax, Tenon e altri), in realtà emuliamo un browser e utilizziamo l'IA per determinare i ruoli degli elementi. Ciò significa che anche se un modulo o un'immagine non è conforme, ma è anche nascosto e non viene mai visualizzato, non lo tralasceremo.Di seguito, troverai un grafico sui dati raccolti da 10.000.000 pagine web. I dati suddividono alcuni degli elementi più importanti per ottenere la conformità.  Il grafico a barre sotto riportato mostra la percentuale di tutte le pagine scansionate che non sono state conformi ai requisiti per menu, immagini, pop-up e così via.

Nota importante: prima di approfondire e spiegare ciascuna categoria, bisogna tenere presente che non spiegheremo sempre perché una determinata categoria o elemento deve applicare questo o quel comportamento o attributo, ma solo i requisiti stessi. È così che l'articolo avrà un fine. Analizziamo più a fondo e suddividiamo in categorie.

WCAG 2.1 AA - Livello di conformità dei menu ed errori:

• % dei siti web non conformi: 98% - quasi nessun sito è conforme, compresi quelli che lavorano manualmente sull'accessibilità del loro menu.
• Cosa è richiesto dalle WCAG:
• Un tag "NAV" o un attributo "role" uguale a "navigation / menu / menubar" (dipende dal tipo di menu) deve essere presente sull'elemento superiore che contiene tutti i link e le voci di menu (role = "navigation / menu / barra dei menu ").
• Gli utenti possono utilizzare il tasto Tab per passare all'elemento successivo e Maiusc + Tab per passare all'elemento precedente e l'elemento attivo deve essere facilmente identificabile utilizzando un anello di messa a fuoco (contorno).
• Gli utenti possono navigare nella barra dei menu stessa utilizzando le frecce sinistra e destra della tastiera. Quando si raggiunge la fine del menu e si preme il tasto freccia avanti, la navigazione dovrebbe tornare al primo elemento. (Non è un requisito WCAG scolpito nella pietra, ma è una best practice e compare in molte cause legali).
• Gli utenti possono aprire i menu a discesa utilizzando i tasti Invio e freccia giù. I menu a discesa dovrebbero essere aperti anche concentrandosi sulla voce di menu.
• Gli utenti possono navigare all'interno dei menu a discesa utilizzando le frecce su e giù e scorrere all'interno del menu a discesa a meno che non sia stato chiuso intenzionalmente. (Non è un requisito WCAG scolpito nella pietra, ma è una best practice e compare in molte cause legali).
• Gli utenti possono chiudere il menu a discesa utilizzando il tasto Esc e lo stato attivo della tastiera deve tornare alla voce di menu principale di questo menu a discesa. (Non è un requisito WCAG scolpito nella pietra, ma è una best practice e compare in molte cause legali).

Nota importante relativa ai requisiti: sappiamo che alcuni dei requisiti per i menu sembrano pignoli, e questo è vero per alcune aree delle WCAG, ma in particolare con i menu, sono incredibilmente importanti. Pensa ad un utente con disabilità motoria con un clic-stick per la bocca (poiché altrimenti non è in grado di interagire con il computer), che prova a navigare tra decine o centinaia di link e menu a discesa uno per uno con il tasto Tab, senza poter saltare utilizzando le frecce o chiudere i menu a discesa con Esc. L'utente impiegherà diversi lunghi minuti solo per trovare ciò che sta cercando.I nostri risultati: abbiamo scoperto che quasi nessuno dei siti web implementava tutti i requisiti relativi ai menu e questo è un grosso problema. Alcuni hanno abilitato la navigazione utilizzando il tasto Tab, alcuni addirittura hanno fatto un ulteriore passo avanti e hanno implementato la navigazione con Tab nei menu a discesa, ma quasi nessuno ha consentito agli utenti di chiudere i menu a discesa con Esc o implementato una corretta navigazione con i tasti freccia. Inoltre, gli attributi di ruolo corretti sono stati trovati raramente.Abbiamo scoperto che modelli popolari di alcuni dei CMS come WordPress, Shopify, Joomla, Magento, BigCommerce, Squarespace e altri, a volte includevano funzionalità di accessibilità integrate relative ai menu, ma non abbastanza.

I risultati

RequisitiConformità

1. Implementazione del tag “NAV” o del ruolo=navigazione/menu/barra dei menu

41%

1. Implementazione di role= menuitem

8%

1. Navigazione Tab & Shift + Tab incluso focus visivo

12%

1. Navigazione e ripetizione ciclica della barra dei menu delle frecce sinistra e destra

<1%

1. Apri menu a discesa con Focus, Invio e freccia giù

5%

1. Navigare all’interno dei menu a discesa utilizzando i tasti su e giù

<1%

1. I menu a discesa possono essere chiusi con ESC e lo stato attivo torna all’elemento principale

3%

WCAG 2.1 AA - Livello di conformità delle immagini ed errori:

• % dei siti web non conformi: 52%.
• % dei siti web conformi: 48%.
• Cosa è richiesto da WCAG: tutte le immagini devono avere un attributo Alt (alcune persone lo chiamano tag anche se in realtà è un attributo), che descriva correttamente gli oggetti nell'immagine e se l'immagine contiene testi (come i tipici banner), allora il testo deve essere presente anche nell'attributo alt.

I nostri risultati

Questo risultato ci ha colti di sorpresa. Le immagini nel 48% delle pagine web, quasi la metà, avevano attributi Alt corretti! Ci aspettavamo un risultato molto inferiore. Non sappiamo se questo sia stato fatto per la SEO o per l'accessibilità (probabilmente SEO?), ma va bene in ogni caso. Alcuni siti Web hanno cercato di essere "intelligenti" e hanno creato il nome del file, l'attributo alt. Altri erano ancora più "intelligenti" e hanno rimosso i simboli "-" e "_" dal nome del file per creare quella che sembra una frase normale. Purtroppo, questo non è approvato. Anche i titoli nelle vicinanze, le stringhe generate automaticamente e altre manipolazioni non vengono accettate.Per verificare gli attributi Alt "corretti", abbiamo utilizzato le nostre tecnologie OCR e IRIS per abbinare le parole incluse nell'Alt fornito, con oggetti e parole effettivamente presenti nelle immagini.

WCAG 2.1 AA - Livello di conformità dei popup ed errori:

• % dei siti web non conformi: 89%. Sono infatti pochissimi siti web che utilizzano plugin e servizi "accessibili".
• Cosa è richiesto dalle WCAG:
• Quando viene visualizzato un popup, lo stato attivo della tastiera deve sollevarsi dalla pagina principale e tornare indietro nel primo elemento selezionabile del popup.
• La navigazione utilizzando il tasto Tab all'interno del popup deve tornare indietro per iniziare quando si raggiunge l'ultimo elemento e si cerca di andare avanti.
• Gli utenti devono essere in grado di chiudere i popup con il tasto Esc e lo stato attivo deve tornare all'elemento su cui era focalizzato prima del popup.
• I popup devono includere un attributo "role" uguale a "dialog".
• I popup devono includere un attributo "aria-modal" uguale a "true".

I nostri risultati

La maggior parte dei siti Web utilizza una qualche forma di plug-in popup, un jQuery non elaborato incorporato nel modello come jQuery UI Dialog e Fancy Box, un plug-in CMS come OptinMonster o un servizio di terze parti come Zoom Analytics. Alcuni di questi servizi implementano alcuni requisiti di accessibilità, ma la maggior parte non ne ha nessuno. In ogni caso, questo significa che anche coloro che pensano all'accessibilità spesso si accontentano solo delle basi. Il grosso problema con i popup è che una volta che non sono completamente conformi, infrangono l' INTERO livello di conformità del sito. Quando un popup salta, blocca letteralmente l'intero schermo, impedendo agli utenti della tastiera di fare nulla al riguardo. Gli utenti di screen reader non sapranno nemmeno che è apparso un popup. Il pieno rispetto dei requisiti del popup è MOLTO importante.Nota: sebbene un buon numero di popup abbia implementato la chiusura Esc, un numero molto piccolo ha effettivamente restituito il focus all'elemento precedentemente focalizzato correttamente.

I risultati:

Requisiti Conformità

1. Lo stato attivo della tastiera si solleva dalla pagina ed entra nel popup

18%

1. Navigazione e ripetizione ciclica del popup con Tab

4%

1. Chiudere il popup con Esc E restituire lo stato attivo

2%

1. I popup devono implementare role = dialog

31%

1. I popup devono implementare aria-modal = true

37%

WCAG 2.1 AA - Livello di conformità dei moduli ed errori:

• % dei siti web non conformi: 71%.
• % dei siti conformi: 29%, grazie ad un lavoro abbastanza buono che alcuni plugin CMS fanno a questo proposito.
• Cosa è richiesto dalle WCAG:
• Tutti i campi devono includere un tag "LABEL" collegato al campo dagli attributi "id" e "for" o da un attributo "aria-label".
• I campi obbligatori devono includere entrambi i segnali visivi (asterisco *, testo o altro) e l'attributo "aria-required" è uguale a true.
• I campi devono includere l'attributo "aria-invalid" per informare gli screen reader se il campo è attualmente valido o non valido. Questo attributo deve cambiare dinamicamente in base alle convalide. Ad esempio, un campo "nome" obbligatorio vuoto deve includere aria-invalid = "true" per indicare che non è valido, ma cambia in aria-invalid = "false" una volta che l'utente lo riempie.
• Quando viene inviato un modulo e sono presenti errori, il focus della tastiera deve essere portato al primo campo non valido e l'utente deve ricevere una spiegazione (sia visiva che per lo screen reader) di quale sia il problema con questo campo.
• Quando un modulo viene inviato con successo, un utente non vedente con uno screen reader dovrebbe esserne informato utilizzando un elemento di avviso o altri mezzi.

I nostri risultati

Abbiamo scoperto che spesso in sistemi chiusi e già pronti come Shopify, Volusion e BigCommerce, la piattaforma oi suoi popolari plug-in di moduli svolgono un lavoro abbastanza buono nel garantire che i moduli siano accessibili.La situazione è molto diversa anche se con la maggior parte delle altre piattaforme open source come WordPress, Magento e Joomla. Questi sistemi sono aperti a modifiche e sostituzioni e, sebbene questo sia positivo per i gestori di siti Web, questo è negativo per l'accessibilità. I gestori dei siti web di solito non applicano manualmente i requisiti di conformità necessari.Inoltre, abbiamo anche riscontrato che, anche se i moduli sono stati resi accessibili e la maggior parte dei campi è stata descritta correttamente, pochissimi hanno effettivamente segnalato a uno screen reader un invio riuscito. Alcuni hanno segnalato un invio non riuscito, ma soprattutto perché i moduli spesso utilizzano le convalide HTML5 integrate (che sono conformi per impostazione predefinita) senza nemmeno sapere che lo hanno fatto.

WCAG 2.1 AA - Livello di conformità dei pulsanti ed errori:

• % dei siti web non conformi: 83%.
• % dei siti web conformi: 17%.
• Cosa è richiesto dalle WCAG:
• Deve contenere testo, titolo o un'etichetta “aria”.
• Deve essere un tag "BUTTON" effettivo o, in alternativa, un attributo "role" uguale a "button".
• I pulsanti devono includere testo / aria-label / titolo.

I nostri risultati

Sebbene la maggior parte dei pulsanti sia conforme alle clausole 1 e 3, la grande maggioranza non viene contrassegnata correttamente! La maggior parte dei siti Web utilizza i tag HTML "SPAN", "DIV" o "A" (link) per la creazione di pulsanti (senza utilizzare role = button come riserva). Gli sviluppatori modificano l'aspetto predefinito di questi tag utilizzando CSS e il loro comportamento utilizzando eventi di clic JavaScript.In questo modo si evita che i pulsanti "falsi" vengano letti correttamente dai lettori di schermo e questo significa anche che non sono cliccabili utilizzando la tastiera per impostazione predefinita.Nella nostra ricerca, quasi tutti i siti Web includevano tali pulsanti "falsi". I tag standard "PULSANTE" venivano usati quasi solo con i moduli, molto raramente come pulsanti autonomi e pochissimi usavano l'attributo "ruolo" come riserva per gli screen reader.

WCAG 2.1 AA - Livello di conformità dei collegamenti ed errori:

• % dei siti web non conformi: 22%.
• % dei siti web conformi: 78%.
• Cosa è richiesto dalle WCAG:
• Deve contenere testo, titolo o un'etichetta “aria”.
• Deve essere ordinato logicamente all'interno del documento (ad esempio, dopo il titolo e il paragrafo di una sezione deve essere inserito un "leggi di più").
• I collegamenti devono essere raggiungibili tramite la navigazione da tastiera utilizzando il tasto Tab.
• I collegamenti devono fornire un indicatore visivo se vengono aperti in una nuova finestra e anche annunciarlo a uno screen reader utilizzando un testo o un titolo nascosto.
• I collegamenti devono essere visibili sulla pagina e avere un aspetto diverso dal testo normale.

I nostri risultati

Nella nostra ricerca, la maggior parte dei siti Web ha superato il test dei collegamenti. Non siamo sicuri se ne siamo sorpresi o meno, perché quasi tutti i requisiti sono un comportamento predefinito del browser, quindi non c'è molto lavoro da fare per la conformità del collegamento.Nota: quasi nessuno dei link indica effettivamente che una nuova finestra è aperta. Possiamo affermare che questi siti web abbiano raggiunto le conformità previste, perché questo non è un enorme problema di violazione degli standard, se non fosse così, dovremmo dichiararli inutilizzabili, nonostante lo siano. Inoltre, c'era un buon numero di link che non contenevano testo, titoli o aria-label, ma solo un'icona, come i link ai social media. Nel nostro caso, non li abbiamo considerati come collegamenti ma come icone, includendo una categoria designata per esse.

WCAG 2.1 AA - Livello di conformità delle icone ed errori:

• % dei siti web non conformi: 76%.
• % dei siti web conformi: 24%.
• Cosa è richiesto dalle WCAG: le icone non hanno molte linee guida, perché non esistono tag o elementi "ICON". Le icone vengono solitamente utilizzate con collegamenti o pulsanti per descrivere un qualche tipo di azione. Quindi, i requisiti per rendere accessibili le icone sono più o meno gli stessi usati per rendere conformi link e pulsanti.

Background: una legittima domanda sarebbe: "Se non ci sono requisiti specifici, perché è inclusa un'intera categoria per le icone?" Bene, questo perché le icone appaiono in quasi il 100% dei siti e, anche se non hanno le proprie funzionalità, gli sviluppatori spesso le usano in modo diverso da pulsanti e collegamenti.Le icone di solito esistono all'interno di un pulsante o di un collegamento e mirano a descrivere quel pulsante o collegamento alle persone che vedono e possono riconoscere questi "segni" . Ad esempio, molti siti Web di e-commerce utilizzano un'icona del carrello senza alcun testo che spieghi che, facendo clic su di essa, si attiva l'apertura del carrello con gli acquisti effettuati. Altri usi possono essere i loghi dei social media senza testo, come i preferiti / lista dei desideri (icona del cuore), pulsanti di ricerca (icona della lente d'ingrandimento), valutazioni dei prodotti (icone a stella) e molti altri casi.

I nostri risultati

La maggior parte delle icone vengono utilizzate come elementi "SVG", icone di caratteri (come font awesome o IcoMoon) o come immagini di sfondo (come Sprite o standalone).Anche se questo struttura va benissimo per le persone che vedono, nessuna di tali pratiche è utile per le persone che usano lettori di schermo (persone non vedenti). Per rendere accessibili queste icone, gli sviluppatori dovranno includere un testo nascosto o un attributo aria-label, che descriva che cos'è questa icona. Ad esempio, un'icona di Facebook dovrà avere un testo nascosto o un'aria-label uguale a "Facebook".Nella nostra ricerca, è risultato che la maggior parte delle icone non viene affatto descritta, specialmente le icone dei caratteri. Detto questo, il 24% delle pagine web ha superato il test, grazie ad alcune popolari librerie di icone che implementano descrizioni integrate nei loro elementi SVG. Anche altri plug-in CMS di font-icon fanno qualcosa di simile ma su un diverso tipo di elemento (di solito un tag "I").

Altri importanti risultati

Esistono altri importanti requisiti di accessibilità che i siti Web devono includere per essere conformi, ma non appartengono a nessuna delle categorie precedenti. Nota: non abbiamo incluso TUTTI i requisiti di conformità, ma solo quelli più evidenti, che hanno un impatto sul livello di conformità della maggior parte o di tutti i siti web.

• Attributo HTML lang: il tag "HTML" deve includere un attributo "lang" uguale alla lingua del documento. Ad esempio, "EN" per l'inglese e "FR" per il francese.
• Salta collegamenti: la parte superiore di ogni pagina Web deve includere pulsanti nascosti visivamente (che appaiono in primo piano) e consentire agli utenti di passare a diverse sezioni all'interno della pagina.
• Uso errato di ARIA: molti siti Web includono un utilizzo errato degli attributi ARIA, solitamente "aria-labelledby" e "aria-descriptionby" che vengono automaticamente popolati da vari plug-in di moduli.
• Tabulazione negli elementi nascosti: le pagine Web spesso includono elementi nascosti che appaiono in determinate condizioni come popup, barre laterali e menu a discesa. Questi elementi non devono essere navigabili se non visivamente attivi sullo schermo.
• Anello di messa a fuoco debole / inesistente: ogni elemento cliccabile deve includere un anello di messa a fuoco (contorno) visivo e visibile quando viene focalizzato durante la navigazione con scheda.

RequisitiSiti web considerati conformi

1. Attributo “lang” HTML corretto

65%

1. Salta collegamenti

18%

1. Uso scorretto di ARIA

15%

1. Tabulazione negli elementi nascosti

39%

1. Anello di messa a fuoco debole/inesistente

32%

Conclusioni finali sugli errori più comuni sull'accessibilità

Questo è ciò che abbiamo imparato sul livello di conformità WCAG 2.1 del web, dopo aver analizzato 10.000.000 pagine. A dire il vero Internet è (o era, prima di noi), in pessime condizioni di conformità. Per dirla senza mezzi termini, l'accessibilità è estremamente difficile da ottenere manualmente.Come si è visto dai risultati, spesso gli sviluppatori di plugin e modelli cercano di conformarsi a determinati requisiti, ma spesso questi non sono nemmeno quasi sufficienti. Inoltre, questi plugin e modelli vengono utilizzati dai proprietari di siti Web che di solito non sanno nulla di codifica, best practice o accessibilità. Hanno semplicemente un sistema e fanno clic sui pulsanti per ottenere ciò che vogliono il più rapidamente possibile senza pensare a che cosa è e che cosa non è accessibile. Pertanto, i proprietari di siti Web finiscono per rovinare la propria conformità molto rapidamente con ogni aggiornamento che fanno.L'accessibilità non è una delle priorità della maggior parte degli imprenditori. Marketing, assunzioni, servizio clienti e vendite lo sono (ovviamente). Il nostro lavoro, come sviluppatori e designer, è concepire e ottenere scoperte tecnologiche per rendere i siti web conformi, nonostante l'argomento non sia una priorità per i proprietari di aziende, perché non lo sarà mai! Dobbiamo occuparcene noi.