Dobry, lepszy, najlepszy: rozwikłanie złożonego świata dostępnych wzorców

Marc Benioff pamiętnie stwierdził, że jedyną stałą w branży technologicznej jest zmiana. Pracując w branży technicznej od ponad 15 lat, mogę to potwierdzić. Inni dinozaury technologiczne mogą zaświadczyć, że sposób, w jaki sieć działała na początku, jest drastycznie inny, niż wielu z nas mogłoby sobie nawet wyobrazić.

Chociaż ta ciągła zmiana w branży technologicznej doprowadziła do innowacji i postępów, które widzimy dzisiaj, wprowadziła również koncepcję wyboru. Chociaż wybór — na pierwszy rzut oka — może wydawać się z natury pozytywną rzeczą, nie zawsze oznacza tęczę i róże. Napływ zmian technologicznych przynosi również rozszczepienie języków kodowania i niekończące się smaki „gorętości” programowania. Czasami ta obfitość wyboru zamienia się w nadmierny wybór — dobrze zbadane upośledzenie funkcji poznawczych, w którym ludzie mają trudności z podjęciem decyzji z powodu zbyt wielu opcji.

W tym artykule postaramy się rozwikłać skomplikowany świat dostępnych wzorców — krok po kroku. Zaczniemy od przeglądu aktualnych dostępnych wzorców i bibliotek, następnie rozważymy nasze ogólne potrzeby wzorcowe i potencjalne ograniczenia, a na koniec przejdziemy przez serię ćwiczeń krytycznego myślenia, aby dowiedzieć się, jak lepiej oceniać wzorce pod kątem dostępności.

Co za splątana sieć, którą tkamy

Overchoice wkradł się do wszystkich aspektów technologii, w tym wzorców i bibliotek, których używamy do tworzenia naszych cyfrowych kreacji — od prostego pola wyboru po złożone dynamiczne modalne i wszystko pomiędzy. Ale skąd mamy wiedzieć, który wzorzec lub biblioteka jest właściwa, skoro jest tak wiele możliwości wyboru? Czy lepiej korzystać z ustalonych wzorców/bibliotek, z którymi użytkownicy spotykają się na co dzień? A może lepiej stworzyć zupełnie nowe wzory, aby zapewnić bardziej przyjemne wrażenia użytkownika?

Mając do dyspozycji niezliczone opcje, możemy szybko zostać sparaliżowani nadmiarem wyborów. Ale jeśli cofniemy się o krok i zastanowimy, dlaczego w pierwszej kolejności budujemy nasze produkty cyfrowe (tj. użytkownika końcowego), czy nie ma sensu wybieranie wzorca lub biblioteki, która może wnieść największą wartość dla jak największej liczby osób ?

Jeśli myślałeś, że wybór wzoru lub biblioteki był już wystarczająco zniechęcającym procesem, może to być punkt, w którym zaczynasz się martwić. Ale nie musisz się martwić — wybór dostępnego wzoru/biblioteki nie jest nauką o rakietach. Jak wszystko inne w technologii, ta podróż zaczyna się od odrobiny wiedzy, ogromnej ilości prób i błędów oraz zrozumienia, że ​​nie ma tylko jednego idealnego wzorca/biblioteki, która pasuje do każdego użytkownika, sytuacji lub struktury.

Skąd mam to wiedzieć? Cóż, spędziłem ostatnie pięć lat na badaniu, budowaniu i testowaniu różnych typów dostępnych wzorców, pracując nad Przewodnikiem po stylach A11y, Biblioteką wzorców ARIA firmy Deque i oceniając popularne wzorce SVG. Ale sprawdziłem również wiele wzorców i bibliotek klientów na każdym frameworku/platformie, jaki można sobie wyobrazić. W tym momencie mogę bez skrupułów powiedzieć, że istnieje wrodzona hierarchia dostępności wzorców, która zaczyna się rozwijać, gdy patrzy się wystarczająco długo. I choć czasami zdarzają się wzorce, których należy unikać za wszelką cenę, nie zawsze jest to tak jednoznaczne. Jeśli chodzi o dostępność, twierdzę, że większość wzorców mieści się w gradientach: dobre, lepsze, najlepsze. Najtrudniejszą częścią jest wiedza, który wzór należy do jakiej kategorii.

