Smashing Podcast Episode 4 z Heydon Pickering: Co to są komponenty inclusive?

Dzisiaj rozmawiam z Heydonem Pickeringiem o jego nowej książce, Inclusive Components . Heydon jest znany ze swojej pracy i pisania na temat dostępności — więc co właściwie oznacza „projekt włączający” i gdzie wchodzą w grę komponenty? Heydon wyjaśnia to wszystko i więcej w tym odcinku. Możesz posłuchać poniżej lub zasubskrybować, gdziekolwiek zdobędziesz swoje podcasty.

Pokaż notatki

• Książka Inclusive Components od Smashing Magazine
• Projekt Heydona Every Layout z Andym Bellem
• Strona internetowa Heydon Heydonworks
• Heydon na Twitterze

Transkrypcja

Drew McLellan: Jest niezależnym konsultantem ds. dostępności stron internetowych, projektantem interfejsów i pisarzem. Jego praca koncentruje się na projektowaniu doświadczeń użytkownika z ułatwieniami dostępu, a także pisaniu i redagowaniu dla magazynu Smashing. Jest autorem uznanej książki o projektowaniu aplikacji internetowych z ułatwieniami dostępu, Apps For All, i właśnie wydał nową książkę, Komponenty włączające, w której wszystko o tym, jak tworzyć dostępne interfejsy internetowe, znowu za pomocą Smashing Magazine. Więc jest ekspertem w dziedzinie przystępnego projektowania, ale czy wiesz, że był pierwszym mężczyzną, który przeskoczył most Sydney Harbour Bridge w motorówce? Moi Smashingowi przyjaciele, witajcie Heydona Pickeringa. Cześć Heydonie. Jak się masz?

Heydon Pickering: Rozwalam. Jestem na marce.

Drew: Chciałem dziś z tobą porozmawiać na temat twojej nowej książki, Inclusive Components.

Heydon: Tak.

Drew: Oczywiście tytuł składający się z dwóch słów, ale wydaje mi się, że każde z tych słów jest bardzo ważne. Zaczynając od końca, co jest oczywiście logiczne, komponenty, czy chodzi o projektowanie oparte na komponentach? Co to jest?

Heydon: Tak, więc przypuszczam, że minęło trochę czasu, odkąd ludzie, programiści front-end, projektanci i wszyscy, którzy współpracują przy tworzeniu interfejsów, zaczęli myśleć o rzeczach w kategoriach komponentów i dzielić je na przyswajalne i wielokrotnego użytku kąski. Przypuszczam, że jeśli z jakiegoś powodu nie znasz tego sposobu pracy, to naprawdę przypomina trochę elementy elektroniczne. Mój ojciec jest inżynierem elektronikiem. Pracuje w czymś w rodzaju analogowego świata płytek drukowanych, lutu i tego typu rzeczy.

Heydon: W rzeczywistości stworzył kilka komponentów, bardzo małych komponentów, które były używane do regulowania prądu płynącego do elektromagnesów w CERN. Jako dziecko bardzo we mnie wierzył, ponieważ zmusił mnie do przylutowania dla nich niektórych części. Myślę, że ta partia została już wycofana, więc nie martw się o moje kiepskie lutowanie, moje kiepskie lutowanie nastolatka, bycie już zaangażowanym w CERN. Ale tak, myślę, że to jest analogiczne do… Och, jest tam zbyt wiele analogów.

Heydon: Jest to analogiczne do płytek z obwodami analogowymi, ponieważ chodzi o to, że masz jedną odpowiedzialność za poszczególne części lub komponenty i razem tworzą obwód i razem zwiększają prąd w przypadku obwodu lub, jak sądzę, interfejs lub wynik w jakikolwiek sposób, w systemie projektowym lub w interfejsie przejawiającym się w systemie projektowym. I tak, Komponenty Włączające, ponieważ chciałem zająć się faktem, że chociaż, mam na myśli, dostępność zazwyczaj pozostaje w tyle, gdy rozwijamy to, co robimy na różnych obszarach, i chciałem wprowadzić dostępność i szerzej. sens, inkluzywny projekt, który ma na celu ten nowy sposób myślenia i tworzenia rzeczy przy użyciu komponentów lub modułów lub jakkolwiek chcesz je nazwać.

Heydon: Więc pomysł polegał na wprowadzeniu dostępności do systemów projektowania, ale z tego samego powodu myślenie systemowe, jeśli chodzi o próby rozwiązania problemu dostępności. Pomyśl o rozwiązaniu jednego problemu w jednym miejscu pod względem dostępności i upewnieniu się, że po prostu rozchodzi się on wokół wzorca [niesłyszalne 00:03:16] całego systemu projektowania.

