Smashing Podcast Episodul 4 cu Heydon Pickering: Ce sunt componentele incluzive?

Astăzi, vorbesc cu Heydon Pickering despre noua sa carte, Inclusive Components . Heydon este cunoscut pentru munca sa și a scris despre accesibilitate – deci ce înseamnă de fapt „Design inclusiv” și unde intră în joc componentele? Heydon explică toate acestea și multe altele în acest episod. Puteți să ascultați mai jos sau să vă abonați de oriunde obțineți podcasturile.

Afișați note

• Cartea Componente inclusive din Smashing Magazine
• Proiectul lui Heydon Every Layout cu Andy Bell
• Site-ul lui Heydon Heydonworks
• Heydon pe Twitter

Transcriere

Drew McLellan: Este un consultant independent de accesibilitate web, designer de interfețe și scriitor. Munca sa se concentrează pe designul experienței utilizatorului accesibil, precum și pe scrierea și editarea pentru Smashing Magazine. El este autorul celebrei cărți despre designul de aplicații web accesibile, Apps For All, și tocmai a lansat o nouă carte, Inclusive Components, despre cum să construiești interfețe web accesibile, din nou, cu Smashing Magazine. Deci este clar un expert în tema designului accesibil, dar știai că a fost primul bărbat bărbat care a sărit Podul Sydney Harbour cu o barcă cu motor? Prietenii mei Smashing, vă rog bun venit lui Heydon Pickering. Bună, Heydon. Ce mai faci?

Heydon Pickering: Sunt zdrobitor. Sunt pe brand.

Drew: Am vrut să vă vorbesc astăzi despre subiectul noii dvs. cărți, Inclusive Components.

Heydon: Da.

Drew: Evident, doar un titlu de două cuvinte, dar simt că fiecare dintre aceste cuvinte are o mulțime de lucruri grele. Începând de la sfârșit, așa cum este evident logic să facem, componente, este vorba despre un fel de design bazat pe componente? Ce este asta?

Heydon: Da, deci presupun că a trecut ceva timp de când oamenii, dezvoltatorii front-end, designerii și toți cei care colaborează la realizarea de interfețe, au început să se gândească la lucruri în termeni de componente și să împartă lucrurile în bucăți digerabile și reutilizabile. Și presupun că dacă nu ești familiarizat cu acest mod de lucru din orice motiv, într-adevăr este un pic ca componentele electronice. Tatăl meu este inginer electronic. Lucrează într-un fel de lume analogică a plăcilor de circuite și lipirii și tot felul de lucruri.

Heydon: De fapt, el a făcut niște componente, componente foarte mici, care au fost folosite pentru a regla curentul care intră în electromagneți la CERN. Și a avut multă încredere în mine când eram copil, pentru că m-a făcut să lipim unele dintre bucăți pentru ele. Cred că acel lot a fost acum retras, așa că nu vă faceți griji cu privire la lipirea mea proastă, lipirea mea proastă din adolescență, să mai fiu implicat în CERN. Dar da, cred că este analog cu... Oh, sunt prea mulți analogi acolo.

Heydon: Este analog plăcilor de circuite analogice prin faptul că ideea este că aveți responsabilități unice pentru părțile sau componentele individuale și, împreună, ele formează circuitul și, împreună, măresc curentul în cazul unui circuit sau, presupun, interfața sau rezultatul în orice fel, într-un sistem de proiectare sau într-o interfață, așa cum se manifestă printr-un sistem de proiectare. Așadar, Componente inclusive pentru că am vrut să abordez faptul că, în timp ce, vreau să spun, accesibilitatea tinde să fie lăsată în urmă în general atunci când avansăm ceea ce facem în diferite arene și am vrut să aduc accesibilitate și, în general, sens, design cuprinzător pentru acest tip de mod nou de a gândi și de a face lucruri folosind componente sau module sau cum doriți să le numiți.

Heydon: Așadar, ideea a fost să aducem accesibilitatea sistemelor de proiectare, dar, în același sens, să gândim sistemic când vine vorba de încercarea de a aborda accesibilitatea. Gândiți-vă la rezolvarea unui fel de problemă într-un singur loc în ceea ce privește accesibilitatea și asigurați-vă că pur și simplu se propagă în jurul modelului [inaudible 00:03:16] sistemului de proiectare în general.

