Smashing Podcast Episode 4 con Heydon Pickering: quali sono i componenti inclusi?

Oggi parlo con Heydon Pickering del suo nuovo libro, Inclusive Components . Heydon è noto per il suo lavoro e per i suoi scritti sull'accessibilità, quindi cosa significa effettivamente "Design inclusivo" e dove entrano in gioco i componenti? Heydon spiega tutto questo e altro in questo episodio. Puoi ascoltare di seguito o iscriverti ovunque trovi i tuoi podcast.

Mostra note

• Il libro Componenti inclusi di Smashing Magazine
• Il progetto di Heydon Every Layout con Andy Bell
• Sito web di Heydon Heydonworks
• Heydon su Twitter

Trascrizione

Drew McLellan: È un consulente freelance per l'accessibilità al web, designer di interfacce e scrittore. Il suo lavoro si concentra sulla progettazione dell'esperienza utente accessibile, nonché sulla scrittura e l'editing per Smashing Magazine. È l'autore dell'acclamato libro sulla progettazione di applicazioni Web accessibili, Apps For All, e ha appena pubblicato un nuovo libro, Componenti inclusivi, tutto su come creare interfacce Web accessibili, ancora una volta, con Smashing Magazine. Quindi è chiaramente un esperto in materia di design accessibile, ma lo sapevi che è stato il primo essere umano maschio a saltare il Sydney Harbour Bridge in un motoscafo? Miei amici Smashing, vi prego di dare il benvenuto a Heydon Pickering. Ciao, Heydon. Come stai?

Heydon Pickering: Sto distruggendo. Sono sul marchio.

Drew: Volevo parlarti oggi dell'argomento del tuo nuovo libro, Componenti inclusivi.

Heydon: Sì.

Drew: Ovviamente solo un titolo di due parole, ma sento che ognuna di queste parole fa un sacco di lavoro pesante. A partire dalla fine, come è ovviamente logico fare, componenti, si tratta di una sorta di progettazione basata sui componenti? Cos'è quello?

Heydon: Sì, quindi suppongo che sia passato un po' di tempo da quando le persone, gli sviluppatori front-end, i designer e tutti coloro che collaborano alla creazione di interfacce, hanno iniziato a pensare alle cose in termini di componenti ea dividere le cose in bocconi digeribili e riutilizzabili. E suppongo che se non hai familiarità con quel modo di lavorare per qualsiasi motivo, è davvero un po' come i componenti elettronici. Mio padre è un ingegnere elettronico. Lavora nel tipo di mondo analogico di circuiti stampati e saldature e tutto quel genere di cose.

Heydon: In effetti, ha realizzato alcuni componenti, componenti molto piccoli, che sono stati usati per regolare la corrente che entra negli elettromagneti al CERN. E da bambino aveva molta fiducia in me, perché mi ha convinto a saldare alcuni pezzi per loro. Penso che quel lotto sia stato ritirato, quindi non preoccuparti della mia scarsa saldatura, della mia scarsa saldatura adolescenziale, del mio coinvolgimento nel CERN. Ma sì, penso che sia analogo a... Oh, ci sono troppi analoghi lì dentro.

Heydon: È analogo ai circuiti stampati analogici in quanto l'idea è che hai responsabilità singole per singole parti o componenti e, insieme, creano il circuito e, insieme, aumentano la corrente nel caso di un circuito o, suppongo, l'interfaccia o il risultato in qualsiasi modo, in un sistema di progettazione o in un'interfaccia manifestata attraverso un sistema di progettazione. E quindi, Componenti inclusivi perché volevo affrontare il fatto che, mentre, intendo dire, l'accessibilità tende a essere lasciata indietro generalmente quando avanziamo in ciò che stiamo facendo in diverse arene, e volevo portare l'accessibilità e, nel più ampio un design sensato e inclusivo per sostenere questo tipo di nuovo modo di pensare e fare le cose usando componenti o moduli o come vuoi chiamarli.

Heydon: Quindi l'idea era di portare l'accessibilità ai sistemi di progettazione, ma allo stesso modo, pensare in modo sistematico quando si tratta di cercare di affrontare l'accessibilità. Pensa a risolvere un tipo di problema in un unico posto in termini di accessibilità e assicurandoti che si propaghi semplicemente attorno al modello [non udibile 00:03:16] il sistema di progettazione in generale.

