Kiedy CSS nie wystarczy: Wymagania JavaScript dla dostępnych komponentów

Jako autor ModernCSS.dev jestem wielkim zwolennikiem rozwiązań CSS. I uwielbiam widzieć sprytne sposoby, w jakie ludzie używają CSS do naprawdę nieszablonowych projektów i interaktywności! Zauważyłem jednak trend w kierunku promowania komponentów „tylko CSS” przy użyciu metod takich jak „checkbox hack”. Niestety, takie hacki powodują, że znaczna liczba użytkowników nie może korzystać z interfejsu.

W tym artykule omówiono kilka typowych komponentów i wyjaśniono, dlaczego CSS nie jest wystarczający do objęcia dostępności poprzez wyszczególnienie wymagań JavaScript. Wymagania te są oparte na wytycznych dotyczących dostępności treści internetowych (WCAG) i dodatkowych badaniach przeprowadzonych przez ekspertów ds. dostępności. Nie będę zalecał rozwiązań JavaScript ani demo CSS, a raczej zbadam, na co należy zwrócić uwagę podczas tworzenia każdego komponentu. Z pewnością można użyć frameworka JavaScript, ale nie jest to konieczne, aby dodać omawiane zdarzenia i funkcje.

Wymienione wymagania nie są w zasadzie opcjonalne — są niezbędne, aby zapewnić dostępność Twoich komponentów.

Jeśli korzystasz ze struktury lub biblioteki składników, możesz skorzystać z tego artykułu, aby ocenić, czy dostarczone składniki spełniają wymagania dotyczące ułatwień dostępu . Ważne jest, aby wiedzieć, że wiele z wymienionych elementów nie będzie w pełni objętych przez automatyczne narzędzia do testowania dostępności, takie jak aXe, i dlatego wymagają ręcznego testowania. Możesz też użyć platformy testowej, takiej jak Cypress, do tworzenia testów dla wymaganej funkcjonalności.

Pamiętaj, że ten artykuł skupia się na informowaniu o zagadnieniach związanych z JavaScriptem dla każdego komponentu interfejsu. Nie jest to wyczerpujące źródło wszystkich szczegółów implementacji do tworzenia w pełni dostępnych komponentów, takich jak niezbędna aria czy nawet znaczniki. Zasoby są dołączone do każdego typu, aby pomóc Ci dowiedzieć się więcej o szerszych rozważaniach dotyczących każdego komponentu.

Ustalanie, czy tylko CSS jest odpowiednim rozwiązaniem

Oto kilka pytań, które należy zadać, zanim przejdziesz do rozwiązania opartego tylko na CSS. Omówimy niektóre z przedstawionych tutaj terminów w szerszym kontekście wraz z ich powiązanymi komponentami.

• Czy to dla własnej przyjemności?
  W takim razie wejdź na całość w CSS, przekraczaj granice i dowiedz się, co ten język może zrobić!
• Czy funkcja obejmuje wyświetlanie i ukrywanie treści?
  Następnie potrzebujesz JS, aby co najmniej przełączać arię i włączać zamykanie na Esc . W przypadku niektórych typów składników, które również zmieniają stan, konieczne może być również informowanie o zmianach poprzez wyzwalanie aktualizacji w aktywnym regionie ARIA.
• Czy naturalny porządek ostrości jest najbardziej idealny?
  Jeśli naturalna kolejność utraci związek między wyzwalaczem a elementem, który wyzwolił lub użytkownik klawiatury nie może nawet uzyskać dostępu do treści za pomocą naturalnej kolejności tabulacji, potrzebujesz JS, aby pomóc w zarządzaniu fokusem.
• Czy stylizowana kontrolka podaje prawidłowe informacje o funkcjonalności?
  Użytkownicy technologii wspomagających, takich jak czytniki ekranu, otrzymują informacje oparte na semantyce i ARIA, które pomagają im określić, co robi kontrolka. Ponadto użytkownicy rozpoznawania mowy muszą być w stanie zidentyfikować etykietę lub typ komponentu, aby opracować frazę używaną do obsługi elementów sterujących. Na przykład, jeśli Twój komponent jest stylizowany jak tabulatory, ale używa przycisków opcji do „działania” jak karty, czytnik ekranu może usłyszeć „przycisk radiowy”, a użytkownik mowy może spróbować użyć słowa „karta”, aby je obsługiwać. W takich przypadkach będziesz potrzebować JS, aby umożliwić korzystanie z odpowiednich kontrolek i semantyki w celu osiągnięcia pożądanej funkcjonalności.