Drew: W pewnym sensie praktycznym, jak właściwie wygląda praca w oparciu o komponenty? Jaki może być przykład komponentu?

Heydon: Tak więc są różne sposoby tworzenia i kodowania komponentów. Mam tendencję do wchodzenia od razu w sedno sprawy, poza konceptualnymi rzeczami i zastanawiam się, jak mogę uporządkować kod. Właściwie zacząłem skupiać się na niestandardowych elementach, a jeśli nie na niestandardowych elementach, to na normalnych elementach, ale z pewnym rodzajem zachowania JavaScript dołączonym do nich w sposób wyizolowany, skomponowany. Bardzo podoba mi się pomysł na komponenty, które są interoperacyjne. Rozumiem przez to, że mogą być używane w różnych frameworkach i systemach, podejściach i stosach technicznych. A elementy niestandardowe są w tym fajne, ponieważ są natywne. Możesz je zdefiniować w jednym miejscu, a następnie mogą być używane, powiedzmy, w aplikacji React, mogą być używane w aplikacji widoku, mogą być używane w aplikacji kątowej lub w jakiejkolwiek większej technologii zarządzania stanem, z której korzystasz za pomocą.

Heydon: Więc dla mnie zwykle komponent będzie prawdopodobnie elementem niestandardowym. Ostatnio pracowałem nad projektem, który nie jest tak bardzo skoncentrowany na dostępności, chociaż starałem się, aby był jak najbardziej dostępny, o nazwie Każdy układ, i chodzi o próbę wyizolowania bardzo specyficznego rodzaju algorytmów dla Układ CSS. Są one definiowane jako elementy niestandardowe, które w pewnym sensie wdrażają się i uruchamiają własny CSS i działają jak prymitywne elementy w większym systemie.

Drew: To znaczy, w praktyce mówimy, że komponent może być czymś w rodzaju pola formularza?

Heydon: Tak, więc może to być coś tak prostego jak dane wejściowe. Powiedzmy, jak wprowadzanie tekstu lub może to być coś złożonego, na przykład interfejs kart. I tak, pomysł z komponentami włączającymi polegał na przyjęciu koncepcji jednego komponentu z jego, miejmy nadzieję, jednym celu, takim jak wprowadzanie tekstu, a następnie zastanowienie się nad wszystkimi różnymi rzeczami, które mogą potykać się o różne rodzaje ludzi i próbować ich uniknąć ich. Nie unikaj ludzi, unikaj problemów. Nie chodzi tu tak bardzo o włączanie ludzi, chodzi o to, by nie arbitralnie wykluczać ludzi.

Heydon: Wydaje mi się, że to najłatwiejszy sposób podejścia do procesu projektowania włączającego, polega na zidentyfikowaniu potencjalnie wykluczających elementów czegoś i próbowaniu ich ominięcia. Tak więc z wprowadzaniem tekstu, z etykietą, masz wiele różnych rzeczy, o które możesz chcieć się martwić. Tak więc na początku będziesz mieć pewność, czy jest właściwie oznakowany, czy nie. Czy używasz elementu label i czy ten element label wskazuje pole tekstowe za pomocą atrybutu for, aby te dwie rzeczy były programowo powiązane, tak że gdy użytkownik czytnika ekranu skupia dane wejściowe, faktycznie słyszy ogłaszaną etykietę? Więc to jedna rzecz, którą należy zrobić dobrze.

Heydon: Następnie, na bardziej wizualnym poziomie, upewniając się, że etykieta jest wyraźnie powiązana z tym polem, a nie innymi polami, i to jest kwestia białej przestrzeni i tego typu rzeczy. Ponadto, upewniając się, że etykieta nie jest, nie robisz czegoś wymyślnego, takiego jak umieszczanie etykiety pod danymi wejściowymi formularza, ponieważ wtedy, gdy na przykład pojawia się wirtualna klawiatura, może to zostać zasłonięte. Więc bierze pod uwagę tego rodzaju rzeczy.

Heydon: Upewnienie się, że dane wejściowe mają styl fokusu, więc gdy ustawiasz fokus za pomocą klawiatury, niezależnie od tego, czy jesteś zwykłym użytkownikiem klawiatury, który używa klawiatury do nawigacji, czy w inny sposób, upewniając się, że styl fokusu jasno wskazuje, że jest to dane wejściowe, na których się koncentrujesz. Upewniając się, mam na myśli takie rzeczy jak autouzupełnianie, martwienie się o to, czy autouzupełnianie jest odpowiednie i pomocne w kontekście, czy nie. Wiele z tych rzeczy odnosi się bezpośrednio do niepełnosprawności, ale wiele z nich ma szerszy zakres, jeśli chodzi o użyteczność i po prostu sprawia, że ​​rzeczy są tak zrozumiałe, jak to tylko możliwe.