Drew: In una sorta di senso pratico, che aspetto ha effettivamente lavorare in un modo basato sui componenti? Quale potrebbe essere un esempio di componente?

Heydon: Quindi, ci sono modi diversi di concepire e codificare i componenti. Tendo ad entrare direttamente nel nocciolo della questione, oltre le cose concettuali e penso a come potrei organizzare il codice. In realtà sono arrivato a concentrarmi molto sugli elementi personalizzati, o se non sugli elementi personalizzati, quindi sugli elementi normali ma con una sorta di comportamento JavaScript ad essi collegato in una sorta di modo isolato e componentizzato. Mi piace molto l'idea di componenti interoperabili. E con ciò intendo dire che possono essere utilizzati in diversi framework e sistemi, approcci e stack tecnici. E gli elementi personalizzati sono piacevoli perché sono nativi. Puoi definirli in un posto e quindi potrebbero essere utilizzati, ad esempio, in un'applicazione di reazione o potrebbero essere utilizzati in un'applicazione di visualizzazione o potrebbero essere utilizzati in un'applicazione angolare o qualsiasi tipo di tecnologia di gestione dello stato più ampia tu sia usando.

Heydon: Quindi, per me, di solito un componente sarà probabilmente un elemento personalizzato. Di recente ho lavorato a un progetto che non è tanto incentrato sull'accessibilità, anche se ho cercato di renderlo il più accessibile possibile, chiamato Every Layout, e si tratta di cercare di isolare tipi molto specifici di algoritmi per Disposizione CSS. E sono definiti come elementi personalizzati e in un certo senso si distribuiscono da soli ed eseguono il proprio CSS e funzionano come una sorta di primitive all'interno del sistema più ampio.

Drew: Voglio dire, in termini pratici reali, stiamo parlando che un componente potrebbe essere qualcosa come un campo modulo?

Heydon: Sì, quindi potrebbe essere qualcosa di semplice come un input. Ad esempio, come un input di testo o potrebbe essere qualcosa di complesso come un'interfaccia a schede. E così, l'idea con Inclusive Components era di prendere il concetto di un componente con il suo, si spera, unico scopo, come un input di testo, e poi pensare a tutte le diverse cose che potrebbero inciampare diversi tipi di persone e cercare di evitare loro. Non evitare le persone, evitare i problemi. Non si tratta tanto di includere le persone, ma di cercare di non escludere arbitrariamente le persone.

Heydon: Per me sembra essere il modo più semplice per avvicinarsi a un processo di progettazione inclusivo, è quello di identificare i potenziali elementi di esclusione di qualcosa e cercare di aggirarli. Quindi, con un input di testo, con un'etichetta, hai una serie di cose diverse di cui potresti volerti preoccupare. Quindi, per cominciare, dovresti sapere se è effettivamente etichettato correttamente o meno. Quindi stai usando un elemento label e quell'elemento label punta al campo di testo usando un attributo for in modo che le due cose siano associate a livello di codice in modo che quando un utente di screen reader focalizza l'input, sente effettivamente l'annuncio dell'etichetta? Quindi questa è una cosa da sistemare.

Heydon: Poi, a un livello più visivo, assicurarsi che l'etichetta sia chiaramente associata a quel campo e non a campi diversi, e questa è una questione di spazi bianchi e cose del genere. Inoltre, assicurandoti che l'etichetta non lo sia, non stai facendo qualcosa di stravagante come mettere l'etichetta sotto il loro input del modulo perché quando, ad esempio, quando viene visualizzata una tastiera virtuale, questo potrebbe oscurarsi. Quindi, sta prendendo in considerazione questo genere di cose.

Heydon: assicurarsi che l'input stesso abbia uno stile di messa a fuoco, quindi quando lo si mette a fuoco con una tastiera, che tu sia un utente abituale della tastiera che usa le tastiere per navigare o altro, assicurandosi che sia chiaro dallo stile di messa a fuoco che quello è il input su cui sei concentrato. Assicurarsi che, voglio dire, cose come il completamento automatico, preoccuparsene, se il completamento automatico è appropriato e utile nel contesto o se non lo è. E molte di queste cose affrontano direttamente la disabilità, ma molte sono più ampie in termini di usabilità e semplicemente rendono le cose il più comprensibili possibile.

