Accessibilità

Workflow per migliorare lo sviluppo dei componenti

Abbiamo costruito un promemoria minimo e non esaustivo di attività e controlli da fare, per supportare l’integrazione e la revisione dei componenti del design system durante le attività di sviluppo. Il promemoria suggerisce come condurre alcune verifiche di accessibilità su componenti, pattern, e su proposte evolutive, per evidenziare criticità e opportunità durante le lavorazioni di sviluppo.

Per svolgere analisi di accessibilità è necessario coinvolgere esperti qualificati (es. Web Accessibility Expert) e, ogni qualvolta possibile, predisporre sessioni di test di usabilità con panel rappresentativi di utenti.

Il flusso di lavoro che segue prende a riferimento le implementazioni per il framework del design system Bootstrap Italia: è da considerare una traccia da seguire come aiuto allo sviluppo, rispetto al lavoro più completo da fare con gli esperti di dominio e con i test di usabilità.

Test validazione HTML

• Implementato nelle automazioni (CI/CD) del repository di Bootstrap Italia tramite HTMLProofer

Test automatici

I test automatici di accessibilità possono essere condotti con molteplici soluzioni, sia generaliste che dedicate a particolari aspetti, e sono talvolta essenziali per l’individuazione di problematiche specifiche; va sottolineato tuttavia che tali soluzioni non sono soddisfacenti per una rilevazione efficace di numerose tipologie di criteri di successo.

Una lista esaustiva, ma non validata, di tali tecnologie è disponibile sul sito del W3C.

Le soluzioni "minime" da utilizzare durante lo sviluppo sono:

• Controllo codice durante la scrittura (eg. con axe-linter per VS Code, anche implementato nelle automazioni (CI/CD) di Bootstrap Italia);
• Test condotti sul DOM in-browser con estensioni (a titolo di esempio):
  • WAVE Evaluation Tool
  • Siteimprove
• Test condotti con script:
  • Pa11y (implementato nelle automazioni (CI/CD) di Bootstrap Italia)

Test manuali

I test manuali sono una fase critica che richiede competenze in materia di accessibilità in chi la esegue. Il workflow che segue è utile per individuare durante lo sviluppo ad esempio errori nelle interazioni e nel labeling non rilevabili dai test automatici, ma non sostituisce il test manuale condotto da esperti qualificati.

Interazioni via tastiera

Da verificare anche rispetto ai pattern ARIA:

• Tab: si sposta sul successivo elemento focusable
• Shift + Tab: si sposta sul precedente elemento focusable
• Invio: attiva link, pulsanti e altri elementi interattivi
• Spazio: attiva radio button, checkbox e pulsanti
• Frecce: navigano i radio button e le opzioni di select e dropdown, e scrollano la pagina

Alcune delle funzionalità da verificare durante i test:

• l'ordine di tab è logico
• il focus è visibile
• non sono presenti "keyboard traps"
• comportamento delle modali

Ingrandimento

Supportare l'ingrandimento, nativo del browser, fino a 400% per viewport larghe 1280px, e laddove esistano elementi con scroll orizzontale, per viewport larghe 1024px.

Verificare assenza di:

• errori nel ridimensionamento testo
• scroll orizzontale non desiderato (o verticale per elementi con scroll orizzontale)
• sovrapposizioni
• tagli di contenuto
• perdita di funzionalità

Lettore di schermo (screen reader)

Sono disponibili diversi screen reader a seconda del sistema operativo utilizzato. In Europa lo screen reader più utilizzato è l’open source NVDA, seguito da JAWS (a pagamento) e VoiceOver (integrato nei sistemi operativi Apple). Il browser più utilizzato è Chrome, seguito da Edge e Safari. Dovendo individuare una soluzione unica per il test durante le lavorazioni, la combinazione suggerita è Windows+Chrome+Jaws.

Controlli da eseguire:

• controllo sequenza lettura
• controllo etichette (label, label nascoste, label ARIA) e ruoli degli elementi
• controllo elementi interattivi
• controllo struttura e gerarchia titolazioni (heading), in special modo nei template di pagina
• controllo testi alternativi (alt text)
• controllo annuncio cambi dinamici del DOM (aria-live)