Krytyczne myślenie o wzorcach

Skąd więc wiemy, które wzorce są dobre, lepsze, najlepsze, jeśli chodzi o dostępność? To zależy. To często przywoływane zdanie społeczności cyfrowej dostępności nie jest wykrętem, ale jest skrótem, ponieważ „potrzebujemy więcej kontekstu, aby móc udzielić najlepszej odpowiedzi”. Jednak kontekst nie zawsze jest jasny, więc budując i oceniając dostępność wzorca, zadaję kilka podstawowych pytań:

• Czy istnieje już ustalony dostępny wzór, którego możemy użyć?
• Jakie przeglądarki i urządzenia technologii wspomagających (AT) obsługujemy?
• Czy istnieją jakieś ograniczenia ramowe lub inne integracje/czynniki, które należy wziąć pod uwagę?

Oczywiście, twoje konkretne pytania mogą się różnić od moich, ale chodzi o to, że musisz zacząć wykorzystywać swoje umiejętności krytycznego myślenia podczas oceny wzorców. Możesz to zrobić, najpierw obserwując, analizując, a następnie oceniając każdy wzorzec pod kątem dostępności, zanim przejdziesz do ostatecznej decyzji. Ale zanim do tego dojdziemy, zagłębmy się nieco bardziej w początkowe pytania.

Czy istnieje już ustalony wzorzec dostępności?

Dlaczego wydaje się, że z każdym nowym frameworkiem otrzymujemy zupełnie nowy zestaw wzorców? To ciągłe odkrywanie koła na nowo z nowymi wyborami wzorów może dezorientować i frustrować programistów, zwłaszcza że zwykle nie jest to konieczne.

Nie wierzysz mi? Pomyśl o tym w ten sposób: jeśli subskrybujemy system projektowania atomowego, rozumiemy, że kilka małych „atomów” kodu łączy się, aby stworzyć większy produkt cyfrowy. Ale w świecie nauki atomy nie są najmniejszym składnikiem życia. Każdy atom składa się z wielu cząstek subatomowych, takich jak protony, neutrony i elektrony.

Ta sama logika może być zastosowana do naszych wzorców. Jeśli przyjrzymy się głębiej wszystkim wzorcom dostępnym w różnych istniejących strukturach, podstawowa struktura subatomowa jest zasadniczo taka sama, niezależnie od używanego języka kodowania. Dlatego doceniam usprawnione biblioteki kodowania z dostępnymi wzorcami, na których możemy budować w oparciu o potrzeby technologiczne i projektowe.

Uwaga : niektóre renomowane źródła obejmują Inclusive Components, Accessible Components i Gov.UK Design System, oprócz listy dostępnych wzorców, które niedawno opublikowano w magazynie Smashing Magazine (oraz bardziej szczegółową listę wzorców i bibliotek na końcu artykułu) .

Jakie przeglądarki i urządzenia technologii wspomagających (AT) obsługujemy?

Po zbadaniu kilku podstawowych wzorców, które mogą działać, możemy przejść do kwestii obsługi przeglądarek i urządzeń technologii wspomagających (AT). Sama obsługa przeglądarek nie jest żartem. Kiedy dodasz do tego urządzenia AT i specyfikacje ARIA, sprawy zaczynają się komplikować… nie niemożliwe, tylko o wiele więcej czasu, wysiłku i procesu myślowego, aby to wszystko rozgryźć.

Ale to nie wszystkie złe wieści. Istnieją wspaniałe zasoby, takie jak ułatwienia dostępu i obsługa ułatwień dostępu w HTML5, które pomagają nam lepiej zrozumieć obecną obsługę przeglądarek i urządzeń AT. Te strony internetowe przedstawiają różne dostępne podelementy wzorców HTML i ARIA, zawierają testy społeczności open source i dostarczają kilka przykładów wzorców — zarówno dla przeglądarek stacjonarnych, jak i mobilnych/urządzeń AT.