Heydon: Molto spesso, c'è una sorta di linea sottile o forse una linea sfocata tra ciò che riguarda il tipo di usabilità per tutti e ciò che affronta la disabilità. E poi, per renderlo ancora più difficile da definire, le disabilità cognitive. Quindi, se qualcosa non è molto utilizzabile per qualcuno che non ha disabilità cognitive, sarà ancora più difficile da elaborare ed essere in grado di usarlo per qualcuno che ha questo tipo di sfide.

Heydon: Quindi sta solo cercando di pensare a tutte queste cose in un unico posto. E in realtà, il libro è solo il mio, è il mio processo di pensiero mentre mi avvicino a ciascuno di questi. Quindi l'ho fatto come blog per cominciare. E ogni schema o ogni componente è un post sul blog e il testo sono solo io che dico: "Quindi, affrontiamo ora questo potenziale problema. Come possiamo farlo? Ok, l'abbiamo controllato. Penso che stiamo bene lì". E non sto affatto cercando di dire che questi sono perfetti e che ho pensato a tutto, perché non è possibile.

Drew: Anche l'adozione di un approccio basato sui componenti al modo in cui lavori su singole parti di un'interfaccia, immagino, ti consente di approfondire quel particolare elemento e assicurarti di averlo ottimizzato molto nel migliore dei modi can in modo che sia accessibile a tutti. C'è un pericolo nel farlo e farlo su molti componenti diversi e poi metterli tutti insieme su una pagina? C'è il pericolo che tu possa creare problemi di cui non eri a conoscenza perché li stai testando individualmente e non insieme?

Heydon: Questo è davvero un buon punto, e l'avrei sollevato prima in realtà. Sono felice che tu l'abbia detto. Quindi, in molti modi, penso che, filosoficamente, abbiamo deciso che dobbiamo separare le cose in queste singole componenti. E c'è una virtù nel farlo, perché se è isolato, è più facile testarlo e considerarlo come un'unica cosa. E puoi in qualche modo, in termini di modo in cui lavoriamo, rendere le cose più facili da gestire. Dobbiamo anche considerare il fatto che queste cose alla fine devono condividere lo stesso spazio e unirsi in un sistema più ampio.

Heydon: E non credo, in realtà, abbastanza del nostro sforzo e del nostro pensiero vada in questo, abbastanza buffamente. Penso che componentizziamo maggiormente le cose per semplificare la nostra vita di ingegneri, in modo da sapere su cosa stiamo lavorando ea che ora. E, ma poi, spesso trascuriamo il fatto che queste cose vivranno in sistemi dinamici e devono essere...

Heydon: Voglio dire, il progetto Every Layout, sebbene riguardi più il design visivo e il layout, riguarda il tentativo di creare queste piccole primitive CSS, queste piccole primitive di layout, in modo tale che possano autogestire algoritmicamente. È così che puoi estrarli da una colonna stretta e metterli poi in una colonna larga e poi sarà, il codice stesso determinerà quanti elementi dovrebbero esserci o se dovrebbe riconfigurarsi in qualche altro modo. Perché non possiamo permetterci di intervenire costantemente, e deve essere un sistema che sia una specie di autoconoscenza e intelligente, credo.

Heydon: Ci sono sempre cose di cui puoi dimenticare. Quindi forse crei un'interfaccia a schede, hai una riga di schede, scegli tra la scheda e la scheda corrisponde a un pannello a schede, che apre qualcosa. E poi, qualcuno arriverà e dirà: "Beh, e se volessi inserire un'interfaccia a schede all'interno di un'interfaccia a schede o qualche altro componente all'interno di un'interfaccia a sfioramento?"

Heydon: E ovviamente, voglio dire, è in parte una questione tecnica se ciò sia possibile, ma sì, devi scegliere se rendere le cose il più flessibili possibile in modo che sia possibile ordinare le cose in un modo complesso, o semplicemente scrivere regole rigide che dicono: "Non puoi mettere qualcosa qui dentro perché il livello di complessità in termini di codice sarebbe probabilmente troppo alto, ma forse anche in termini di come l'utente può percepire e utilizzare la cosa." Sono tutto per la scrittura di regole che dicono: "Non annidare un sacco di funzionalità complesse al suo interno", perché è semplicemente improbabile che le persone siano in grado di capirlo, davvero.

