Pattern, componenti e sistemi di progettazione

Molte persone utilizzano lo sviluppo basato su componenti utilizzando guide di stile dei pattern, librerie di componenti o sistemi di progettazione completi nel processo di flusso di lavoro di sviluppo. Anche se non hai utilizzato formalmente questi strumenti, è probabile che tu utilizzi un processo simile per suddividere un design di grandi dimensioni per un sito web, un'app o un altro prodotto digitale in parti gestibili.

Come per la costruzione di una struttura fisica, è importante procedere un pezzo alla volta. Innanzitutto, le fondamenta, la struttura, le pareti, le finestre, il tetto e tutto ciò che c'è in mezzo. Gli strumenti di sviluppo basati su componenti ci consentono di farlo per siti web, app e altri prodotti digitali.

Alcuni vantaggi dello sviluppo basato su componenti includono la suddivisione in parti gestibili, quindi i tempi di sviluppo sono inferiori con questi componenti riutilizzabili. Consente a designer, sviluppatori frontend e backend e addetti al QA di lavorare contemporaneamente. E a clienti, designer, project manager e altri professionisti piace perché possono visualizzare l'anteprima del processo di creazione e utilizzare una guida di stile dinamica come riferimento dopo il lancio del sito web.

Tuttavia, quando esaminiamo pattern, componenti e sistemi di progettazione tenendo conto dell'accessibilità, sorgono alcune domande. Come fai a sapere quali pattern sono i migliori per l'accessibilità? Dovresti utilizzare un pattern o una libreria consolidati o crearne di nuovi? Come fai a sapere se questi schemi aiuteranno effettivamente i tuoi utenti?

Con la miriade di opzioni disponibili, è facile confondersi su pattern, componenti e sistemi di progettazione. Questo modulo ha lo scopo di fornirti informazioni generali su come valutare pattern, componenti e sistemi di progettazione per l'accessibilità e ti offre un punto di partenza per aiutarti a fare scelte più accessibili.

Pensa in modo critico

Scegliere un pattern, un componente o un sistema di design accessibile non è un'impresa impossibile, ma richiede tempo e pensiero critico. In realtà, non esiste un "modello perfetto", ma potrebbero esserci potenzialmente molte opzioni che potrebbero funzionare. Si tratta di imparare a scegliere l'opzione migliore per la tua situazione.

Nei moduli di test successivi, scoprirai di più sulle tecniche e metodi per valutare pattern, componenti e sistemi di progettazione per l'accessibilità. Prima di arrivare a questo punto, devi porti alcune domande fondamentali, ad esempio:

  • Esiste già un pattern, un componente o un sistema di progettazione accessibile?
  • Quali browser e tecnologie per la disabilità (AT) supporto?
  • Esistono limitazioni per il codice o il framework? Ci sono altre integrazioni, fattori o esigenze degli utenti che devo prendere in considerazione?

A seconda dell'ambiente di sviluppo e delle esigenze degli utenti, potresti avere domande aggiuntive o diverse da queste. Considera queste domande come punto di partenza per la valutazione dell'accessibilità.

Risorse stabilite

Prima di creare qualcosa di nuovo, svolgi la due diligence e controlla cosa esiste già in termini di pattern, componenti e sistemi di progettazione accessibili. Con un po' di ricerca, potresti scoprire una o più soluzioni adatte alle tue esigenze.

Ecco alcune ottime risorse per pattern, componenti e sistemi di progettazione accessibili:

Per i framework JavaScript, le seguenti risorse sono abbastanza accessibili per impostazione predefinita o personalizzabili per l'accessibilità:

Tuttavia, e non è mai abbastanza sottolineato, non dovresti mai copiare/incollare il codice e presumere che si adatti al tuo ambiente e soddisfi automaticamente le esigenze degli utenti. Questo vale per tutti i pattern, i componenti e i sistemi di design, anche se etichettati come completamente accessibili.

Tutte le risorse devono essere considerate come un punto di partenza. Assicurati di testare tutto.

Supporto di browser e tecnologie per la disabilità (AT)

Dopo aver cercato alcuni pattern di base, componenti o un sistema di progettazione completo che potrebbe essere adatto al tuo ambiente di sviluppo, puoi passare all'assistenza per le tecnologie per la disabilità. Uno dei principali tipi di AA su cui ti consigliamo di concentrarti quando valuti pattern, componenti e sistemi di progettazione è lo screen reader.