• Czy efekt zależy od najechania kursorem i/lub skupienia?
  Wtedy możesz potrzebować JS, aby pomóc w alternatywnym rozwiązaniu zapewniającym równy dostęp lub stały dostęp do treści, szczególnie dla użytkowników ekranu dotykowego i osób korzystających z zoomu pulpitu 200%+ lub oprogramowania do powiększania.

Szybka wskazówka : Innym punktem odniesienia podczas tworzenia dowolnego rodzaju niestandardowej kontroli jest lista kontrolna dostępna dla niestandardowych kontroli z przewodnika W3 „Korzystanie z funkcji ARIA”. Wspomina to o kilku punktach powyżej, z kilkoma dodatkowymi rozważaniami projektowymi i semantycznymi.

Podpowiedzi

Zawężenie definicji podpowiedzi jest nieco trudne, ale w tej sekcji mówimy o małych etykietach tekstowych, które pojawiają się po najechaniu myszą w pobliżu elementu wyzwalającego. Nakładają się na inne treści, nie wymagają interakcji i znikają, gdy użytkownik usunie wskaźnik myszy lub fokus.

Rozwiązanie oparte wyłącznie na CSS może wydawać się całkowicie w porządku i można je osiągnąć za pomocą czegoś takiego:

 <button class="tooltip-trigger">I have a tooltip</button> <span class="tooltip">Tooltip</span> .tooltip { display: none; } .tooltip-trigger:hover + .tooltip, .tooltip-trigger:focus + .tooltip { display: block; }

Jednak ignoruje to listę problemów związanych z dostępnością i wyklucza wielu użytkowników z dostępu do treści podpowiedzi.

Duża grupa wykluczonych użytkowników to użytkownicy korzystający z ekranów dotykowych, na których :hover prawdopodobnie nie zostanie wywołane, ponieważ na ekranach dotykowych zdarzenie :hover jest wyzwalane zsynchronizowane ze zdarzeniem :focus . Oznacza to, że każda powiązana akcja połączona z elementem wyzwalającym — taka jak przycisk lub łącze — zostanie uruchomiona wraz z odsłanianą podpowiedzią. Oznacza to, że użytkownik może przegapić podpowiedź lub nie mieć czasu na przeczytanie jej zawartości.

W przypadku, gdy podpowiedź jest dołączona do interaktywnego elementu bez zdarzeń, podpowiedź może się wyświetlać, ale nie można jej odrzucić, dopóki inny element nie stanie się aktywny, a w międzyczasie może zablokować zawartość i uniemożliwić użytkownikowi wykonanie zadania.

Ponadto użytkownicy, którzy muszą używać oprogramowania do powiększania lub powiększania, aby nawigować, również napotykają sporą przeszkodę w korzystaniu z podpowiedzi. Ponieważ podpowiedzi są ujawniane po najechaniu kursorem, jeśli ci użytkownicy muszą zmienić swoje pole widzenia, przesuwając ekran, aby przeczytać podpowiedź, może to spowodować jej zniknięcie. Etykietki narzędzi również usuwają kontrolę z użytkownika, ponieważ często nic nie mówi użytkownikowi, że etykietka pojawi się z wyprzedzeniem. Nakładka treści może uniemożliwić im wykonanie zadania. W niektórych sytuacjach, takich jak podpowiedź powiązana z polem formularza, klawiatura mobilna lub inna klawiatura ekranowa może przesłaniać treść podpowiedzi. A jeśli nie są odpowiednio połączone z elementem wyzwalającym, niektórzy użytkownicy technologii wspomagających mogą nawet nie wiedzieć, że pojawiła się podpowiedź.

Wskazówki dotyczące zachowania podpowiedzi pochodzą z kryterium sukcesu WCAG 1.4.13 — Treść po najechaniu lub skupieniu. To kryterium ma na celu pomóc użytkownikom słabowidzącym oraz korzystającym z oprogramowania do powiększania i powiększania. Zasady przewodnie dla podpowiedzi (i innych treści pojawiających się po najechaniu kursorem i fokusie) obejmują:

• Odrzucone
  Podpowiedź można zamknąć bez poruszania kursorem lub fokusem
• Unoszący się
  Ujawnioną zawartość podpowiedzi można najechać kursorem bez jej zniknięcia