Drew: Într-un fel de sens practic, cum arată de fapt să lucrezi într-un mod bazat pe componente? Care ar putea fi un exemplu de componentă?

Heydon: Deci, există moduri diferite de a concepe și de a codifica componentele. Am tendința să intru direct în niște chestii de fond, să trec de lucrurile conceptuale și să mă gândesc la cum aș putea organiza codul. De fapt, am ajuns să mă concentrez foarte mult pe elemente personalizate, sau dacă nu pe elemente personalizate, atunci pe elemente normale, dar cu un fel de comportament JavaScript atașat acestora într-un fel izolat, component. Îmi place foarte mult ideea componentelor care sunt interoperabile. Și prin asta, vreau să spun că pot fi utilizate în diferite cadre și sisteme și abordări și stive tehnice. Și elementele personalizate sunt frumoase în asta pentru că sunt native. Le puteți defini într-un singur loc și apoi ar putea fi utilizate, să zicem, într-o aplicație de reacție sau ar putea fi utilizate într-o aplicație de vizualizare sau ar putea fi utilizate într-o aplicație unghiulară sau orice fel de tehnologie de management de stat mai mare pe care o utilizați folosind.

Heydon: Deci, pentru mine, de obicei, o componentă va fi probabil un element personalizat. Am lucrat recent la un proiect care nu este atât de axat pe accesibilitate, deși am încercat să-l fac cât mai accesibil posibil, numit Every Layout, și totul se referă la un fel de încercare de a izola anumite tipuri de algoritmi pentru Aspect CSS. Și sunt definite ca elemente personalizate și un fel de ele se instalează singure și își rulează propriul CSS și funcționează ca niște primitive în cadrul unui sistem mai mare.

Drew: Adică, în termeni practici efectivi, vorbim că o componentă ar putea fi ceva ca un câmp de formular?

Heydon: Da, deci ar putea fi ceva la fel de simplu ca o intrare. Să spunem, ca o introducere de text sau ar putea fi ceva complex, cum ar fi o interfață cu file. Și așa, ideea cu Componentele incluzive a fost să luăm conceptul de o componentă cu scopul său, sperăm, unic, cum ar fi o introducere de text, și apoi să ne gândim la toate lucrurile diferite care ar putea împiedica diferite tipuri de oameni și să încerce să evite. lor. Nu evita oamenii, evita problemele. Nu este vorba atât de a include oameni, ci de a încerca să nu excludeți în mod arbitrar oamenii.

Heydon: Acesta pare a fi cel mai simplu mod de a aborda un proces de design incluziv pentru mine, este să identific într-un fel potențialele elemente de excludere a ceva și să încerc să le ocolesc. Deci, cu o introducere de text, cu o etichetă, aveți o serie de lucruri diferite de care ați putea dori să vă faceți griji. Deci, pentru început, ai avea de gând dacă este sau nu etichetat corect. Deci utilizați un element de etichetă și acel element de etichetă indică către câmpul de text folosind un atribut pentru, astfel încât cele două lucruri să fie asociate programatic, astfel încât atunci când un utilizator de cititor de ecran concentrează intrarea, să audă de fapt eticheta anunțată? Deci ăsta e un lucru pe care trebuie să-l corectezi.

Heydon: Apoi, la un nivel mai vizual, asigurându-vă că eticheta este asociată în mod clar cu acel câmp și nu cu un câmp diferit, și asta este o problemă de spațiu alb și chestii de genul ăsta. De asemenea, asigurându-vă că eticheta nu este, nu faceți ceva fantezist, cum ar fi să puneți eticheta sub introducerea formularului, pentru că atunci când, de exemplu, când apare o tastatură virtuală, aceasta ar putea deveni ascunsă. Deci, se ia în considerare astfel de lucruri.

Heydon: Asigurați-vă că intrarea în sine are un stil de focalizare, așa că atunci când o focalizați cu o tastatură, indiferent dacă sunteți un utilizator obișnuit de tastatură care folosește tastaturi pentru a naviga sau altfel, asigurându-vă că din stilul de focalizare este clar că acesta este intrare pe care vă concentrați. Asigurându-mă că, vreau să spun, lucruri precum completarea automată, îngrijorarea pentru asta, dacă completarea automată este adecvată și utilă în context sau dacă nu este. Și multe dintre aceste lucruri se referă direct la dizabilități, dar multe dintre ele sunt mai largi în ceea ce privește utilizarea și doar fac lucrurile cât mai ușor de înțeles posibil.