Drew: È possibile adottare un approccio completamente algoritmico o automatizzato alla progettazione per l'accessibilità?

Heydon: Non credo. No. Quindi abbiamo strumenti automatizzati e non voglio in alcun modo denigrare gli strumenti automatizzati. Penso che siano molto utili, ma li uso come un sistema di allerta precoce per cercare di avere un'idea di dove siano le aree problematiche. Quindi, se dovessi fare un audit per un'organizzazione che voleva qualche consiglio su come rendere i propri prodotti più accessibili. Quindi è un buon tipo di finanziamento dove si trovano le aree problematiche, ma voglio dire, puoi avere un'interfaccia che è tecnicamente accessibile al 100%, forse, secondo alcuni strumenti, anche un buon strumento per giudicarla, diciamo, contro WCAG , le linee guida per l'accessibilità dei contenuti Web o altre specifiche di accettazione. E, anche se è una sorta di 100% di tutte le caselle selezionate, può comunque essere del tutto inutilizzabile per vari motivi.

Heydon: Per esempio, tornando a quello che dicevamo prima, può essere del tutto troppo complesso. Puoi semplicemente sopraffare qualcuno con i collegamenti e semplicemente non c'è modo che siano in grado di superarlo e poi diventa, è una cosa molto tacita e difficile da definire, ma è destinato solo ad alienare le persone. Ma c'è anche, puoi ottenere, è molto facile ottenere falsi positivi e cose del genere. Ho avuto una cosa l'altro giorno, l'ho detto l'altro giorno, era l'altro mese, stavo lavorando per un'organizzazione e ovviamente volevano avere una scuola faro accessibile al 100% e c'era un iframe che è stato inserito dinamicamente da un copione analitico o qualcosa del genere. Sai il genere di cose in cui è una sorta di codice leggermente grossolano, che viene semplicemente buttato nella pagina per svolgere un'attività del genere.

Heydon: Ora consiglierei di non utilizzare affatto l'analisi e ho raccomandato loro di supportare almeno il protocollo di non tracciabilità in modo che le persone potessero rinunciare. Sfortunatamente, quel protocollo non funziona più perché non è mai stato supportato correttamente. Ma questo iframe diceva che non aveva un titolo. Quindi l'idea è che se si dispone di un iframe, dovrebbe avere un attributo title perché questo è il modo migliore per identificare a cosa serve l'iframe per un utente di screen reader. Ma questo era un iframe che era anche impostato per non visualizzare nessuno, quindi non era nemmeno percepibile da uno screen reader in primo luogo perché non visualizzava nessuno, proprio come nasconde le cose visivamente in uno screen reader, essenzialmente lo rimuoverà dal interfaccia, quindi non verrà rilevato o annunciato in alcun modo.

Heydon: Quindi era un falso positivo. Voglio dire, mi stava chiedendo di identificare un iframe che non era lì per essere percepito in primo luogo. Quindi, ci saranno sempre questo tipo di errori e problemi nei test automatizzati. Ma alla fine, si tratta di sapere, anche se è solo una specie di cosa in cui i programmatori, suppongo, non amano pensare di essere coinvolti e lo trovano un po' fastidioso, ma riguarda il comportamento umano e come le persone capiscono le cose ed è una cosa molto difficile avere solo una serie di regole binarie o booleane.

Heydon: Quindi, voglio dire, ho parlato con uno sviluppatore quando stavo consultando questo argomento qualche tempo fa e continuavano a dire: "Beh, finché abbiamo test automatizzati, va tutto bene, vero? È solo che allora possiamo semplicemente andare avanti". E ho detto: "Devi ancora testare manualmente. Non esiste un test automatizzato che possa davvero dirti se l'utilizzo dell'interfaccia tramite tastiera è impossibile in un modo o nell'altro". Ci sono una sorta di cose discrete che puoi cercare, ma l'esperienza complessiva è ancora qualcosa che deve essere giudicata dall'essere umano. Sì.