• Trwały
  Dodatkowa zawartość nie znika po przekroczeniu limitu czasu, ale czeka, aż użytkownik usunie najechanie kursorem lub fokus lub w inny sposób je odrzuci

Aby w pełni spełnić te wytyczne, wymagana jest pomoc JavaScript, zwłaszcza w celu umożliwienia odrzucenia treści.

• Użytkownicy technologii pomocniczych założą, że zachowanie odrzucania jest powiązane z klawiszem Esc , który wymaga detektora JavaScript.
• Zgodnie z badaniami Sarah Higley opisanymi w następnej sekcji, dodanie widocznego przycisku „zamknij” w podpowiedzi wymagałoby również, aby JavaScript obsłużył jego zdarzenie zamknięcia.
• Możliwe, że JavaScript będzie musiał ulepszyć rozwiązanie do stylizacji, aby użytkownik mógł najechać kursorem na treść podpowiedzi bez jej odrzucania, gdy użytkownik porusza myszą.

Alternatywy dla podpowiedzi

Podpowiedzi powinny być ostatecznością. Sarah Higley — ekspert ds. ułatwień dostępu, której szczególną pasją jest zniechęcanie do używania podpowiedzi — oferuje ten prosty test:

„Dlaczego dodaję ten tekst do interfejsu użytkownika? Gdzie indziej mógłby się udać?

— Sarah Higley z prezentacji „Podpowiedzi: Badanie na cztery części”

Na podstawie badań, w które Sarah brała udział w swojej roli w Microsoft, alternatywnym rozwiązaniem jest dedykowana „toggletip”. Zasadniczo oznacza to dostarczenie dodatkowego elementu, który pozwoli użytkownikowi celowo wywołać wyświetlanie i ukrywanie dodatkowej treści . W przeciwieństwie do podpowiedzi, podpowiedzi mogą zachowywać semantykę elementów w ujawnionej treści. Dają również użytkownikowi z powrotem kontrolę nad ich przełączaniem i zachowują wykrywalność i funkcjonalność dla większej liczby użytkowników, w szczególności użytkowników ekranu dotykowego.

Jeśli pamiętasz, że atrybut title istnieje, po prostu wiedz, że cierpi na te same problemy, które zauważyliśmy w naszym rozwiązaniu wykorzystującym tylko CSS. Innymi słowy — nie używaj title , zakładając, że jest to akceptowalne rozwiązanie podpowiedzi.

Aby uzyskać więcej informacji, zapoznaj się z prezentacją Sarah na YouTube, a także jej obszernym artykułem na temat podpowiedzi. Aby dowiedzieć się więcej na temat podpowiedzi w porównaniu z podpowiedziami przełączania i nieco więcej informacji na temat tego, dlaczego nie używać title , zapoznaj się z artykułem Heydona Pickeringa w Inclusive Components: Tooltips and Toggletips.

Modals

Modals — czyli lightboxy lub okna dialogowe — to okna na stronie, które pojawiają się po akcji wyzwalającej. Nakładają się na inną zawartość strony, mogą zawierać uporządkowane informacje, w tym dodatkowe czynności, i często mają półprzezroczyste tło, które pomaga odróżnić okno modalne od reszty strony.

Widziałem kilka odmian modalnego tylko CSS (i jestem winny zrobienia jednego dla starszej wersji mojego portfolio). Mogą użyć „hakowania pola wyboru”, skorzystać z zachowania :target , lub spróbować ukształtować je z :focus (co jest prawdopodobnie naprawdę przesadną wskazówką w przebraniu).

Jeśli chodzi o element dialog HTML, pamiętaj, że nie jest on uważany za wszechstronnie dostępny. Tak więc, chociaż zdecydowanie zachęcam ludzi do używania natywnego HTML przed niestandardowymi rozwiązaniami, niestety ten łamie ten pomysł. Możesz dowiedzieć się więcej o tym, dlaczego dialog HTML jest niedostępne.

W przeciwieństwie do podpowiedzi, mody mają na celu umożliwienie zawartości strukturalnej. Oznacza to potencjalnie nagłówek, treść akapitu i elementy interaktywne, takie jak łącza, przyciski, a nawet formularze. Aby większość użytkowników miała dostęp do tych treści, muszą mieć możliwość korzystania ze zdarzeń klawiatury , w szczególności tabulacji. W przypadku dłuższej zawartości modalnej klawisze strzałek powinny również zachować możliwość przewijania. I podobnie jak podpowiedzi, powinny być odrzucane za pomocą klawisza Esc — i nie ma możliwości włączenia tego tylko w CSS.