Heydon: Destul de des, există un fel de linie subțire sau poate o linie neclară între ceea ce se adresează unui fel de utilizare pentru toată lumea și ceea ce se adresează dizabilității. Și apoi, pentru a face și mai dificil de identificat, dizabilitățile cognitive. Deci, dacă ceva nu este foarte utilizabil pentru cineva care nu are dizabilități cognitive, atunci va fi și mai dificil de rezolvat și de utilizat pentru cineva care are astfel de provocări.

Heydon: Deci încercăm să mă gândesc la toate acele lucruri într-un singur loc. Și într-adevăr, cartea este doar al meu, este procesul meu de gândire pe măsură ce mă apropii de fiecare dintre acestea. Așa că am făcut-o ca pe un blog pentru început. Și fiecare model sau fiecare componentă este o postare pe blog, iar textul este doar eu spunând: „Deci, acum să abordăm această problemă potențială. Cum facem asta? Bine, l-am bifat pe acela. Cred că suntem bine acolo.” Și, în niciun caz, nu încerc să spun că acestea sunt perfecte și că m-am gândit la toate, pentru că nu se poate.

Drew: La fel și luarea unei abordări bazate pe componente a modului în care lucrezi pe părți individuale ale unei interfețe, cred că îți permite să mergi cu adevărat în profunzime asupra aceluiași articol și să te asiguri că l-ai optimizat foarte mult în cel mai bun mod în care ai poate astfel încât să fie accesibil tuturor. Există un pericol în a face asta și a face asta pe o mulțime de componente diferite și apoi a le pune pe toate împreună pe o pagină? Există pericolul că puteți crea probleme de care nu erați conștient, deoarece le testați individual și nu împreună?

Heydon: Acesta este un punct foarte bun și, de fapt, aveam de gând să-l vorbesc mai devreme. Mă bucur că ai spus asta. Deci, în multe feluri, cred că, din punct de vedere filozofic, am decis că trebuie să separăm lucrurile în aceste componente individuale. Și există o virtute în a face asta, pentru că dacă este izolat, atunci este mai ușor de testat și de tratat ca un singur lucru. Și puteți oarecum, în ceea ce privește modul în care lucrăm, face lucrurile mai ușor de gestionat. Trebuie să luăm în considerare, de asemenea, faptul că aceste lucruri trebuie să împartă în cele din urmă același spațiu și să se unească într-un sistem mai mare.

Heydon: Și nu cred că, de fapt, efortul și gândurile noastre sunt suficiente în asta, destul de amuzant. Cred că componem lucrurile mai mult pentru a ne ușura viața ca ingineri, astfel încât să știm la ce lucrăm la ce oră. Și, dar apoi, neglijăm adesea faptul că aceste lucruri vor trăi în sisteme dinamice și trebuie să fie...

Heydon: Adică, proiectul Every Layout, deși este mai mult despre design vizual și despre aspect, este totul despre încercarea de a face aceste mici primitive CSS, aceste mici primitive de layout, în așa fel încât să se poată auto-gestiona algoritmic. Este astfel încât să le puteți scoate dintr-o coloană îngustă și să le puneți apoi într-o coloană largă și apoi va fi, codul însuși va determina câte elemente ar trebui să existe sau dacă ar trebui să se reconfigureze într-un alt mod. Pentru că nu ne putem permite să intervenim în mod constant și trebuie să fie un sistem care este un fel de autocunoaștere și inteligent, cred.

Heydon: Întotdeauna sunt lucruri de care poți uita. Deci poate faci o interfață cu file, ai un rând de file, alegi între filă și fila corespunde unui panou cu file, care deschide ceva. Și apoi, cineva va veni și va spune: „Ei bine, ce se întâmplă dacă vreau să pun o interfață cu filă într-o interfață cu filă sau o altă componentă într-o interfață prin atingere?”

Heydon: Și, desigur, vreau să spun, este parțial o preocupare tehnică dacă acest lucru ar fi posibil, dar da, trebuie să alegeți dacă veți face lucrurile cât mai flexibile posibil, astfel încât să fie este posibil să împachetați lucrurile într-un mod complex sau pur și simplu să scrieți reguli stricte care spun: „Nu puteți pune ceva înăuntru aici, deoarece nivelul de complexitate în ceea ce privește codul ar fi probabil prea mare, dar, eventual, în ceea ce privește modul în care utilizatorul poate percepe și utiliza lucrul.” Sunt total pentru a scrie reguli care spun: „Nu înghesuiți o mulțime de funcționalități complexe în sine”, pentru că este puțin probabil ca oamenii să reușească să înțeleagă asta, într-adevăr.