Drew: A volte il pericolo con gli strumenti automatizzati è che guardano gli elementi in isolamento o guardano un'interfaccia in isolamento e non vedono il contesto più ampio.

Heydon: Sì.

Drew: Sicuramente usando il faro per i controlli delle prestazioni, a volte potrei prendere una decisione come sviluppatore da includere, potrebbero esserci molti più CSS di quelli usati in quella pagina e, a rigor di termini, sto scaricando troppi CSS, ma in realtà , So che una volta caricato quel file, quando l'utente passa alla pagina successiva, ha già il CSS. Quindi è un'ottimizzazione che viene effettuata su più pagine che lo strumento, guardando una pagina isolatamente, vede come un errore.

Heydon: Sì, assolutamente. Stai pensando al futuro e stai facendo una chiamata di giudizio, e fino a quando non arriviamo all'IA avanzata per anticiparlo, allora sì, hai davvero bisogno che gli esseri umani lo guardino, lo affrontino e se ne vadano... Voglio dire, quindi i test automatizzati dovrebbero essere in atto, come ho detto, una sorta di sistema di allerta precoce, sistema diagnostico, ma dovrebbe anche esserci, se sei interessato a che la tua organizzazione si prenda davvero cura e renda le cose più inclusive e più accessibili, ci deve essere anche formazione . Ci devono essere domande e risposte.

Heydon: Quindi scriverei script per "Ecco come dovrebbe funzionare quando interagisci con questo componente con una tastiera" oppure "Così è come dovrebbe funzionare quando interagisci con esso con un lettore di schermo e non effettivamente passi attraverso esso. Quindi, quando lo fai, dovrebbe succedere. Quando lo fai, dovrebbe succedere. Quando lo fai, dovrebbe apparire questo "o quel genere di cose. Quindi, e del tipo di viaggio, come dici tu, gli strumenti automatizzati non ne sono consapevoli. Vedono solo "Oh, questo non ha un testo alternativo qui". E in realtà, in molti casi, forse non dovrebbe avere il testo alternativo. Inoltre, non può giudicare se hai scritto bene o meno il testo alternativo. Quindi penso che un'immagine senza tutto il testo alternativo sia probabilmente migliore di un'immagine con testo alternativo fuorviante o semplicemente errato. E questa è di nuovo una chiamata di giudizio, non è vero?

Drew: Una delle cose con cui ho lottato, storicamente, nel costruire le cose in un modo accessibile è mantenere aggiornata la mia conoscenza delle migliori pratiche perché ogni volta che faccio riferimento a qualsiasi documentazione o consiglio, sembra quello che stavo facendo e pensavo di fare la cosa giusta, i consigli sono andati avanti e ora dovrei fare qualcos'altro. E questa è una storia familiare con tutte le aree di lavoro sul web. Ma penso che il pericolo sia, ovviamente, con i problemi di accessibilità, è che, se non stai seguendo la migliore pratica, se lasci qualcosa nella tua interfaccia che ora non è una buona pratica, ciò potrebbe influire negativamente sui tuoi utenti strada. Un approccio basato sui componenti alla creazione di un'interfaccia o di un sito aiuta in qualche modo?

Heydon: Penso puramente nel senso che, poiché hai un componente che poi, l'idea ovviamente in tutti i casi e non solo in termini di accessibilità, è che hai questo componente definito in un posto che verrà poi utilizzato in diversi luoghi, almeno quando cambiano gli aspetti o il supporto del browser o qualunque cosa sia e vuoi aggiornare il componente, devi solo farlo in un posto e quindi ovunque venga utilizzato, quel miglioramento o quel cambiamento si sentirà. Quindi, da questo punto di vista, penso che sia sicuramente più utile avere le cose divise in componenti.

Heydon: Ma poi, sì, come ho detto, ciò non riguarda solo l'accessibilità, ma può influenzare qualsiasi cosa cambi. Ma poi, non sono sicuro di quanti cambiamenti ci siano... Voglio dire, ci saranno pochi cambiamenti di rilievo in termini di accessibilità all'HTML, che è, ovviamente, un'area molto ristretta. Ma in termini di qualità del codice o di come funziona il codice, le cose vengono introdotte nelle specifiche HTML, ovviamente, molto lentamente e non altrettanto lentamente ma abbastanza lentamente anche nelle specifiche ARIA. E poi, gran parte di ARIA rispecchia comunque ciò che è nell'HTML di base sottostante.