JavaScript jest wymagany do zarządzania fokusami w modach. Modały powinny zatrzymywać fokus, co oznacza, że ​​gdy fokus znajdzie się w modalnym, użytkownik nie powinien mieć możliwości wyjścia z niego na znajdującą się za nim zawartość strony. Ale najpierw należy skupić się na środku modalnym, co wymaga również JavaScript, aby uzyskać w pełni dostępne rozwiązanie modalne.

Oto sekwencja zdarzeń powiązanych modalnie, którymi należy zarządzać za pomocą JavaScript:

1. Odbiornik zdarzeń na przycisku otwiera mod
2. Fokus znajduje się w obrębie modu; który element zmienia się w zależności od treści modalnej (patrz drzewo decyzyjne)
3. Fokus jest uwięziony w module modalnym, dopóki nie zostanie odrzucony
4. Najlepiej, aby użytkownik mógł zamknąć modalny klawiszem Esc oprócz dedykowanego przycisku zamykania lub destrukcyjnej akcji przycisku, takiej jak „Anuluj”, jeśli wymagane jest potwierdzenie zawartości modalnej
   1. Jeśli Esc jest dozwolony, kliknięcia modalnego tła powinny również odrzucić modalne
5. Po zamknięciu, jeśli nie nastąpiła nawigacja, fokus jest ponownie umieszczany na elemencie przycisku wyzwalającego

Drzewo decyzyjne skupienia modalnego

W oparciu o przykład dialogu modalnego WAI-ARIA Authoring Practices, oto uproszczone drzewo decyzyjne określające, gdzie należy umieścić fokus po otwarciu modu. Kontekst zawsze będzie dyktował wybór tutaj, a najlepiej byłoby, gdyby koncentracja była zarządzana dalej niż po prostu „pierwszy element, na który można się skupić”. W rzeczywistości czasami trzeba wybrać elementy, na których nie można ustawić ostrości.

• Podstawowym przedmiotem modalnego jest forma.
  Skoncentruj się na pierwszym polu formularza.
• Treść modalna ma znaczną długość i wypycha działania modalne z widoku.
  Skoncentruj nagłówek, jeśli jest obecny, lub pierwszy akapit.
• Cel modu jest proceduralny (przykład: potwierdzenie akcji) z wieloma dostępnymi akcjami.
  Skoncentruj się na „najmniej destrukcyjnym” działaniu w oparciu o kontekst (przykład: „OK”).
• Cel modalny jest proceduralny z jednym działaniem.
  Skoncentruj się na pierwszym elemencie, na który można ustawić ostrość

Szybka wskazówka : w przypadku konieczności skoncentrowania się na elemencie, na który nie można się skoncentrować, takim jak nagłówek lub akapit, dodaj tabindex="-1" , co pozwala programowo ustawić fokus na elemencie za pomocą JS, ale nie dodaje go do kolejności kart DOM .

Więcej informacji na temat innych wymagań dotyczących konfiguracji ARIA oraz dodatkowe informacje na temat wybierania elementu, do którego ma zostać dodany fokus, można znaleźć w modalnej wersji demonstracyjnej WAI-ARIA. Demo zawiera również JavaScript, aby zilustrować, jak zarządzać fokusem.

Aby uzyskać gotowe rozwiązanie, Kitty Giraudel stworzyła okno dialogowe 11y, które zawiera omówione przez nas wymagania dotyczące funkcji. Adrian Roselli zbadał również zarządzanie skupieniem się na oknach dialogowych modalnych i stworzył demonstrację oraz skompilował informacje o tym, jak różne kombinacje przeglądarki i czytnika ekranu będą komunikować dany element.

Karty

Interfejsy z zakładkami obejmują szereg wyzwalaczy, które wyświetlają po jednym odpowiednim panelu treści. „Atrakcje” CSS, które możesz znaleźć w tym przypadku, obejmują stylizowane przyciski opcji lub :target , które umożliwiają wyświetlanie tylko jednego panelu naraz.

Oto funkcje kart, które wymagają JavaScript:

1. Przełączanie atrybutu aria-selected na true dla bieżącej karty i false dla niezaznaczonych kart
2. Tworzenie wędrującego tabindex w celu odróżnienia wyboru tabulatora od fokusu
3. Przenieś fokus między kartami, odpowiadając na zdarzenia klawiszy strzałek (i opcjonalnie Home i End )