Drew: Este posibil să adoptăm o abordare complet algoritmică sau automatizată a proiectării pentru accesibilitate?

Heydon: Nu cred. Nu. Deci avem instrumente automate și nu vreau să disprețuiesc instrumentele automate în niciun fel. Cred că sunt foarte utile, dar le folosesc ca un fel de sistem de avertizare timpurie pentru a încerca să îmi fac o impresie despre unde sunt zonele cu probleme. Deci, dacă făceam un audit pentru o organizație care dorea niște sfaturi despre cum să-și facă produsele mai accesibile. Deci, este o modalitate bună de finanțare acolo unde sunt zonele cu probleme, dar vreau să spun, puteți avea o interfață care este 100% accesibilă din punct de vedere tehnic, poate, potrivit unui instrument, chiar un instrument bun pentru a o judeca, să zicem, împotriva WCAG. , regulile de accesibilitate a conținutului web sau alte specificații de acceptare. Și, chiar dacă este un fel de 100% din toate casetele bifate, poate fi totuși complet inutilizabil din diverse motive.

Heydon: De exemplu, revenind la ceea ce spuneam înainte, poate fi cu totul prea complex. Poți pur și simplu copleși pe cineva cu legături și pur și simplu nu există nicio modalitate ca acesta să poată trece prin asta și apoi asta devine, este un fel de lucru tacit și dificil de stabilit, dar este obligat să înstrăineze oamenii. Dar există și, puteți obține, este foarte ușor să obțineți false pozitive și lucruri de genul ăsta. Am avut o chestie zilele trecute, am spus zilele trecute, era luna cealaltă, lucram pentru o organizație și, desigur, ei doreau să aibă o școală far 100% accesibilă și a fost un iframe care a fost introdus acolo dinamic printr-un scenariu analitic sau ceva. Știți genul de lucru în care este un fel de cod ușor grosolan, care este doar aruncat în pagină pentru a face o astfel de activitate.

Heydon: Acum aș recomanda să nu folosiți deloc analitice și le-am recomandat să accepte cel puțin protocolul de nu urmărire, astfel încât oamenii să poată renunța. Din păcate, protocolul respectiv nu mai funcționează, deoarece nu a fost niciodată susținut corespunzător. Dar acest iframe spunea că nu are un titlu pe el. Deci, ideea este că, dacă aveți un iframe, ar trebui să aibă un atribut de titlu, deoarece acesta este cel mai bun fel de mod de lungă durată de a identifica pentru un utilizator de cititor de ecran pentru ce este iframe. Dar acesta a fost un iframe care, de asemenea, a fost setat să nu afișeze niciunul, așa că nici măcar nu a fost perceptibil de un cititor de ecran, în primul rând, deoarece nu afișa niciunul, așa cum ascunde vizual lucrurile într-un cititor de ecran, îl va elimina în esență din ecran. interfață, deci nu va fi întâlnită sau anunțată în niciun fel.

Heydon: Deci a fost un fals pozitiv. Adică, îmi cerea să identific un iframe care nu era acolo pentru a fi perceput în primul rând. Deci, vor exista întotdeauna astfel de erori și probleme în testarea automată. Dar, în ultimă instanță, este vorba despre cunoaștere, deși este doar un fel de lucru în care programatorilor, cred, nu le place să creadă că sunt implicați și li se pare puțin ciudat, dar este vorba despre comportamentul uman și despre cum înțeleg oamenii lucrurile și este un lucru foarte dificil de a avea doar un set de reguli binare sau booleene.

Heydon: Deci, vreau să spun, am vorbit cu un dezvoltator când m-am consultat cu ceva timp în urmă despre asta și au tot spus: „Ei bine, atâta timp cât avem testare automată, suntem bine, nu-i așa? Doar că atunci putem merge înainte.” Și i-am spus: „Încă trebuie să testați manual. Nu există niciun test automat care să vă spună dacă folosirea interfeței cu tastatura este imposibilă într-un fel sau altul.” Există un fel de lucruri discrete pe care le puteți căuta, dar experiența generală este încă ceva care trebuie judecat de ființa umană. Da.