Heydon: Dość często istnieje bardzo cienka linia, a może niewyraźna granica między tym, co dotyczy użyteczności dla wszystkich, a tym, co dotyczy niepełnosprawności. A potem, żeby jeszcze trudniej było to określić, upośledzenie poznawcze. Więc jeśli coś nie jest zbyt użyteczne dla kogoś, kto nie ma niepełnosprawności poznawczej, to będzie jeszcze trudniej to rozpracować i będzie w stanie użyć dla kogoś, kto ma tego rodzaju wyzwania.

Heydon: Więc to po prostu próba myślenia o wszystkich tych rzeczach w jednym miejscu. I tak naprawdę ta książka jest tylko moja, to mój proces myślowy, kiedy zbliżam się do każdego z nich. Na początek zrobiłem to jako blog. A każdy wzorzec lub każdy składnik to post na blogu, a tekst to tylko ja: „Więc zajmijmy się teraz tym potencjalnym problemem. Jak sobie z tym poradzimy? Dobra, sprawdziliśmy to. Myślę, że tam wszystko w porządku. I w żadnym wypadku nie staram się powiedzieć, że są idealne i że pomyślałem o wszystkim, bo to nie jest możliwe.

Drew: Podobnie jak podejście oparte na komponentach do pracy nad poszczególnymi częściami interfejsu, jak sądzę, pozwala to naprawdę zagłębić się w ten konkretny element i upewnić się, że naprawdę mocno go zoptymalizowałeś w najlepszy sposób może tak, aby była dostępna dla wszystkich. Czy istnieje niebezpieczeństwo w robieniu tego i robieniu tego na wielu różnych komponentach, a następnie umieszczaniu ich wszystkich razem na stronie? Czy istnieje niebezpieczeństwo, że możesz stworzyć problemy, których nie byłeś świadomy, ponieważ testujesz je indywidualnie, a nie razem?

Heydon: To naprawdę dobra uwaga i zamierzałem o tym wspomnieć wcześniej. Cieszę się, że to powiedziałeś. Tak więc, na wiele sposobów, myślę, że filozoficznie zdecydowaliśmy, że musimy rozdzielić rzeczy na poszczególne składniki. I jest w tym cnota, ponieważ jeśli jest odizolowana, łatwiej jest ją przetestować i traktować jako pojedynczą rzecz. A sposób, w jaki pracujemy, może w pewnym sensie ułatwia zarządzanie. Musimy również wziąć pod uwagę fakt, że te rzeczy ostatecznie muszą dzielić tę samą przestrzeń i łączyć się w większy system.

Heydon: I nie sądzę, że wystarczająco dużo naszego wysiłku i myśli idzie w to, wystarczająco zabawnie. Myślę, że bardziej komponujemy rzeczy, aby ułatwić nam życie jako inżynierów, abyśmy wiedzieli, nad czym pracujemy i o której godzinie. A przecież często zaniedbujemy fakt, że te rzeczy będą żyć w dynamicznych systemach i muszą być…

Heydon: Mam na myśli, że projekt Every Layout, chociaż bardziej dotyczy projektowania wizualnego i layoutu, polega na próbie stworzenia tych małych prymitywów CSS, tych małych prymitywów layoutu, w taki sposób, aby mogły sobie algorytmicznie zarządzać sobą. Jest tak, że można je wyciągnąć z wąskiej kolumny i włożyć następnie do szerokiej kolumny i wtedy będzie, sam kod określi, ile elementów powinno być obok siebie lub czy powinien się przekonfigurować w jakiś inny sposób. Ponieważ nie możemy sobie pozwolić na nieustanną interwencję i myślę, że musi to być system, który jest w pewnym sensie samoświadomy i inteligentny.

Heydon: Zawsze są rzeczy, o których możesz zapomnieć. Więc może tworzysz interfejs kart, masz rząd kart, wybierasz między kartą, a karta odpowiada panelowi kart, który otwiera coś. A potem ktoś przyjdzie i powie: „A co, jeśli chcę umieścić interfejs z kartami w interfejsie z kartami lub inny komponent w interfejsie z kartami?”

Heydon: I oczywiście mam na myśli to, że częściowo jest to kwestia techniczna, czy byłoby to możliwe, ale tak, musisz zdecydować, czy zamierzasz uczynić rzeczy tak elastycznymi, jak to tylko możliwe, aby było to możliwe. możliwe do skomplikowania rzeczy w złożony sposób lub po prostu napisania twardych reguł, które mówią: „Nie możesz tu czegoś umieścić, ponieważ poziom złożoności pod względem kodu byłby prawdopodobnie zbyt wysoki, ale prawdopodobnie również pod względem jak użytkownik może to postrzegać i używać”. Jestem całkowicie za pisaniem zasad, które mówią: „Nie zagnieżdżaj w sobie wielu złożonych funkcji”, ponieważ po prostu jest mało prawdopodobne, że ludzie będą w stanie to ogarnąć, naprawdę.