Opcjonalnie możesz wybrać opcję podążania za fokusem — co oznacza, że ​​gdy karta jest skoncentrowana, jest ona również zaznaczana i wyświetla powiązany z nią panel kart. Praktyki autorskie WAI-ARIA oferują ten przewodnik, jak dokonać wyboru, czy selekcja powinna podążać za fokusem.

Niezależnie od tego, czy wybierzesz opcję śledzenia fokusa, będziesz także używać JavaScript do nasłuchiwania zdarzeń klawiszy strzałek, aby przenosić fokus między elementami karty. Jest to alternatywny wzorzec umożliwiający nawigację po opcjach tabulatorów, ponieważ użycie ruchomego tabindex (opisanego dalej) zmienia naturalną kolejność fokusów na klawiaturze.

O Roving tabindex

Koncepcja wędrującego tabindex polega na tym, że wartość wartości tabindex jest sterowana programowo w celu zarządzania kolejnością skupienia elementów. W odniesieniu do kart oznacza to, że tylko wybrana karta jest częścią kolejności fokusów poprzez ustawienie tabindex="0" , a niezaznaczone karty są ustawione na tabindex="-1" , co usuwa je z naturalnej kolejności fokusów klawiatury.

Powodem tego jest to, że po wybraniu karty następna karta spowoduje skupienie użytkownika na powiązanym panelu kart. Możesz ustawić fokus na elemencie panelu kart, przypisując mu tabindex="0" , lub może to nie być konieczne, jeśli istnieje gwarancja, że ​​w panelu z kartami będzie można skoncentrować się na elemencie . Jeśli zawartość panelu kart będzie bardziej zmienna lub złożona, możesz rozważyć zarządzanie fokusem zgodnie z drzewem decyzyjnym, które sprawdziliśmy pod kątem modów.

Przykładowe wzorce tabulacji

Oto kilka wzorców referencyjnych do tworzenia kart:

• Demonstracja Tabpanelu z Uniwersytetu Deque
• Testy widżetów zakładek od Scotta O'Hary (testuje kilka wzorców funkcjonalnych)
• Interfejsy z zakładkami z Heydon Pickering's Inclusive Components , który pokazuje, w jaki sposób zakładki mogą być progresywnym ulepszeniem spisu treści

Karuzele

Nazywane również pokazami slajdów lub suwakami, karuzele zawierają serię obracających się paneli treści (tzw. „slajdy”), które zawierają mechanizmy kontrolne. Znajdziesz je w wielu konfiguracjach z szeroką gamą treści. Są dość powszechnie uważane za zły wzorzec projektowy.

Trudną częścią karuzeli z CSS jest to, że mogą nie oferować elementów sterujących lub mogą używać nieoczekiwanych elementów sterujących do manipulowania ruchem karuzeli. Na przykład możesz ponownie użyć „hakowania z polami wyboru”, aby spowodować przejście karuzeli, ale pola wyboru przekazują niewłaściwy typ informacji o interakcji użytkownikom technologii wspomagających. Ponadto, jeśli zmienisz styl etykiet pól wyboru tak, aby wyglądały wizualnie jako strzałki do przodu i do tyłu, prawdopodobnie użytkownicy oprogramowania do rozpoznawania mowy będą mieli błędne wrażenie, co powinni powiedzieć, aby sterować karuzelą.

Niedawno pojawiła się natywna obsługa CSS dla przyciągania przewijania. Na pierwszy rzut oka wydaje się to idealnym rozwiązaniem tylko dla CSS. Jednak nawet automatyczne sprawdzanie dostępności oznaczy je jako niemożliwe do nawigowania przez użytkowników klawiatury, na wypadek gdyby nie było możliwości nawigowania po nich za pomocą elementów interaktywnych. Istnieją inne problemy związane z dostępnością i doświadczeniem użytkownika związane z domyślnym zachowaniem tej funkcji, z których niektóre umieściłem w moim demo Snap Snap przewijania na SmolCSS.

Pomimo szerokiego zakresu wyglądu karuzeli, istnieje kilka wspólnych cech. Jedną z opcji jest utworzenie karuzeli za pomocą znaczników tabulacji, ponieważ w rzeczywistości jest to ten sam interfejs ze zmienioną prezentacją wizualną. W porównaniu z kartami karuzele mogą oferować dodatkowe elementy sterujące dla poprzedniego i następnego, a także wstrzymywać się, jeśli karuzela odtwarza się automatycznie.