Drew: Uneori pericolul cu instrumentele automate este că se uită la elemente izolat sau se uită la o interfață izolat și nu văd contextul mai larg.

Heydon: Da.

Drew: Cu siguranță, cu utilizarea farului pentru audituri de performanță, uneori s-ar putea să iau o decizie ca dezvoltator să includ, poate exista mult mai mult CSS decât este folosit pe pagina respectivă și, strict vorbind, descarc prea mult CSS, dar de fapt , știu că odată ce acel fișier este încărcat, în momentul în care utilizatorul navighează la pagina următoare, are deja CSS-ul. Deci, este o optimizare care se face pe mai multe pagini, instrumentul, privind o singură pagină, o vede ca o eroare.

Heydon: Da, absolut. Te gândești în viitor și faci un apel de judecată, și până când ajungem la AI avansată pentru a anticipa asta, atunci da, chiar ai nevoie de ființe umane care să se uite la asta și să treacă prin asta și să treacă... Adică, testarea automată ar trebui să fie să existe, așa cum am spus, un fel de sistem de avertizare timpurie, un sistem de diagnosticare, dar ar trebui să existe și, dacă ești interesat ca organizația ta să aibă cu adevărat grija și să facă lucrurile mai incluzive și mai accesibile, trebuie să existe și instruire. . Trebuie să existe întrebări și răspunsuri.

Heydon: Așa că aș scrie scripturi pentru „Așa ar trebui să funcționeze când interacționați cu această componentă cu o tastatură” sau „Așa ar trebui să funcționeze când interacționați cu ea cu un cititor de ecran și nu parcurgeți de fapt. aceasta. Deci, atunci când faci asta, asta ar trebui să se întâmple. Când faci asta, asta ar trebui să se întâmple. Când faci asta, ar trebui să apară asta”, sau genul ăsta de lucruri. Deci, și genul de chestii de călătorie, așa cum spuneți, instrumentele automate nu sunt conștiente de asta. Ei doar văd: „Oh, acesta nu are text alternativ aici”. Și de fapt, în multe cazuri, poate că nu ar trebui să aibă text alternativ. Și, de asemenea, nu poate judeca dacă ați scris textul alternativ bine sau nu. Deci, cred că o imagine fără tot textul alternativ este probabil mai bună decât o imagine cu text alternativ înșelător sau pur și simplu prost. Și ăsta este din nou o chemare de judecată, nu-i așa?

Drew: Unul dintre lucrurile cu care m-am luptat, din punct de vedere istoric, în construirea lucrurilor într-un mod accesibil este să-mi păstrez la zi cunoștințele despre cele mai bune practici, deoarece, de fiecare dată când mă refer la orice documentație sau orice fel de recomandări, este pare ceea ce făceam și credeam că fac ceea ce trebuie, recomandările au trecut mai departe și acum ar trebui să fac altceva. Și aceasta este o poveste familiară cu toate domeniile de lucru pe web. Dar cred că pericolul este, desigur, cu problemele de accesibilitate, este că, dacă nu urmați cele mai bune practici, dacă lăsați ceva în interfața dvs. care acum nu este o practică bună, asta ar putea afecta utilizatorii în mod negativ. cale. O abordare bazată pe componente pentru construirea unei interfețe sau a unui site ajută la asta în vreun fel?

Heydon: Cred pur și simplu în sensul că, pentru că aveți o componentă care atunci, ideea desigur în toate cazurile și nu doar în ceea ce privește accesibilitatea, este că aveți această componentă definită într-un singur loc care va fi apoi folosită în diferite locuri, cel puțin când se schimbă aspecte sau suportul browserului sau orice ar fi acesta și doriți să actualizați componenta, abia atunci trebuie să o faceți într-un singur loc și apoi oriunde este folosită, acea îmbunătățire sau acea schimbare se va simți. Deci, din acest punct de vedere, cred că cu siguranță este mai util să avem lucrurile împărțite în componente.

Heydon: Dar apoi, da, așa cum am spus, asta nu afectează doar accesibilitatea, ci poate afecta orice se schimbă. Dar apoi, nu sunt sigur cu adevărat cât de multe schimbări vor avea... Adică, vor fi puține schimbări de ruptură în ceea ce privește tipul de accesibilitate HTML, care este, evident, o zonă foarte îngustă. Dar în ceea ce privește calitatea codului sau cum funcționează codul, lucrurile sunt introduse în specificația HTML, evident, foarte încet și nu la fel de încet, dar destul de încet și în specificația ARIA. Și apoi, o mare parte din ARIA oglindește oricum ceea ce este în HTML-ul de bază de bază.