Drew: Czy możliwe jest przyjęcie w pełni algorytmicznego lub zautomatyzowanego podejścia do projektowania pod kątem dostępności?

Heydon: Nie sądzę. Nie. Mamy więc zautomatyzowane narzędzia i nie chcę w żaden sposób dyskredytować zautomatyzowanych narzędzi. Myślę, że są one bardzo przydatne, ale używam ich jako systemu wczesnego ostrzegania, aby spróbować zorientować się, gdzie znajdują się obszary problemowe. Tak więc, gdybym robił audyt dla organizacji, która potrzebowała porady, jak uczynić swoje produkty bardziej dostępnymi. Więc jest to dobry sposób na finansowanie tam, gdzie są obszary problemowe, ale mam na myśli, że możesz mieć interfejs, który jest technicznie w 100% dostępny, być może, według jakiegoś narzędzia, nawet dobre narzędzie do oceniania go, powiedzmy, w stosunku do WCAG , wytyczne dotyczące dostępności treści internetowych lub inną specyfikację akceptacji. I chociaż jest to 100% wszystkich zaznaczonych pól, nadal może być całkowicie bezużyteczny z różnych powodów.

Heydon: Na przykład wracając do tego, o czym mówiliśmy wcześniej, może to być po prostu zbyt skomplikowane. Możesz po prostu przytłoczyć kogoś linkami i po prostu nie ma możliwości, aby był w stanie przez to przejść, a potem staje się to bardzo milczącą rzeczą i trudną do sprecyzowania, ale musi po prostu zrazić ludzi. Ale jest też bardzo łatwo uzyskać fałszywe alarmy i tym podobne. Miałem coś innego dnia, powiedziałem, że to był inny miesiąc, pracowałem dla organizacji i oczywiście chcieli mieć szkołę latarni morskiej 100% dostępności i był tam iframe, który był tam dynamicznie wrzucany przez skrypt analityczny czy coś takiego. Znasz ten rodzaj rzeczy, w których jest to coś w rodzaju nieco obrzydliwego kodu, który jest po prostu wrzucany na stronę, aby wykonać takie zadanie.

Heydon: Teraz poleciłbym w ogóle nie używać analityki i zaleciłem im przynajmniej wsparcie protokołu „nie śledź”, aby ludzie mogli zrezygnować. Niestety, ten protokół tak naprawdę już nie działa, ponieważ nigdy nie był właściwie obsługiwany. Ale ten iframe mówił, że nie ma na nim tytułu. Pomysł jest taki, że jeśli masz element iframe, powinien on mieć atrybut title, ponieważ jest to najlepszy długotrwały sposób identyfikowania, do czego służy element iframe dla użytkownika czytnika ekranu. Ale był to element iframe, który również nie wyświetlał żadnego, więc nie był nawet widoczny dla czytnika ekranu, ponieważ nie wyświetlaj, tak jak ukrywa rzeczy wizualnie w czytniku ekranu, zasadniczo usunie je z interfejs, więc nie zostanie w żaden sposób napotkany ani ogłoszony.

Heydon: Więc to był fałszywy alarm. Chodzi mi o to, że prosił mnie o zidentyfikowanie elementu iframe, którego nie było w ogóle, aby był postrzegany. Tak więc w automatycznym testowaniu zawsze będą pojawiać się tego rodzaju błędy i problemy. Ale ostatecznie chodzi o wiedzę, chociaż wydaje mi się, że jest to po prostu rzecz, o której programiści, jak sądzę, nie lubią myśleć, że są zaangażowani i uważają to za trochę nieprzyjemne, ale dotyczy to ludzkiego zachowania i jak ludzie rozumieją różne rzeczy, a bardzo trudno jest mieć zestaw pewnego rodzaju binarnych lub logicznych reguł.

Heydon: To znaczy, rozmawiałem z programistą, kiedy jakiś czas temu konsultowałem się w tej sprawie, a oni ciągle powtarzali: „Dopóki mamy automatyczne testy, wszystko w porządku, prawda? Po prostu wtedy możemy po prostu iść do przodu”. Powiedziałem: „Nadal musisz testować ręcznie. Nie ma automatycznego testu, który naprawdę może powiedzieć, czy korzystanie z interfejsu za pomocą klawiatury jest w taki czy inny sposób niemożliwe.” Są pewne dyskretne rzeczy, których możesz szukać, ale ogólne doświadczenie jest nadal czymś, co musi zostać ocenione przez człowieka. Tak.