Poniżej przedstawiono uwagi dotyczące JavaScript w zależności od funkcji karuzeli:

• Korzystanie z kontroli stronicowanych
  Po wybraniu ponumerowanego elementu programowo ustaw fokus na powiązanym slajdzie karuzeli. Będzie to obejmować konfigurowanie pojemników na slajdy za pomocą wędrującego tabindex, dzięki czemu można skupić się na bieżącym slajdzie, ale uniemożliwić dostęp do slajdów poza ekranem.
• Korzystanie z autoodtwarzania
  Dołącz kontrolkę pauzy, a także włącz wstrzymywanie, gdy slajd jest najechany lub interaktywny element w nim jest skupiony. Dodatkowo możesz sprawdzić prefers-reduced-motion w JavaScript, aby załadować pokaz slajdów w stanie wstrzymania, aby przestrzegać preferencji użytkownika.
• Korzystanie z poprzednich/następnych elementów sterujących
  Dołącz wizualnie ukryty element oznaczony jako aria-live="polite" i po aktywacji tych elementów sterujących wypełnij obszar na żywo wskazaniem bieżącej pozycji, np. „Slajd 2 z 4”.

Zasoby do tworzenia dostępnych karuzeli

• Dokładne szczegóły implementacji i rozważania, a także pełny przykład kodu z samouczka W3C Web Accessibility na temat karuzeli
• Przykład Deque University, jak ulepszyć interfejs kart w karuzelę
• Przykład praktyki autorskiej WAI-ARIA karuzeli obrazów z automatycznym obracaniem
• Wybór zasobów karuzeli w zestawieniu dostępnych komponentów Smashing

Menu rozwijane

Odnosi się to do komponentu, w którym przycisk przełącza otwiera listę łączy, zwykle używanych w menu nawigacyjnych. Implementacje CSS, które zatrzymują się na wyświetlaniu menu na :hover lub :focus , pomijają tylko niektóre ważne szczegóły.

Przyznam, że nawet pomyślałem, że używając nowszej właściwości :focus-within , możemy bezpiecznie zaimplementować rozwiązanie oparte wyłącznie na CSS. Zobaczysz, że mój artykuł na temat rozwijanych menu CSS został poprawiony, aby uwzględnić uwagi i zasoby dotyczące niezbędnego JavaScriptu (zachowałem tytuł, aby inne osoby poszukujące tego rozwiązania, miejmy nadzieję, również dokończyły implementację JS). W szczególności poleganie wyłącznie na CSS oznacza naruszenie kryterium sukcesu WCAG 1.4.13: Treść po najechaniu lub skupieniu, o której dowiedzieliśmy się dzięki podpowiedziom.

Musimy dodać JavaScript, aby uzyskać kilka technik, które w tym momencie powinny brzmieć znajomo:

• Przełączanie aria-expanded na przycisku menu między true a false przez słuchanie zdarzeń click
• Zamykanie otwartego menu po użyciu klawisza Esc i powrót fokusa do przycisku przełączania menu
• Najlepiej zamykanie otwartych menu, gdy fokus jest przesunięty poza menu
• Opcjonalnie : zaimplementuj klawisze strzałek oraz klawisze Home i End do nawigacji między przyciskami przełączania menu i linkami w menu rozwijanych

Szybka wskazówka : Zapewnij poprawną implementację menu rozwijanego, kojarząc wyświetlanie menu z selektorem .dropdown-toggle[aria-expanded= " true " ] + .dropdown , zamiast opierać wyświetlanie menu na obecności dodatkowego kodu JS- dodano klasę jak active . To również usuwa pewną złożoność z twojego rozwiązania JS!

Jest to również określane jako „wzorzec ujawniania”, a więcej szczegółów można znaleźć w przykładowym menu nawigacji ujawnień WAI-ARIA Authoring Practices.

Dodatkowe zasoby dotyczące tworzenia dostępnych komponentów

• Kompletny przewodnik Smashing po dostępnych komponentach front-end
• Artykuł Carie Fisher Good, Better, Best: Untangling The Complex World Of Accessible Patterns
• Prezentacje i informacje o typowych wzorcach projektowych i widżetach dostępne w WAI-ARIA Authoring Practices 1.2
• Biblioteka kodów Uniwersytetu Deque
• Dostępne komponenty Scotta O'Hary
• Dołączone komponenty Heydon Pickering