Come assicurarsi che il vostro contributo sia accessibile

Sapete che volete che il vostro contributo – modulo, iniziativa, tema, patch o core – sia accessibile, ma non siete sicuri di come riuscirci.

L’approccio dei BBC Accessibility Champions ha avuto un enorme successo, e la comunità di Drupal può usarlo come base per modellare il proprio processo raccomandato. L’accessibilità non è semplice: richiede creatività, test e apertura. Si ottiene in modo più efficace ed elegante quando viene integrata in tutto il processo fin dall’inizio.

Trovate un campione A11y per la vostra squadra (o diventatelo voi stessi)

• La nostra comunità è ricca di esperti che desiderano rendere Drupal il più accessibile possibile; potete trovare campioni nelle code delle issue, parlare con esperti di accessibilità nei camp e nei con, oppure unirvi al canale #accessibility su Drupal Slack.
• Che siate un campione dedicato o che svolgiate questo ruolo insieme ad altri, è importante consultare regolarmente i maintainers per ricevere feedback su problemi complessi e approcci. Stiamo anche organizzando delle ore di ufficio mensili per facilitare questo processo.
• Eseguite regolarmente le vostre revisioni di accessibilità.
• Familiarizzate con i fondamenti delle linee guida WCAG 2.1 e ATAG 2.0.

Pianificate le revisioni di accessibilità in ogni fase

Tutto ciò che viene integrato nel core di Drupal deve passare attraverso il “gateway di accessibilità”, il che significa che un maintainer dell’accessibilità deve approvarlo. Tuttavia, ottenere questa approvazione alla fine di un progetto può essere molto difficile se non avete considerato l’accessibilità fin dall’inizio.

Il modo migliore per garantire l’accessibilità è pianificare revisioni regolari con gli esperti del team di accessibilità. Al minimo, consigliamo le seguenti fasi:

1. Revisione del design

• Design dell’interazione (inclusi gli aspetti visivi).
• Design tecnico: il modo in cui implementate le soluzioni e scrivete il codice può avere un impatto significativo sull’accessibilità. Prima di iniziare a sviluppare, discutete il vostro piano con un esperto di accessibilità.

2. Revisione Alpha

L’esperto di accessibilità ha esaminato il vostro prototipo e la roadmap; l’ambito è chiaro e i problemi di accessibilità sono stati identificati (anche se non ancora risolti).

3. Revisione Beta

Tutti i problemi di accessibilità sono stati individuati e sapete come verranno risolti (anche se non ancora corretti). L’esperto di accessibilità approva il vostro approccio pianificato.

4. Revisione stabile

Tutti i problemi di accessibilità sono stati risolti e verificati con successo; il codice supera il “gateway di accessibilità” per l’inclusione nel core.

Consigliamo di ottenere un’approvazione ufficiale dal maintainer dell’accessibilità in ciascuna di queste fasi, in modo da rendere più fluido il rilascio finale.

Ma cosa succede se non abbiamo iniziato nel modo giusto?

• E se il nostro lavoro è già in corso e non abbiamo iniziato con questo approccio?

Iniziate il prima possibile. La comunità è qui per aiutarvi.

• E se non ne sappiamo abbastanza?

Ci sono molte risorse per guidarvi lungo il percorso, e i maintainer dell’accessibilità sono qui per supportarvi, non per giudicare. Possiamo anche indirizzarvi verso i materiali più adatti.

• E se non riusciamo a trovare un campione di accessibilità?

Se volete diventare voi stessi il vostro campione di accessibilità, scoprirete che è un ruolo stimolante e ricco di apprendimento. Inoltre, sul canale #accessibility di Slack troverete molti membri attivi con cui iniziare.

• E se commettiamo un errore?

Qualcuno lo segnalerà nella coda delle issue, e lavorerete insieme per capire come risolverlo e migliorare ulteriormente il vostro lavoro. È una cosa positiva.

Questo articolo è rilevante per me?

Partecipate allo sviluppo del core, di temi, moduli o patch di Drupal? Se sì, allora sì, vi riguarda. Drupal è ampiamente utilizzato da università, governi e grandi istituzioni in tutto il mondo, molte delle quali sono legalmente obbligate a garantire l’accessibilità dei loro strumenti digitali.

Correggere funzionalità non accessibili o riscrivere codice inaccessibile può essere estremamente impegnativo e costoso.

Creare qualcosa di accessibile fin dall’inizio è molto più elegante, semplice ed economico.