Drew: Czasami niebezpieczeństwo związane z automatycznymi narzędziami polega na tym, że patrzą na elementy w izolacji lub patrzą na jeden interfejs w izolacji i nie widzą szerszego kontekstu.

Heydon: Tak.

Drew: Oczywiście używając latarni do audytów wydajności, czasami jako programista mogę podjąć decyzję o włączeniu, może być o wiele więcej CSS niż na tej jednej stronie, a ściśle mówiąc, pobieram za dużo CSS, ale tak naprawdę , wiem, że po załadowaniu tego pliku, zanim użytkownik przejdzie do następnej strony, ma już CSS. Jest to więc optymalizacja przeprowadzana na wielu stronach, którą narzędzie, patrząc na jedną stronę osobno, postrzega jako błąd.

Heydon: Tak, absolutnie. Myślisz z wyprzedzeniem i wydajesz osąd, i dopóki nie dojdziemy do zaawansowanej sztucznej inteligencji, aby to przewidzieć, wtedy tak, naprawdę potrzebujesz ludzi, którzy na to patrzą, przechodzą przez to i robią… to znaczy, automatyczne testowanie powinno być na miejscu, jak mówię, coś w rodzaju systemu wczesnego ostrzegania, systemu diagnostycznego, ale powinien też istnieć, jeśli jesteś zainteresowany, aby Twoja organizacja naprawdę troszczyła się i czyniła rzeczy bardziej włączającymi i bardziej dostępnymi, konieczne jest również szkolenie . Potrzebne są pytania i odpowiedzi.

Heydon: Więc napisałbym skrypty: „Tak powinno działać, gdy wchodzisz w interakcję z tym komponentem za pomocą klawiatury” lub „Tak powinno działać, gdy wchodzisz w interakcję z czytnikiem ekranu, a nie przechodzisz przez to. Więc kiedy to zrobisz, powinno się to zdarzyć. Kiedy to zrobisz, powinno to nastąpić. Kiedy to zrobisz, powinno to się pojawić” lub tego typu rzeczy. Tak więc, jak mówisz, zautomatyzowane narzędzia nie są tego świadome. Widzą tylko: „Och, tutaj nie ma tekstu alternatywnego”. I faktycznie, w wielu przypadkach może nie powinien zawierać tekstu alternatywnego. A także nie może ocenić, czy dobrze napisałeś tekst alternatywny, czy nie. Myślę więc, że obraz bez całego tekstu alternatywnego jest prawdopodobnie lepszy niż obraz z mylącym lub po prostu złym tekstem alternatywnym. I to znowu wezwanie do osądu, prawda?

Drew: Jedną z rzeczy, z którymi zmagałem się, historycznie, w budowaniu rzeczy w przystępny sposób, jest aktualizowanie mojej wiedzy na temat najlepszych praktyk, ponieważ za każdym razem, gdy odnoszę się do jakiejkolwiek dokumentacji lub jakiegokolwiek rodzaju zaleceń, wygląda na to, co robiłem i myślałem, że robię dobrze, zalecenia poszły dalej i teraz powinienem zrobić coś innego. I to jest znajoma historia ze wszystkich obszarów pracy w sieci. Myślę jednak, że niebezpieczeństwo związane z dostępnością polega na tym, że jeśli nie stosujesz najlepszych praktyk, jeśli zostawisz w interfejsie coś, co nie jest teraz dobrą praktyką, może to negatywnie wpłynąć na użytkowników. sposób. Czy podejście oparte na komponentach do budowania interfejsu lub witryny w jakikolwiek sposób pomaga?

Heydon: Myślę wyłącznie w tym sensie, że ponieważ masz jeden komponent, który następnie, idea oczywiście we wszystkich przypadkach, a nie tylko pod względem dostępności, jest taka, że ​​masz ten komponent zdefiniowany w jednym miejscu, który będzie następnie używany w różnych w niektórych miejscach, przynajmniej wtedy, gdy zmienią się aspekty lub obsługa przeglądarki lub cokolwiek to jest, i chcesz zaktualizować komponent, musisz to zrobić tylko w jednym miejscu, a następnie wszędzie tam, gdzie jest używany, to ulepszenie lub ta zmiana będą odczuwalne. Pod tym względem myślę, że z pewnością bardziej przydatne jest dzielenie rzeczy na komponenty.