Czy są jakieś ograniczenia ramowe lub inne integracje/czynniki do rozważenia?

Po wybraniu kilku dostępnych wzorców podstawowych i uwzględnieniu obsługi przeglądarki/urządzeń AT, możemy przejść do bardziej szczegółowych pytań kontekstowych dotyczących wzorca i jego środowiska. Na przykład, jeśli używamy wzorca w systemie zarządzania treścią (CMS) lub rozważamy starszy kod, pojawią się pewne ograniczenia wzorca. W takim przypadku garść wzorów do wyboru można szybko skrócić do jednego lub dwóch. Z drugiej strony, niektóre frameworki są bardziej wyrozumiałe i otwarte na akceptację każdego wzorca, więc możemy mniej martwić się ograniczeniami frameworka i bardziej skupić się na dokonaniu najbardziej dostępnego wyboru wzorca, jakiego możemy dokonać.

Oprócz tego, co omówiliśmy do tej pory, przy wyborze wzorca należy wziąć pod uwagę wiele dodatkowych kwestii, takich jak wydajność, bezpieczeństwo, optymalizacja pod kątem wyszukiwarek, tłumaczenie językowe, integracja z innymi firmami i wiele innych. Czynniki te niewątpliwie wpłyną na wybór dostępnego wzoru, ale powinieneś także pomyśleć o ludziach tworzących treść. Dostępny wzorzec, który wybierzesz, musi być zbudowany w wystarczająco solidny sposób, aby poradzić sobie z potencjalnymi ograniczeniami dotyczącymi treści generowanych przez edytorów i/lub użytkowników.

Ocena wzorców pod kątem dostępności

Kod często mówi głośniej niż słowa, ale zanim przejdziemy do tego wszystkiego, szybko zauważ, że poniższe przykłady wzorców nie są jedynymi wzorcami dostępnymi dla każdej sytuacji, ani ten uważany za „najlepszy” w grupie nie jest najlepszą opcją w całej grupie. cały świat dostępnych wzorów.

W przypadku poniższych demonstracji wzorców powinniśmy wyobrazić sobie hipotetyczną sytuację, w której porównujemy każdą grupę wzorców ze sobą. Chociaż nie jest to realistyczna sytuacja, zapoznanie się z tymi ćwiczeniami krytycznego myślenia i ocena wzorców dostępności powinno pomóc w lepszym przygotowaniu się, gdy napotkasz wybór wzorca w prawdziwym świecie.

Dostępne wzory przycisków

Pierwsza grupa wzorców, które sprawdzimy pod kątem dostępności, jest wszechobecna w prawie każdej witrynie lub aplikacji: przyciski. Pierwszy wzorzec przycisku wykorzystuje rolę przycisku ARIA do naśladowania przycisku, podczas gdy drugi i trzeci wzorzec przycisku używają elementu HTML <button> . Trzeci wzorzec dodaje również aria-describedby i CSS, aby ukryć rzeczy wizualnie.

Dobrze: role="button"

 <a role="button" href="[link]">Sign up</a>

Lepiej: <button>

 <button type="button">Sign up</button>

Najlepsze: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Chociaż pierwsze wzorce na pierwszy rzut oka wydają się proste, wywołują one pewne pytania dotyczące ułatwień dostępu. Na przykład w pierwszym wzorcu przycisku widzimy, że ARIA role="button" jest używane we wzorcu „dobry” zamiast w elemencie HTML <button> . Myśląc w kategoriach dostępności, ponieważ wiemy, że element HTML <button> został wprowadzony w HTML4, możemy rozsądnie spekulować, że jest on w pełni obsługiwany przez najnowsze wersje wszystkich głównych przeglądarek i będzie działał dobrze z większością urządzeń AT. Ale jeśli zagłębimy się głębiej i przyjrzymy się obsłudze ułatwień dostępu dla ARIA role="button", zobaczymy niewielką przewagę z perspektywy technologii wspomagających, podczas gdy element HTML <button> brakuje niektórych obszarów zasięgu przeglądarki + AT, zwłaszcza jeśli weźmiemy pod uwagę obsługa sterowania głosowego.