Heydon: Cred că, mai mult decât tehnologia, percepția și înțelegerea acestor lucruri tinde să se schimbe în timp. Adică, recent, în sondajul WebAIM recent, au identificat site-urile care foloseau ARIA erau mai inaccesibile decât site-urile care nu îl foloseau. Deci, această tehnologie concepută special pentru a ajuta oamenii să facă site-urile web mai accesibile, a înrăutățit situația. Deci, este într-adevăr, este doar o lacune de cunoștințe, nu o lacună tehnologică sau o deficiență tehnologică. Oamenii pur și simplu iau tehnologia și o folosesc greșit pentru că nu au înțeles cu adevărat cum este intenționată să funcționeze, din păcate. Sper că unele dintre scrierile mele ar putea ajuta cu asta. În unele zone, oricum.

Drew: Dar un fel de sistem bine structurat bazat pe componente ți-ar permite, odată ce îți dai seama că ceva este depășit sau ai luat o decizie proastă și acum știi mai bine, ți-ar permite să intri mai ușor și să repari asta. în aplicația dvs.

Heydon: Da, exact. Da, da, absolut. Adică, totul ține de eficiență, nu-i așa? Și acest principiu uscat sau ce ai, și vezi, de aceea cred că inițial am fost foarte încântat de această oportunitate, pentru că oamenii se plâng mereu că a face lucrurile accesibile este o muncă suplimentară și este greu și este supărător și toate astea. Și așa, a fost un fel de ocazie de a spune: „Ei bine, știi cum faci aceste lucruri cu adevărat, construind eficient aceste sisteme de componente? Aduceți-vă accesibilitatea acolo pentru acea componentă pe care o realizați și apoi nu mai trebuia să vă faceți griji cu privire la accesibilitate, în afară de modificarea sau actualizarea ocazională a specificațiilor sau ce ați făcut.”

Heydon: Sau pur și simplu, vreau să spun, probabil de cele mai multe ori, iterația se va baza pur și simplu pe feedback-ul utilizatorilor și pe cercetările continue, pe care, evident, ar trebui să le faci, pe cât posibil, cu un grup divers de oameni. Așadar, ar trebui să primiți oameni care folosesc dispozitive diferite și au obiceiuri diferite de navigare și folosesc tehnologii de asistență diferite și așa ceva. Și știi, lucrurile trebuie să apară tot timpul. Cred că am stabilit cu adevărat o componentă, cred că este foarte solidă, apoi fac un pic de cercetare și constat că am făcut niște presupuneri destul de proaste. Dar da, cu un sistem de componente nu trebuie decât să-l repari într-un singur loc.

Drew: Poate o componentă să fie vreodată pe deplin incluzivă sau este un spectru în care lucrezi din ce în ce mai mult spre incluziune?

Heydon: Da, ar fi posibil ca o componentă să fie, să spunem, fără erori WCAC, să îndeplinească toate criteriile WCAC, dar așa cum am spus, asta te duce doar atât de departe și ar putea fi în continuare complet inutilizabilă sau imposibil de înțeles chiar și cu acele criterii tehnice îndeplinite. Deci da, asta e ceva despre care vorbesc mult. Încerc să conving oamenii că accesibilitatea este ca orice altă zonă a designului, este doar o parte a procesului de proiectare și nimic nu poate fi proiectat perfect, așa cum nimic nu poate fi perfect accesibil. Cred că, din păcate, mulți oameni se gândesc la asta doar pentru a se asigura că este compatibil cu cititoarele de ecran, ceea ce este, evident, un domeniu de aplicare foarte îngust în ceea ce privește accesibilitatea și includerea în general.

Heydon: Deci, vor exista oameni cu care, niște oameni buni cu care am lucrat, cum ar fi la Paciello Group, care ar spune: „Ei bine, de fapt, vreau să fiu cunoscut ca o persoană accesibilă UX.” Deci nu este vorba doar despre acest exercițiu de bifare a casetei, este mai degrabă despre încercarea de a face experiența mai bună și mai valoroasă pentru un număr mai mare de oameni și de a trece mai mult către un fel de principii mai largi și lucruri care sunt mai puțin binare. Dar, în cele din urmă, este totul, iar WCAC și alte astfel de criterii pot identifica cu adevărat doar chestii reale și rapide, „Acesta este greșit”, presupun.