Heydon: Ale tak, jak mówię, to nie tylko wpływa na dostępność, ale może wpływać na wszystko, co się zmienia. Ale z drugiej strony nie jestem pewien, jak wiele zmian w nim… Mam na myśli, że będzie kilka przełomowych zmian w zakresie dostępności HTML, która jest oczywiście bardzo wąskim obszarem. Ale jeśli chodzi o jakość kodu lub sposób działania kodu, rzeczy są wprowadzane do specyfikacji HTML, oczywiście bardzo powoli i nie tak powoli, ale dość powoli również do specyfikacji ARIA. A poza tym większość ARIA i tak po prostu odzwierciedla to, co znajduje się w bazowym HTML-u.

Heydon: Myślę, że bardziej niż technologia, postrzeganie i rozumienie tych rzeczy zmienia się z czasem. Mam na myśli to, że ostatnio w ankiecie WebAIM okazało się, że strony używające ARIA są bardziej niedostępne niż strony, które jej nie używają. Tak więc ta technologia stworzona specjalnie po to, aby pomóc ludziom w zwiększaniu dostępności stron internetowych, pogarszała sytuację. Więc tak naprawdę jest to tylko luka w wiedzy, a nie luka technologiczna lub wada technologiczna. To ludzie po prostu biorą technologię i nadużywają jej, ponieważ tak naprawdę nie rozumieją, jak ma ona działać, niestety. Mam nadzieję, że niektóre moje teksty mogą w tym pomóc. W każdym razie w niektórych obszarach.

Drew: Ale coś w rodzaju dobrze zorganizowanego systemu opartego na komponentach umożliwiłoby ci, gdybyś zdał sobie sprawę, że coś jest nieaktualne lub podjąłeś złą decyzję i teraz wiesz lepiej, umożliwi ci to łatwiejsze wejście i naprawienie tego w całej aplikacji.

Heydon: Tak, dokładnie. Tak, tak, absolutnie. Chodzi mi o to, że chodzi o wydajność, prawda? I ta sucha zasada, czy co ty, i widzisz, dlatego myślę, że początkowo byłem bardzo podekscytowany tą szansą, ponieważ ludzie zawsze narzekają, że udostępnianie rzeczy to dodatkowa praca, jest to trudne i denerwujące, i tak dalej. Była to więc okazja, by powiedzieć: „Cóż, wiesz, jak robisz to naprawdę, wydajnie budując te systemy składowe? Uzyskaj tam swoją dostępność dla tego jednego komponentu, który tworzysz, a wtedy nie musisz się już martwić o dostępność, poza okazjonalną zmianą specyfikacji lub aktualizacją lub co masz”.

Heydon: Lub po prostu, mam na myśli, prawdopodobnie przez większość czasu iteracja będzie po prostu oparta na opiniach użytkowników i trwających badaniach, które oczywiście powinieneś przeprowadzać, na ile to możliwe, z różnorodną grupą ludzi. Powinieneś więc pozyskiwać ludzi, którzy używają różnych urządzeń i mają różne nawyki przeglądania oraz używają różnych technologii wspomagających i tego typu rzeczy. I wiesz, rzeczy na pewno będą się pojawiać cały czas. Myślę, że naprawdę określiłem komponent, myślę, że jest naprawdę solidny, a potem robię trochę badań i stwierdzam, że przyjąłem dość złe założenia. Ale tak, z systemem komponentów wystarczy go naprawić tylko w jednym miejscu.

Drew: Czy komponent może kiedykolwiek być w pełni inkluzywny, czy jest to spektrum, w którym pracujesz coraz bardziej w kierunku włączenia?

Heydon: Tak, możliwe byłoby, aby komponent był wolny od błędów, powiedzmy WCAC, spełnia wszystkie kryteria WCAC, ale jak powiedziałem, to prowadzi tylko tak daleko i nadal może być całkowicie bezużyteczny lub niemożliwe do zrozumienia nawet przy spełnieniu tych kryteriów technicznych. Więc tak, to jest coś, o czym dużo mówię. Staram się przekonać ludzi, że dostępność jest jak każda inna dziedzina projektowania, to tylko część procesu projektowania i nic nie może być doskonale zaprojektowane, tak jak nic nie może być doskonale dostępne. Myślę, niestety, że wielu ludzi myśli o tym tylko w kategoriach upewnienia się, że jest kompatybilny z czytnikami ekranu, co oczywiście jest bardzo wąskim zakresem pod względem dostępności i ogólnego włączenia.

Heydon: Więc będą ludzie, z którymi pracowałem, jak na przykład z Paciello Group, którzy powiedzieliby: „Właściwie, chcę być znany jako osoba przystępna UX”. Więc nie chodzi tylko o to ćwiczenie polegające na zaznaczaniu pola, ale bardziej o to, by uczynić to doświadczenie lepszym i bardziej wartościowym dla większej liczby ludzi i bardziej podążać w kierunku szerszych zasad i rzeczy, które są mniej binarne. Ale ostatecznie to wszystko, a WCAC i inne podobne kryteria mogą naprawdę zidentyfikować tylko naprawdę twarde i szybkie rzeczy, „To jest złe”, jak sądzę.