Heydon: Penso che, più della tecnologia, la percezione e la comprensione di queste cose tenda a cambiare nel tempo. Voglio dire, recentemente, nel sondaggio WebAIM di recente, hanno identificato i siti che utilizzavano ARIA erano più inaccessibili dei siti che non lo utilizzavano. Quindi questa tecnologia concepita appositamente per aiutare le persone a rendere i siti Web più accessibili, stava peggiorando le cose. Quindi è davvero, è solo una lacuna di conoscenza, non una lacuna tecnologica o una carenza tecnologica. Sono le persone che prendono la tecnologia e la usano in modo improprio perché non hanno davvero capito come dovrebbe funzionare, sfortunatamente. Si spera che alcuni dei miei scritti potrebbero essere in grado di aiutare in questo. In alcune zone, comunque.

Drew: Ma una sorta di sistema basato sui componenti ben strutturato ti consentirebbe, una volta che ti rendi conto che qualcosa non è aggiornato o che hai preso una decisione sbagliata e ora lo sai meglio, ti consentirebbe di entrare più facilmente e aggiustarlo nell'applicazione.

Heydon: Sì, esattamente. Sì, sì, assolutamente. Voglio dire, è tutta una questione di efficienza, vero? E questo principio arido o quello che hai, e vedi, è per questo che all'inizio ero molto entusiasta di questa opportunità, perché le persone si lamentano sempre che rendere le cose accessibili è un lavoro extra ed è difficile, sconvolgente e tutto il resto. E così, è stata una specie di opportunità per dire: "Beh, sai come stai facendo davvero questa roba, costruendo in modo efficiente questi sistemi di componenti? Ottieni la tua accessibilità lì per quell'unico componente che stai realizzando, e quindi non devi più preoccuparti dell'accessibilità a parte il cambio o l'aggiornamento delle specifiche occasionali o quello che hai. "

Heydon: O semplicemente, voglio dire, probabilmente la maggior parte delle volte, l'iterazione sarà semplicemente basata sul feedback degli utenti e sulla ricerca in corso, che, ovviamente, dovresti condurre, per quanto possibile, con un gruppo eterogeneo di persone. Quindi, dovresti ottenere persone che utilizzano dispositivi diversi e hanno abitudini di navigazione diverse e utilizzano tecnologie assistive diverse e quel genere di cose. E sai, le cose sono destinate a venire fuori tutto il tempo. Penso di aver davvero fissato un componente, penso che sia davvero solido come una roccia, e poi faccio un po' di ricerca e scopro di aver fatto delle ipotesi piuttosto negative. Ma sì, con un sistema di componenti devi solo ripararlo in un posto.

Drew: Un componente può mai essere completamente inclusivo o è uno spettro in cui stai solo lavorando sempre di più verso l'inclusività?

Heydon: Sì, sarebbe possibile che un componente fosse, in termini di WCAC, esente da errori, soddisfa tutti i criteri WCAC, ma come ho detto, questo ti porta solo così lontano e potrebbe essere ancora del tutto inutilizzabile o impossibile da capire anche con quei criteri tecnici soddisfatti. Quindi sì, è qualcosa di cui parlo molto. Cerco di convincere le persone che l'accessibilità è come qualsiasi altra area del design, è solo una parte del processo di progettazione e nulla può essere perfettamente progettato proprio come nulla può essere perfettamente accessibile. Penso che, sfortunatamente, molte persone ci pensino solo in termini di assicurarsi che sia compatibile con gli screen reader, che ovviamente è un ambito molto ristretto in termini di accessibilità e inclusione in generale.

Heydon: Quindi, ci saranno persone con cui, alcune brave persone con cui ho lavorato come al Gruppo Paciello, direbbero: "Beh, in realtà, voglio essere conosciuto come una persona UX accessibile". Quindi non si tratta solo di questo esercizio di spuntare le caselle, si tratta più di cercare effettivamente di rendere l'esperienza migliore e più preziosa per il maggior numero di persone e di spostarsi maggiormente verso una sorta di principi più ampi e cose che sono meno binarie. Ma alla fine, è tutto questo, e WCAC e altri criteri simili possono solo identificare il vero duro e veloce, "Questo è sbagliato", suppongo.