Drew: Deci, dacă sunt dezvoltator, ce ar trebui să fac diferit când abordez modul în care proiectez, planific și construiesc o componentă? Există ceva ce ar trebui să iau în considerare în munca mea pentru a mă asigura că acea componentă va ajunge să fie cât mai incluzivă posibil?

Heydon: Deci, adică, în funcție de ceea ce construiești, vor fi diferite criterii care trebuie îndeplinite. Deci, de exemplu, nu fiecare componentă va avea imagini accesibile cu text alternativ, deoarece s-ar putea să nu folosească imagini deloc. Ar putea fi doar bazat pe text sau ce ai tu. Unele ar putea să nu fie interactive. Deci, în ceea ce privește cerințele specifice, atunci s-ar schimba între componentă, dar sperăm că ceea ce o parte din scrisul meu și ceea ce vă ajută cartea Componente inclusive este să vă încadrați sau să adoptați o disciplină a gândirii inclusive.

Heydon: Deci, atunci când abordezi chestia asta, nu doar să te gândești, ei bine, practic doar să scapi de mentalitatea: „Dacă funcționează pentru mine, probabil funcționează pentru toți ceilalți”, pentru că pur și simplu nu este cazul în care modul în care tu sau eu răsfoim lucrurile, adică probabil că vom face lucrurile complet diferit, doar noi doi, nu?

Drew: Corect.

Heydon: Și noi suntem occidentali, albi, englezi ca primă limbă. Și deci, da, cantitatea de diversitate în ceea ce privește oamenii care consumă asta, mă refer, oamenii de performanță vorbesc mereu despre asta, oameni care sunt interesați să pledeze pentru o performanță mai bună. Sunteți obișnuit să utilizați o configurație de înaltă specificație într-o rețea bună și mulți dintre utilizatorii dvs. sau mulți dintre potențialii dvs. nu vor fi cu siguranță, la fel și cu accesibilitatea. Este doar o chestiune de, practic, să nu te mai gândești la tine, într-adevăr. Literal doar atât. Și încercând, evident, să ajungi dincolo de colegii tăi imediati și de oamenii din același grup social.

Heydon: Așa că sperăm că este doar „Iată ce am rezolvat pentru chestiile astea” și la ce mă gândeam la acea vreme. Puteți reutiliza unele dintre aceste idei și aplica exact ceea ce am aplicat, dacă este util sau relevant pentru dvs. Sperăm că cartea se referă mai mult la „Iată un studiu de caz al unei persoane care încearcă să gândească inclusiv. Vedeți, la felul de lucruri la care se gândeau, atunci când proiectați ceva complet diferit, poate folosiți același tip de gândire și încercați să vă deschideți mintea la diversitatea utilizatorilor și la modul în care aceștia lucrează.”

Drew: Deci cartea în sine, cum ai decis cum să o structurezi? Pare foarte practic, ceea ce îmi place într-o carte, dar cum ai structurat-o?

Heydon: La fel ca și cartea anterioară, de fapt a fost Inclusive Design Patterns și am avut multe probleme cu acea carte, pentru că am încercat să o organizez în termeni de criterii abstracte. Așa că am început să fac un capitol care era despre accesibilitatea tastaturii, dar asta a fost foarte greu pentru că atunci a trebuit, de fiecare dată când vorbeam despre un alt tip de accesibilitate la tastatură sau despre un lucru la care trebuie să te gândești, atunci am a trebuit să evoce un fel de componentă și apoi să renunțe la acea componentă și apoi să treacă la altceva.

Heydon: Și așa, a avut mai mult sens pentru mine să organizez lucrurile în termeni de componente în sine. Deci, Inclusive Design Patterns face acest lucru, iar acum Inclusive Components este într-adevăr doar o continuare, care acoperă doar diferite componente. Este diferit prin faptul că, în ceea ce privește caracteristicile, este puțin diferit, deoarece include și exemple de cod live și chestii, ceea ce nu am făcut atât de mult pentru cărțile anterioare. Dar da, este literalmente doar „Vom face această componentă”, fie că este o interfață prin atingere sau o secțiune pliabilă sau un comutator de teme sau un card flash de notificare sau un prăjitor de pâine sau cum se numesc, și apoi totul este apoi organizată în jurul acelei componente.

