Pattern, componenti e sistemi di progettazione

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

Come nel caso di una struttura fisica, è importante costruire un pezzo alla volta. Prima le fondamenta, la struttura, le pareti, le finestre, il tetto e tutto il resto. Gli strumenti di sviluppo basati su componenti ci consentono di farlo per siti web, app e altri prodotti digitali.

Alcuni vantaggi dello sviluppo basato sui componenti includono la suddivisione in parti gestibili, in modo da ridurre i tempi di sviluppo con questi componenti riutilizzabili. che consente a designer, sviluppatori di frontend e backend e al QA di lavorare contemporaneamente. E i clienti, i designer, i PM e molti altri apprezzano perché possono visualizzare l'anteprima del processo di compilazione e utilizzare una guida di stile moderna come riferimento dopo il lancio del sito web.

Tuttavia, quando esaminiamo pattern, componenti e sistemi di progettazione tenendo conto dell'accessibilità, ci sono alcune domande che sorgono. Come fai a sapere quali modelli sono i migliori per quanto riguarda l'accessibilità? Devi usare un pattern/libreria stabilito o crearne di nuovi? Come fai a sapere se questi pattern aiuteranno effettivamente i tuoi utenti?

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

Pensa in modo critico

Scegliere uno schema, un componente o un sistema di progettazione accessibile non è una scienza spaziale, ma richiede tempo e pensiero critico. In realtà, non esiste "un unico schema perfetto", ma potrebbero esserci molte opzioni che potrebbero funzionare. Si tratta di capire come scegliere l'opzione migliore per la tua situazione specifica.

Nei successivi moduli di test, scoprirai di più sulle tecniche e sui metodi per valutare pattern, componenti e sistemi di progettazione per l'accessibilità. Ma prima di questa fase, devi fare un passo indietro e porti alcune domande fondamentali, come:

  • Esiste già un modello, un componente o un sistema di progettazione accessibili e consolidati?
  • Quali sono i browser e le tecnologie per la disabilità che sto supportando?
  • Ci sono limitazioni di codice/framework o altre integrazioni/fattori/esigenze degli utenti che devo prendere in considerazione?

A seconda del tuo ambiente di sviluppo e delle esigenze degli utenti, potresti avere domande aggiuntive o diverse tra queste. Considera queste domande come punto di partenza nella tua valutazione dell'accessibilità.

Risorse consolidate

Prima di creare qualcosa di nuovo, fai la due diligence e rivedi ciò che già esiste in termini di modelli, componenti e sistemi di progettazione accessibili. Con poche ricerche, potresti sorprenderti di trovare una o più soluzioni adatte alle tue esigenze.

Alcune ottime risorse per pattern, componenti e sistemi di progettazione accessibili includono:

Per i framework JavaScript, le seguenti risorse sono disponibili fin dal primo avvio o sono facili da personalizzare per l'accessibilità:

Tuttavia, e questo non può essere abbastanza stressato, 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 progettazione, anche se etichettati come completamente accessibili.

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

Supporto di browser e tecnologie per la disabilità

Dopo aver studiato alcuni pattern di base, componenti o un sistema di progettazione completo che potrebbe funzionare per il tuo ambiente di sviluppo, puoi passare al supporto delle tecnologie per la disabilità. Uno dei principali tipi di AT su cui concentrarti durante la valutazione di pattern, componenti e sistemi di progettazione sono gli screen reader.

Gli screen reader sono stati realizzati pensando a browser specifici e sono più adatti a questi tipi di browser. Analizzeremo questo argomento in modo molto più dettagliato nel modulo sui test AT, ma ai fini della valutazione dei pattern è utile comprendere queste combinazioni in modo da sapere cosa ti serve in termini di assistenza.

Screen reader Sistema operativo Compatibilità del browser Costo
Accesso al job di riconoscimento vocale (JAWS) Windows Chrome, Firefox, Edge Licenza richiesta (esiste una versione senza costi di 40 minuti)
Accesso non visivo al desktop (NVDA) Windows Chrome e Firefox Senza costi (richiede il download)
Narrator Windows Perimetrale 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 quando aggiungi dispositivi AT e specifiche ARIA al mix.

Ma non sono tutte cattive notizie. Fortunatamente, ottime risorse come l'accessibilità HTML5, il supporto per l'accessibilità e l'elenco di controllo per lo sviluppo accessibile tramite controllo personalizzato delle WCAG ci aiutano a comprendere meglio il supporto dei browser attuali e dei dispositivi AT e persino quando utilizzare ARIA in primo luogo.

Queste risorse descrivono i diversi sottoelementi con pattern HTML e ARIA disponibili, compresi i test della community open source. Puoi anche esaminare alcuni esempi di pattern per browser desktop e mobile/dispositivi AT. Pertanto, queste risorse possono aiutarti a prendere una decisione più accessibile riguardo a pattern, componenti e sistemi di progettazione che potresti voler utilizzare.

Altre considerazioni

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

Ad esempio, se lavori in un sistema di gestione (CMS) o hai un codice legacy, potrebbero esserci alcune limitazioni ai pattern che puoi utilizzare. Dopo la revisione, varie scelte di pattern possono essere rapidamente ridotte a una o due opzioni.

Molti framework JavaScript consentono agli sviluppatori di utilizzare quasi tutti i pattern scelti. In casi come questi, potresti avere meno restrizioni e puoi scegliere l'opzione del pattern più accessibile.

Quando si sceglie un modello, un componente o un sistema di progettazione occorre considerare ulteriori considerazioni, ad esempio:

  • Esibizione
  • Sicurezza
  • Ottimizzazione per i motori di ricerca
  • Supporto della traduzione in altre lingue
  • Integrazioni di terze parti

Questi fattori avranno indubbiamente un ruolo nella scelta dei pattern, ma dovresti considerare anche le persone che creano i contenuti e il codice stesso. Il pattern che scegli deve essere abbastanza solido da poter gestire eventuali limitazioni relative ai contenuti generati dagli editor o dagli utenti, inoltre deve essere realizzato in modo tale da consentire agli sviluppatori di tutte le conoscenze sull'accessibilità.

Verifica la tua comprensione

Verifica la tua conoscenza dei pattern

I componenti accessibili rimangono sempre accessibili agli utenti?

Sì, puoi utilizzare questi componenti senza ulteriore intervento.
Sebbene una risorsa progettata per l'accessibilità abbia maggiori probabilità di funzionare automaticamente rispetto ad altre, è essenziale eseguire comunque test di accessibilità per garantire che questi componenti funzionino per gli utenti.
No, devi prima testare i tuoi componenti.
Anche i componenti e i pattern progettati per l'accessibilità devono essere testati. Potrebbe essere inaccessibile in combinazione con altri componenti esistenti.