Dlaczego więc wzorzec ARIA nie należy do kategorii „lepsze”? Czy ARIA nie czyni tego bardziej dostępnym? Nie. W rzeczywistości w takich przypadkach specjaliści od ułatwień dostępu często recytują pierwszą zasadę ARIA — nie używaj ARIA. To żartobliwy sposób na powiedzenie, że używaj elementów HTML, gdy tylko jest to możliwe. ARIA jest rzeczywiście potężna, ale w niewłaściwych rękach może wyrządzić więcej szkody niż pożytku. W rzeczywistości raport WebAIM Million stwierdza, że ​​„strony z ARIA zawierają średnio 60% więcej błędów niż te bez”. W związku z tym musisz wiedzieć, co robisz podczas korzystania z ARIA.

Kolejnym ostrzeżeniem przeciwko używaniu ARIA w tej sytuacji jest to, że potrzebna nam funkcjonalność przycisku musiałaby zostać zbudowana dla role="button" , podczas gdy ta funkcjonalność jest już wstępnie zapisana w elemencie <button> . Biorąc pod uwagę, że element <button> również ma 100% wsparcie dla przeglądarek i jest łatwym do zaimplementowania wzorcem, nieznacznie wyprzedza hierarchię podczas oceny dwóch pierwszych wzorców. Mamy nadzieję, że to porównanie pomoże obalić mit, że dodanie ARIA czyni wzór bardziej dostępnym — często jest odwrotnie.

Trzeci wzorzec przycisku pokazuje element HTML <button> połączony z aria-describedby z elementem ID, który jest wizualnie ukryty za pomocą CSS. Chociaż ten wzór jest nieco bardziej złożony, dodaje wiele kontekstu, tworząc związek między przyciskiem a celem. W razie wątpliwości, za każdym razem, gdy możemy dodać więcej kontekstu do sytuacji, tym lepiej, abyśmy mogli założyć, że jeśli jest poprawnie zakodowany, jest to najlepszy wzorzec przy porównywaniu tylko tych konkretnych wzorców przycisków.

Dostępne wzorce linków kontekstowych

Druga grupa wzorców, które omówimy, to linki kontekstowe. Te wzorce pomagają przekazać użytkownikom AT więcej informacji niż to, co jest widoczne na ekranie. Pierwszy wzorzec łącza wykorzystuje CSS do wizualnego ukrycia dodatkowych informacji kontekstowych. Podczas gdy wzorce drugiego i trzeciego łącza dodają atrybuty ARIA do miksu: odpowiednio aria-labelledby i aria-label .

Dobrze: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Lepiej: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Najlepsze: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Chociaż wszystkie trzy wzorce linków kontekstowych wyglądają tak samo, kiedy sprawdzamy kod lub testujemy je za pomocą urządzeń AT, istnieją pewne oczywiste różnice. Pierwszy wzorzec wykorzystuje technikę CSS do wizualnego ukrywania treści dla widzących użytkowników, ale nadal renderuje ukrytą treść dla niewidzących użytkowników AT. I chociaż ta technika powinna działać w większości przypadków, nie ma rzeczywistego związku między linkiem a dodatkowymi informacjami, więc połączenie jest w najlepszym razie niepewne. Jako taki, pierwszy wzorzec łącza jest dobrym wyborem, ale nie jest najsolidniejszym wzorcem łącza z trzech.

Kolejne dwa wzorce linków są nieco trudniejsze do oceny. Zgodnie ze specyfikacją ARIA z W3C „Cel aria-label jest taki sam, jak aria-labelledby . Zapewnia użytkownikowi rozpoznawalną nazwę obiektu.” Teoretycznie więc oba atrybuty powinny mieć tę samą podstawową funkcjonalność.