Drew: Więc jeśli jestem programistą, co powinienem zrobić inaczej, gdy podchodzę do tego, jak projektuję, planuję i buduję komponent? Czy jest coś, co powinienem wziąć pod uwagę w swojej pracy, aby upewnić się, że ten składnik będzie tak wszechstronny, jak to tylko możliwe?

Heydon: To znaczy, w zależności od tego, co budujesz, będą różne kryteria, które należy spełnić. Na przykład nie każdy komponent będzie miał dostępne obrazy z tekstem alternatywnym, ponieważ może w ogóle nie używać obrazów. Może to być po prostu tekst lub co masz. Niektóre mogą nie być interaktywne. Tak więc, jeśli chodzi o konkretne wymagania, zmieniłoby się to między komponentami, ale mam nadzieję, że część moich prac i to, w czym pomaga książka Komponenty włączające, to wpaść w dyscyplinę lub przyjąć dyscyplinę polegającą na myśleniu włączającym.

Heydon: Więc kiedy podchodzisz do tych rzeczy, nie tylko myślisz, cóż, w zasadzie po prostu odchodzisz od nastawienia: „Jeśli to działa dla mnie, to prawdopodobnie działa dla wszystkich innych”, ponieważ po prostu nie jest tak, że sposób, w jaki ty lub ja przeglądamy różne rzeczy, to znaczy, prawdopodobnie będziemy robić rzeczy zupełnie inaczej, tylko my dwoje, prawda?

Drew: Racja.

Heydon: A my jesteśmy białymi z Zachodu, Anglicy jako ludzie pierwszego języka. A więc, tak, ilość różnorodności pod względem ludzi, którzy to konsumują, mam na myśli to, że ludzie występowi zawsze o tym mówią, ludzie, którzy są zainteresowani promowaniem lepszych wyników. Jesteś przyzwyczajony do korzystania z wysokiej specyfikacji w dobrej sieci i wielu użytkowników lub wielu potencjalnych użytkowników z pewnością nie będzie, podobnie jak dostępność. To tylko kwestia, w zasadzie, po prostu oderwania się od myślenia o sobie, naprawdę. Dosłownie właśnie to. I oczywiście starając się dotrzeć do nie tylko najbliższych współpracowników i osób z tej samej grupy społecznej.

Heydon: Miejmy nadzieję, że tak naprawdę to tylko „Oto, co rozwiązałem w tej sprawie” i o czym wtedy myślałem. Możesz ponownie wykorzystać niektóre z tych pomysłów i zastosować dokładnie to, co zastosowałem, jeśli jest to dla Ciebie przydatne lub istotne. Miejmy nadzieję, że książka jest bardziej o tym, że „Oto studium przypadku osoby, która stara się myśleć inkluzywnie. Widzisz, o tym, o czym myśleli, kiedy projektujesz coś zupełnie innego, być może po prostu zastosuj ten sam sposób myślenia i spróbuj otworzyć swój umysł na różnorodność użytkowników i sposób, w jaki sobie z tym radzą”.

Drew: A więc sama książka, jak zdecydowałeś, jak ją ustrukturyzować? Wydaje się to bardzo praktyczne, co lubię w książce, ale jak to skonstruowałeś?

Heydon: Bardzo podobnie jak poprzednia książka, była to inkluzywne wzorce projektowe i na początku miałem z nią wiele problemów, ponieważ próbowałem uporządkować ją w kategoriach abstrakcyjnych kryteriów. Zacząłem więc od robienia rozdziału, który dotyczył wyłącznie dostępności klawiatury, ale było to bardzo trudne, ponieważ wtedy musiałem tak jakby, za każdym razem, gdy mówiłem o innym typie dostępności klawiatury lub rzeczy, o której musisz pomyśleć, wtedy musiałem wyczarować jakiś składnik, a następnie porzucić ten składnik, a następnie przejść do czegoś innego.

Heydon: A więc bardziej sensowne było dla mnie organizowanie rzeczy pod kątem samych komponentów. Tak więc robią to wzorce projektu włączającego, a teraz komponenty włączające są tak naprawdę tylko kontynuacją, która obejmuje tylko różne komponenty. Różni się tym, że pod względem funkcji jest nieco inny, ponieważ zawiera również przykłady kodu na żywo i inne rzeczy, których nie robiłem zbyt wiele w poprzednich książkach. Ale tak, dosłownie: „Zrobimy ten komponent”, niezależnie od tego, czy jest to interfejs kranu, zwijana sekcja, przełącznik motywów, karta flash z powiadomieniem, toster, czy jakkolwiek się tam nazywają, a potem po prostu wszystko jest następnie zorganizowana wokół tego komponentu.