Gli screen reader sono stati progettati tenendo conto di browser specifici e funzionano al meglio se abbinati a questi browser. Analizzeremo questo argomento in modo molto più dettagliato nel modulo sui test AT, ma per la valutazione dei pattern è utile sapere che esistono queste combinazioni, in modo da sapere di cosa hai bisogno in termini di assistenza.

Screen reader Sistema operativo Compatibilità del browser Costo
Job Access with Speech (JAWS) Windows Chrome, Firefox, Edge Licenza richiesta (è disponibile una versione senza costi di 40 minuti)
Non-Visual Desktop Access (NVDA) Windows Chrome e Firefox Senza costi (richiede il download)
Narratore Windows Edge Senza costi (integrato nei computer Windows)
VoiceOver macOS Safari Senza costi (integrato nelle macchine macOS)
Orca Linux Firefox Senza costi (integrato nelle distribuzioni basate su Gnome)
TalkBack Android Chrome e Firefox Senza costi (integrato in alcune versioni del sistema operativo Android)
VoiceOver iOS Safari Senza costi (integrato nei dispositivi iOS)

Il supporto dei browser è in genere complicato e le cose si complicano ulteriormente se aggiungi dispositivi AT e specifiche ARIA.

Ma non sono tutte cattive notizie. Fortunatamente, esistono ottime risorse come Accessibilità HTML5, Assistenza per l'accessibilità e la lista di controllo per lo sviluppo di controlli accessibili del WCAG che ci aiutano a comprendere meglio l'attuale supporto dei browser e dei dispositivi AT e persino quando utilizzare ARIA.

Queste risorse descrivono i diversi elementi secondari dei pattern HTML e ARIA disponibili, inclusi i test della community open source. Puoi anche esaminare alcuni esempi di pattern per computer, browser mobile e dispositivi AT. Di conseguenza, queste risorse possono aiutarti a prendere una decisione più accessibile in merito a pattern, componenti e sistemi di design che potresti voler utilizzare.

Altre considerazioni

Dopo aver scelto alcuni pattern o componenti di base accessibili e preso in considerazione il supporto dei browser e dei dispositivi AT, puoi passare a domande contestuali più specifiche sul pattern, sul componente, sul sistema di design e sull'ambiente di sviluppo.

Ad esempio, se utilizzi un sistema di gestione (CMS) o hai codice legacy, potrebbero esserci alcune limitazioni ai pattern che puoi utilizzare. Dopo la revisione, diversi modelli possono essere ridotti rapidamente a una o due opzioni.

Molti framework JavaScript consentono agli sviluppatori di utilizzare quasi tutti i pattern che scelgono. In questi casi, potresti avere meno limitazioni e puoi scegliere l'opzione di motivo più accessibile.

Esistono altre considerazioni da valutare quando si sceglie un pattern, un componente o un sistema di design, ad esempio:

  • Prestazioni
  • Sicurezza
  • Ottimizzazione per i motori di ricerca
  • Supporto per la traduzione di lingue
  • Integrazioni di terze parti

Questi fattori incidono senza dubbio sulla scelta del pattern, ma devi anche prendere in considerazione le persone che creano i contenuti e il codice stesso. Il pattern scelto deve essere sufficientemente solido da gestire eventuali potenziali limitazioni relative ai contenuti generati dagli editor o dagli utenti, oltre a essere progettato in modo da poter essere utilizzato dagli sviluppatori con tutte le conoscenze sull'accessibilità.

Verificare di aver compreso

Metti alla prova le tue conoscenze sui pattern

I componenti accessibili rimangono sempre accessibili per gli utenti?

Sì, puoi utilizzare questi componenti senza ulteriori interventi.
Sebbene una risorsa creata per l'accessibilità abbia maggiori probabilità di funzionare automaticamente rispetto ad altre, è essenziale eseguire comunque i test di accessibilità per assicurarti che questi componenti funzionino per i tuoi utenti.
No, devi prima testare i componenti.
Anche i componenti e gli schemi progettati per l'accessibilità devono essere sottoposti a test. È possibile che non sia accessibile in combinazione con altri componenti esistenti.