Drew: Quindi, se sono uno sviluppatore, cosa dovrei fare in modo diverso quando mi avvicino al modo in cui progetto, pianifico e costruisco un componente? C'è qualcosa che dovrei considerare nel mio lavoro per assicurarmi che quel componente finisca per essere il più inclusivo possibile?

Heydon: Quindi, voglio dire, a seconda di cosa stai costruendo, ci saranno diversi criteri che devono essere soddisfatti. Quindi, ad esempio, non tutti i componenti avranno le immagini accessibili con testo alternativo, perché potrebbero non utilizzare affatto le immagini. Potrebbe essere solo basato su testo o cosa hai. Alcuni potrebbero non essere interattivi. Quindi, in termini di requisiti specifici, quindi, cambierebbe tra i componenti, ma si spera che ciò che alcuni dei miei scritti e ciò che il libro Componenti inclusivi ti aiuta a fare è cadere o adottare una disciplina del solo pensiero inclusivo.

Heydon: Quindi, quando ti avvicini a queste cose, non solo pensando, beh, fondamentalmente semplicemente uscendo dalla mentalità "Se funziona per me, probabilmente funziona per tutti gli altri", perché semplicemente non è il caso che il nel modo in cui tu o io sfogliamo le cose, voglio dire, probabilmente faremo le cose in modo completamente diverso, solo noi due, giusto?

Drew: Giusto.

Heydon: E noi siamo occidentali, bianchi, inglesi come persone di prima lingua. E quindi, sì, la quantità di diversità in termini di persone che consumano questo, intendo dire che anche le persone delle prestazioni ne parlano sempre, le persone che sono interessate a sostenere prestazioni migliori. Sei abituato a utilizzare una specifica elevata impostata su una buona rete e molti dei tuoi utenti o molti dei tuoi potenziali utenti non lo saranno certamente, e lo stesso vale per l'accessibilità. È solo una questione di, fondamentalmente, uscire dal pensare a te stesso, davvero. Letteralmente proprio questo. E cercando, ovviamente, di andare oltre i tuoi colleghi immediati e anche le persone del tuo stesso gruppo sociale.

Heydon: Quindi, si spera, è davvero solo, "Ecco cosa ho risolto per questa roba" e cosa stavo pensando in quel momento. Puoi riutilizzare alcune di queste idee e applicare esattamente ciò che ho applicato, se è utile o rilevante per te. Si spera che il libro riguardi più semplicemente: “Ecco un caso di studio di una persona che cerca di pensare in modo inclusivo. Vedi, il tipo di cose a cui stavano pensando, quando stai progettando qualcosa di completamente diverso, forse impiega semplicemente lo stesso tipo di pensiero e prova ad aprire la tua mente alla diversità degli utenti e al modo in cui affrontano le cose".

Drew: Quindi il libro stesso, come hai deciso come strutturarlo? Sembra molto ferocemente pratico, cosa che mi piace in un libro, ma come l'hai strutturato?

Heydon: Molto simile al libro precedente, in realtà era Inclusive Design Patterns e ho avuto molti problemi con quel libro, all'inizio, perché ho cercato di organizzarlo in termini di criteri astratti. Così ho iniziato a fare un capitolo incentrato sull'accessibilità della tastiera, ma è stato molto difficile perché poi ho dovuto in qualche modo, ogni volta che parlavo di un diverso tipo di accessibilità della tastiera o delle cose a cui devi pensare, poi ho ha dovuto evocare una sorta di componente e poi abbandonare quel componente e poi passare a qualcos'altro.

Heydon: E quindi, per me aveva più senso organizzare le cose in termini di componenti stessi. Quindi, Inclusive Design Patterns fa questo e ora Inclusive Components è davvero solo una continuazione, che copre solo diversi componenti. È diverso in quanto, in termini di funzionalità, è un po' diverso perché include anche esempi di codice live e cose che non ho fatto molto per i libri precedenti. Ma sì, è letteralmente solo "Faremo questo componente", che si tratti di un'interfaccia di tocco o di una sezione pieghevole o di un commutatore di temi o di una scheda flash di notifica o di un tostapane o come si chiamano, e poi proprio tutto viene quindi organizzato attorno a quel componente.