Jednak specyfikacje wskazują również, że programy użytkownika dają pierwszeństwo aria-labelledby przed aria-label przy podejmowaniu decyzji, którą dostępną nazwę przekazać użytkownikowi. Badania wykazały również problemy związane z automatycznym tłumaczeniem i atrybutami aria-label. Więc to oznacza, że ​​powinniśmy użyć aria-labelledby , prawda?

Cóż, nie tak szybko. Ta sama specyfikacja ARIA mówi: „Jeżeli interfejs jest taki, że nie jest możliwe umieszczenie widocznej etykiety na ekranie (lub jeśli widoczna etykieta nie jest pożądanym doświadczeniem użytkownika), autorzy powinni używać aria-label i nie powinni użyj aria-labelledby .” Porozmawiaj o zagmatwaniu — więc jaki wzór wybrać?

Gdybyśmy mieli duże potrzeby tłumaczeniowe, moglibyśmy zdecydować się na zmianę aspektu wizualnego i napisać linki z pełnym kontekstem (np. „ Czytaj więcej o tej niesamowitej rzeczy ”) lub zdecydować się na użycie aria-labelledby . Załóżmy jednak, że nie mieliśmy potrzeby tłumaczenia na dużą skalę lub mogliśmy odpowiedzieć na te potrzeby w rozsądny/przystępny sposób i nie chcieliśmy zmieniać oprawy wizualnej — co wtedy?

Bazując na aktualnych zaleceniach ARIA 1.1 (z obietnicą przetłumaczenia aria-label w ARIA 1.2) oraz fakcie, że aria-label jest nieco łatwiejsza do zaimplementowania dla programistów w porównaniu z aria-labelledby , możemy zdecydować się na zwiększenie wagi aria-label aria-labelledby w naszej ocenie wzorców. Jest to wyraźny przykład tego, kiedy kontekst ma duże znaczenie w naszym wyborze dostępnych wzorców.

Dostępne wzory <svg>

Na koniec przyjrzyjmy się grupie wzorców obrazów SVG pod kątem dostępności. Pliki SVG są wizualną reprezentacją kodu, ale mimo to kod. Oznacza to, że urządzenie AT może pominąć niedekoracyjny obraz SVG, chyba że do wzorca zostanie dodana role="img" .

Zakładając, że poniższe wzorce SVG mają charakter informacyjny, do każdego z nich dołączono funkcję role="img" . Pierwszy wzorzec SVG używa <title> i <text> w połączeniu z CSS, aby wizualnie ukryć zawartość przed widzącymi użytkownikami. Następne dwa wzorce SVG zawierają elementy <title> i <desc> , ale z atrybutem aria-labelledby dodanym do ostatniego wzorca.

Dobrze: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Lepiej: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Najlepsze: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Przyjrzyjmy się najpierw pierwszemu wzorcowi za pomocą <title> i <text> oraz wizualnie ukrytego CSS. W przeciwieństwie do poprzedniego, widocznie ukrytego tekstu we wzorach, istnieje nieodłączny związek między elementami <title> i <text> , ponieważ są one zgrupowane pod tym samym parasolem elementów SVG. Jednak ten związek nie jest bardzo silny. W rzeczywistości, jeśli spojrzysz wstecz na moje badania nad wzorcami SVG, zobaczymy, że tylko 3 z 8 kombinacji przeglądarka/AT usłyszało pełny komunikat. (Uwaga: wzór Świnia nr 1 jest odpowiednikiem wzoru żarówki nr 7).

Jest to prawdą, chociaż działające specyfikacje SVG W3C definiują element <text> jako „element graficzny składający się z tekstu… znaki do narysowania są wyrażone jako dane znakowe. W rezultacie dane tekstowe w treści SVG są łatwo dostępne dla osób niedowidzących”. Ten pierwszy wzór jest w porządku, ale możemy zrobić to lepiej.

Drugi wzorzec usuwa element <text> i zastępuje go elementem <desc> . Specyfikacje SVG W3C stwierdzają:

„Element potomny <title> reprezentuje krótką alternatywę tekstową dla elementu… a element <desc> reprezentuje bardziej szczegółowe informacje tekstowe dla elementu, takie jak opis.”

Oznacza to, że elementy <title> i <desc> w SVG mogą być używane podobnie do alternatywnego tekstu graficznego i opcji długiego opisu, które tradycyjnie znajdują się w elementach <img> . Po dodaniu elementu <desc> do drugiego SVG, widzimy podobną obsługę przeglądarki/AT, w której 3 z 8 kombinacji słyszy pełny komunikat. (Uwaga: wzór świni nr 2 jest odpowiednikiem wzorca żarówki nr 10). Chociaż te wyniki testu wydają się odzwierciedlać pierwszy wzorzec, powodem, dla którego ten wzorzec trafia do kategorii „lepsze”, jest to, że nieco łatwiej jest zaimplementować kod- mądry i wpływa na większą liczbę użytkowników AT, ponieważ działał na JAWS, VoiceOver desktop i VoiceOver mobile, podczas gdy pierwszy wzorzec obsługiwał mniej popularne kombinacje przeglądarki/AT.

Trzeci wzorzec ponownie używa elementów <title> i <desc> , ale teraz ma dodany identyfikator aria-labelledby plus ID. Zgodnie z tymi samymi testami SVG, dodanie tego dodatkowego fragmentu kodu oznacza, że ​​możemy w pełni obsługiwać 7 z 8 kombinacji przeglądarka/AT. (Uwaga: wzór świni nr 3 jest odpowiednikiem wzoru żarówki nr 11.) Spośród trzech wzorów SVG ten trzeci jest „najlepszy”, ponieważ obsługuje większość urządzeń AT. Ale ten wzorzec ma wadę w korzystaniu z niektórych kombinacji przeglądarki/AT; usłyszysz zduplikowaną treść tytułu/opisu obrazu dla tego wzorca. Chociaż potencjalnie irytujące dla użytkowników, uważam, że generalnie lepiej jest słyszeć zduplikowane treści niż wcale.

Myśli zamykające

Chociaż wszyscy z pewnością cenimy wybór w dziedzinie technologii, zastanawiam się, czy doszliśmy do momentu, w którym nadmiar opcji sparaliżował nas i zdezorientował, co dalej? Jeśli chodzi o wybór dostępnych wzorców, możemy zadawać proste pytania dotyczące opcji wzorców/biblioteki, obsługi przeglądarki/urządzeń AT, ograniczeń ramowych i innych.

Mając odpowiednie dane, odpowiedzi na te pytania są dość łatwe. Jednak staje się to nieco bardziej skomplikowane, gdy wychodzimy poza schematy i naprawdę bierzemy pod uwagę ludzi, którzy ich używają. Właśnie wtedy zdajemy sobie sprawę z wpływu naszych wyborów na zdolność naszych użytkowników do odniesienia sukcesu. Jak wymownie stwierdza prof. George Dei:

„Włączenie nie oznacza wprowadzania ludzi do tego, co już istnieje — to tworzenie nowej przestrzeni, lepszej przestrzeni dla wszystkich”.

Poświęcając nieco więcej czasu na krytyczne przemyślenie wzorców i wybranie najbardziej dostępnych, bez wątpienia stworzymy bardziej inkluzywną przestrzeń, aby dotrzeć do większej liczby użytkowników — na ich warunkach.

Powiązane zasoby

Narzędzia

• Wsparcie dostępności, Michael Fairchild, a11ysupport.io
• Dostępność HTML5, Steve Faulkner

Biblioteki wzorów

• Projekt dostępności
• Przewodnik po stylach dostępności
• Dostępne komponenty, Scott O'Hara
• Dostępna wtyczka drag-and-drop listy, Harris Schneiderman
• Biblioteka wzorów ARIA firmy Deque
• Dostępna biblioteka reakcji Deque
• System projektowania GOV.UK
• Dołączone komponenty, Heydon Pickering
• Amerykański system projektowania stron internetowych (USWDS)
• Samouczki dotyczące ułatwień dostępu w sieci