Heydon: Deci, „Asta este ceea ce facem și acestea sunt lucrurile pe care ar trebui să le luăm în considerare în timp ce o facem pentru a fi mai incluzive”, pentru că așa lucrez eu și așa lucrează alți oameni. Și de îndată ce am început să o fac așa, eram într-adevăr doar eu să lucrez și să scriu note în timp ce lucram. Și așa, chestia s-a scris de la sine, și apoi tot efortul a fost de fapt să mă asigur că făceam o treabă decentă, cred că acele lucruri nu sunt inaccesibile.

Drew: Da, vreau să spun cuprinsul se citește aproape ca o documentație sau ca un manual de auto-ajutor sau așa ceva. Direct cu capitolul unu, butoanele de comutare. Dacă vrei să implementezi niște butoane de comutare, mergi la acest capitol, citește-l și vei obține tot ce trebuie să știi despre cum să faci asta, care este o abordare care îmi place foarte mult. Văd lucruri precum secțiuni pliabile, interfață cu file, comutatoare de teme, tabele de date, o mulțime de lucruri practice reale, reale pe care le construim cu toții în fiecare zi și cred că toți, probabil, am putea construi mai bine.

Heydon: Da, asta a fost ideea pentru că nu era vorba doar despre mine să-mi fac componentele, a fost un caz și ai atins-o acolo, ceea ce mă bucur că ai făcut-o, adică a fost de identificare comună. modele pe care le folosim cu toții. Deci, vreau să spun, există interfețe cu file peste tot și toate sunt implementate diferit și toate sunt implementate, diferit, foarte prost. Adică, am implementat interfețe de file groaznice și că am învățat puțin despre cât de proaste erau pentru oameni, apoi am încercat să le fac ceva mai bune și puțin mai bune și puțin mai bune. Probabil că am făcut 15 sau 16 versiuni diferite de interfețe cu file pe vremea mea, făcând astfel de lucruri de ani de zile.

Heydon: Și știi, ei devin puțin mai buni, sperăm, de fiecare dată. Dar este doar un lucru comun. Era un lucru obișnuit pe care îl foloseam destul de des între diferite site-uri web, îl folosesc și îl folosește toată lumea. Deci, o parte a ideii a fost să spunem: „Ei bine, de fapt, să facem un sistem de design, un fel de sistem de design accesibil pentru web.” Acum, oamenii se vor ramifica și vor face propriile versiuni ale acestor lucruri, dar pentru a reduce lucrurile de bază și accesibilitatea este un lucru de bază care ar trebui să fie în lucruri. Nu ar trebui să fie un supliment, nu ar trebui să fie nici/sau, nu ar trebui să fie o caracteristică. Ar trebui să fie un lucru de bază. Și dacă împerechezi acele chestii de bază, atunci da, sperăm că oamenii se vor uita la capitole și vor spune: „Oh, bine, le-am făcut. Le-am văzut pe alea. Să vedem cum să o facem cât mai inclusiv posibil”, și apoi sperăm că vor obține ceva valoare din asta.

Drew: Ei bine, ceea ce îmi place la ea este că, cu siguranță, știu că, în trecut, am avut câteva funcții de interfață pe care trebuia să le implementez și știu că va fi dificil din punct de vedere al accesibilității. , să zicem un fel de meniu vertical, meniu derulant, ceva de genul ăsta. Mă gândesc: „Bine, aici fiți dragoni în ceea ce privește accesibilitatea. Trebuie să mă asigur că fac asta corect.” Și așa, caut pe Google cum să o fac, găsesc o sursă de renume care spune: „Folosește această metodă”, folosesc acea metodă, o implementez și merg mai departe, dar de fapt nu am învățat nimic. Nu am aflat de ce soluția a fost asta. Și ceea ce îmi place cu adevărat la felul în care intri în ea în carte este că pot face două lucruri deodată. Îmi pot da seama cum ar trebui să o fac și pot să-mi dau seama de ce ar trebui să o fac așa, deoarece totul este explicat foarte atent. Așadar, cred că este cu adevărat de succes din acest punct de vedere.

Heydon: Oh, grozav. Pentru asta mă îndreptam. Deci e bine. 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. Da.

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.