Heydon: Quindi è "Questo è quello che stiamo facendo e queste sono le cose che dovremmo considerare mentre lo facciamo per essere più inclusivi", perché è così che lavoro io ed è così che lavorano le altre persone. E non appena ho iniziato a farlo in quel modo, ero davvero solo io a lavorare e scrivere appunti mentre lavoravo. E così, la cosa in un certo senso si è scritta da sola, e quindi tutto lo sforzo è stato davvero solo per assicurarmi che stessi facendo un lavoro decente per rendere quelle cose non inaccessibili, immagino.

Drew: Sì, voglio dire che il sommario si legge quasi come documentazione o come un manuale di auto-aiuto o qualcosa del genere. Direttamente con il capitolo uno, pulsanti di commutazione. Se vuoi implementare alcuni pulsanti di commutazione, vai a questo capitolo, leggilo e otterrai tutto ciò che devi sapere su come farlo, che è un approccio che mi piace molto. Vedo cose come sezioni comprimibili, interfaccia a schede, interruttori a tema, tabelle di dati, un sacco di cose reali e pratiche che tutti noi costruiamo ogni giorno e penso che tutti, probabilmente, potremmo costruire meglio.

Heydon: Sì, era proprio l'idea perché non si trattava solo di me che creavo i miei componenti, era un caso, e l'hai toccato lì, cosa che sono felice che tu l'abbia fatto, che è stato quello di identificare i comuni modelli che tutti usiamo. Quindi voglio dire, ci sono interfacce a schede ovunque e sono tutte implementate in modo diverso e sono tutte implementate, in modo diverso, molto male. Voglio dire, ho implementato terribili interfacce a schede e ho imparato un po' di quanto fossero dannose per le persone, e poi ho cercato di renderle un po' migliori e un po' migliori e un po' migliori. Probabilmente ho realizzato 15 o 16 versioni diverse di interfacce a schede ai miei tempi, facendo questo genere di cose da anni ormai.

Heydon: E sai, stanno migliorando un po', si spera, ogni volta. Ma è solo una cosa comune. Era una cosa comune che usavo abbastanza spesso tra diversi siti web, che uso e che tutti usano. Quindi, parte dell'idea era dire: "Beh, in realtà, facciamo un sistema di progettazione, una specie di sistema di progettazione accessibile per il web". Ora, le persone si espanderanno e faranno le proprie versioni di queste cose, ma in qualche modo ridurre le cose fondamentali e l'accessibilità è una cosa fondamentale che dovrebbe essere nelle cose. Non dovrebbe essere un componente aggiuntivo, non dovrebbe essere neanche/o, non dovrebbe essere una funzionalità. Dovrebbe essere una cosa fondamentale. E se abbini le cose fondamentali, allora sì, si spera che le persone guardino i capitoli e dicano: "Oh, ok, li ho fatti. quelli li ho visti. Vediamo come farlo nel modo più inclusivo possibile”, e poi si spera che ne traggano un certo valore.

Drew: Beh, quello che mi piace è che sicuramente so di aver avuto, in passato, alcune funzionalità dell'interfaccia che dovevo implementare e so che sarà complicato dal punto di vista dell'accessibilità , diciamo una sorta di menu a comparsa, menu a discesa, qualcosa del genere. Penso: "Va bene, qui ci sono i draghi in termini di accessibilità. Devo assicurarmi di farlo bene". E così, cerco su Google come farlo, trovo una fonte attendibile che dice: "Usa questo metodo", uso quel metodo, lo implemento e vado avanti, ma in realtà non ho imparato nulla. Non ho capito perché la soluzione fosse quella. E quello che mi piace davvero del modo in cui lo affronti nel libro è che posso fare due cose contemporaneamente. Posso capire come dovrei farlo e posso capire perché dovrei farlo in quel modo perché è tutto spiegato molto accuratamente. Quindi, penso che sia davvero un successo da quel punto di vista.

Heydon: Oh, fantastico. Era quello che stavo cercando. Quindi va bene. But yeah, that seems to be my thing. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Sì.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.