Heydon: Więc to jest: „To właśnie robimy i to są rzeczy, które powinniśmy wziąć pod uwagę, gdy robimy to, aby było bardziej inkluzywne”, ponieważ tak właśnie pracuję i tak pracują inni ludzie. I jak tylko zacząłem to robić w ten sposób, tak naprawdę byłem tylko ja, który pracowałem i pisałem notatki podczas pracy. I tak to się pisało, a potem cały wysiłek polegał na upewnieniu się, że wykonałem przyzwoitą robotę, aby te rzeczy nie były niedostępne, jak sądzę.

Drew: Tak, mam na myśli spis treści, który naprawdę czyta się prawie jak dokumentację, podręcznik samopomocy czy coś takiego. Prosto z pierwszym rozdziałem, przełączaj przyciski. Jeśli chcesz zaimplementować przyciski przełączania, przejdź do tego rozdziału, przeczytaj go, a dowiesz się wszystkiego, co musisz wiedzieć o tym, jak to zrobić, co bardzo mi się podoba. Widzę takie rzeczy, jak zwijane sekcje, interfejs z zakładkami, przełączniki motywów, tabele danych, mnóstwo rzeczywistych, naprawdę praktycznych rzeczy, które wszyscy budujemy każdego dnia i myślę, że wszyscy prawdopodobnie moglibyśmy budować lepiej.

Heydon: Tak, to był całkowicie pomysł, ponieważ nie chodziło tylko o to, żebym robił moje komponenty, była to sprawa i dotknąłeś tego tam, co cieszę się, że to zrobiłeś, czyli było to zidentyfikowanie wspólnych wzory, których wszyscy używamy. Więc mam na myśli, że są wszędzie interfejsy kart i wszystkie są zaimplementowane inaczej i wszystkie są zaimplementowane, różnie, bardzo źle. Mam na myśli to, że zaimplementowałem okropne interfejsy kart i dowiedziałem się trochę o tym, jak złe są dla ludzi, a potem próbowałem uczynić je trochę lepszymi, trochę lepszymi i trochę lepszymi. Prawdopodobnie w swoim czasie stworzyłem 15 lub 16 różnych wersji interfejsów kart, robiąc tego rodzaju rzeczy od lat.

Heydon: I wiesz, miejmy nadzieję, że za każdym razem są trochę lepsze. Ale to tylko powszechna rzecz. To była powszechna rzecz, z której korzystałem dość często między różnymi stronami internetowymi, z których korzystam i wszyscy korzystają. Częścią pomysłu było więc powiedzenie: „Właściwie, zróbmy system projektowania, rodzaj dostępnego systemu projektowania dla sieci”. Teraz ludzie będą się rozgałęziać i będą robić swoje własne wersje tych rzeczy, ale w pewnym sensie zniwelowanie podstawowych rzeczy, a dostępność jest podstawową rzeczą, która powinna być w rzeczach. To nie powinno być dodatkiem, nie powinno być albo/albo, nie powinno być funkcją. Powinna to być sprawa podstawowa. A jeśli połączysz te podstawowe rzeczy w parę, to tak, miejmy nadzieję, że ludzie spojrzą na rozdziały i powiedzą: „Och, w porządku, zrobiłem je. Widziałem to. Zobaczmy, jak to zrobić tak inkluzywnie, jak to tylko możliwe”, a potem miejmy nadzieję, że uzyskają z tego jakąś wartość.

Drew: Cóż, podoba mi się to, na pewno wiem, że w przeszłości miałem kilka funkcji interfejsu, które musiałem zaimplementować i wiem, że będzie to trudne z punktu widzenia dostępności , powiedzmy jakieś wysuwane menu, rozwijane menu, coś w tym stylu. Myślę: „Ok, oto smoki, jeśli chodzi o dostępność. Muszę się upewnić, że robię to dobrze”. I tak szukam w Google, jak to zrobić, znajduję renomowane źródło mówiące „Użyj tej metody”, używam tej metody, wdrażam ją i idę dalej, ale właściwie niczego się nie nauczyłem. Nie dowiedziałem się, dlaczego było to rozwiązanie. A najbardziej podoba mi się sposób, w jaki opisujesz to w książce, że mogę zrobić dwie rzeczy naraz. Potrafię wymyślić, jak powinienem to robić i dlaczego powinienem to robić, ponieważ wszystko jest bardzo dokładnie wyjaśnione. Więc myślę, że z tego punktu widzenia to naprawdę udane.

Heydon: Och, świetnie. To było to, do czego zmierzałem. Więc to dobrze. 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. Tak.

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.