WCAG 2.5.6: Równoczesne mechanizmy wprowadzania danych

Co oznacza ta zasada

\n

WCAG 2.5.6 — Concurrent Input Mechanisms to kryterium sukcesu na poziomie AAA w WCAG 2.2. Jego podstawowy wymóg jest prosty: treści internetowe nie mogą ograniczać ani zakłócać możliwości użytkownika korzystania z wielu mechanizmów wprowadzania jednocześnie lub zamiennie. W praktyce oznacza to, że strona internetowa lub aplikacja nie może programowo wykrywać, z jakiego urządzenia wejściowego użytkownik aktualnie korzysta, a następnie „zamykać” go w tej jednej modalności, odmawiając mu dostępu do innych dostępnych metod wprowadzania.

\n

Nowoczesne urządzenia obsługują bogatą gamę mechanizmów wprowadzania: fizyczne klawiatury, myszy i gładziki, ekrany dotykowe, rysiki, przełączniki, sterowanie głosem, śledzenie ruchu oczu i inne. Wielu użytkowników polega na więcej niż jednym z nich jednocześnie — na przykład użytkownik laptopa z ekranem dotykowym może płynnie przełączać się między touchpadem a interfejsem dotykowym palcem. Zaawansowany użytkownik może nawigować po formularzu za pomocą klawiatury, jednocześnie używając myszy do przewijania. Osoba z niepełnosprawnością ruchową może korzystać z kombinacji wskaźnika nagłownego i urządzenia przełącznikowego. Kryterium chroni wszystkie te sposoby pracy.

\n

Naruszenie występuje, gdy strona internetowa używa JavaScriptu do wykrywania typu używanego wejścia, a następnie usuwa lub wyłącza funkcjonalność dla innych typów wejścia. Na przykład, jeśli witryna wykryje zdarzenie dotykowe, a następnie usunie wskaźniki fokusu klawiatury lub wyłączy nawigację klawiaturą, jest to bezpośrednie naruszenie. Podobnie, blokowanie wejścia wskaźnika po wykryciu użycia klawiatury lub używanie interfejsów API platformy do sztucznego ograniczania wejścia do jednej modalności — wszystko to stanowi naruszenia.

\n

Zgodność ma miejsce, gdy użytkownicy mogą w dowolnym momencie interakcji korzystać z dowolnych dostępnych mechanizmów wprowadzania. Treść powinna poprawnie reagować na każdy mechanizm wprowadzania, który użytkownik zdecyduje się w danej chwili zastosować, bez konieczności przeładowania strony, przełączania trybu czy podejmowania dodatkowych działań w celu ponownego włączenia danego typu wejścia.

\n

Kryterium zawiera jeden oficjalny wyjątek zdefiniowany w WCAG: ograniczenie jest dozwolone tam, gdzie jest to niezbędne — czyli tam, gdzie określona modalność wejścia jest wewnętrznie wymagana. Klasycznym przykładem jest aplikacja do rozpoznawania pisma odręcznego, w której wejście dotykowe lub za pomocą rysika jest istotą funkcjonalności. Innym przykładem może być pole do składania podpisu cyfrowego, które wymaga określonego wejścia wskaźnikiem. Nawet w takich przypadkach wyjątek należy interpretować wąsko, a autor powinien zapewnić alternatywne sposoby wykonania zadania wszędzie tam, gdzie to możliwe.

\n

Ważne jest, aby zauważyć, że to kryterium nie wymaga od autorów dodawania obsługi mechanizmów wprowadzania, których urządzenie nie posiada. Reguluje ono ograniczenia nakładane na mechanizmy, które urządzenie i platforma już obsługują. Jeśli urządzenie nie ma ekranu dotykowego, nie ma czego ograniczać.

\n\n

Dlaczego to ma znaczenie

\n

Możliwość korzystania z równoczesnych lub zamiennych mechanizmów wprowadzania nie jest funkcją wygody — to kluczowy wymóg dostępności, który bezpośrednio wpływa na kilka odrębnych grup użytkowników.

\n

Użytkownicy z niepełnosprawnościami ruchowymi często polegają na technologiach asystujących, które łączą wiele mechanizmów wprowadzania. Osoba z ograniczoną sprawnością rąk może używać urządzenia typu sip-and-puff wraz z klawiaturą ekranową. Ktoś z drżeniem może zacząć nawigację po stronie za pomocą klawiatury, ale przełączyć się na mysz lub interfejs dotykowy, gdy skrót klawiaturowy zawiedzie. Jeśli strona internetowa wykryje jeden typ wejścia i wyłączy inne, tacy użytkownicy mogą zostać całkowicie odcięci od treści lub funkcjonalności.

\n

Użytkownicy z niepełnosprawnościami poznawczymi lub trudnościami w uczeniu się często odnoszą korzyści z możliwości wyboru metody wprowadzania, która wydaje się najbardziej komfortowa lub naturalna dla danego zadania. Wymuszanie jednej modalności odbiera ten wybór i może wprowadzać niepotrzebne obciążenie poznawcze, szczególnie gdy użytkownik nie jest biegły w podstawowej metodzie wprowadzania urządzenia.

\n

Osoby starsze, które mogą mieć związane z wiekiem trudności ruchowe, coraz częściej korzystają z urządzeń obsługujących zarówno dotyk, jak i klawiaturę. Możliwość przełączania się między tymi mechanizmami, gdy precyzja ruchów drobnych zmienia się w ciągu dnia, jest ważna dla utrzymania samodzielnego korzystania z sieci.

\n

Zaawansowani użytkownicy i użytkownicy urządzeń multimodalnych — tacy jak użytkownicy Surface Pro czy iPad Pro — regularnie używają klawiatury, rysika i interfejsu dotykowego na tym samym urządzeniu w tej samej sesji. Strona, która wykrywa wejście dotykowe i usuwa skróty klawiaturowe lub odwrotnie, pogarsza doświadczenie ogromnej grupy użytkowników, którzy mogą nie identyfikować się jako osoby z niepełnosprawnościami.

\n

Rozważmy ten scenariusz z życia wzięty: internetowy portal tureckiego banku wykrywa, że klient korzysta z tabletu z ekranem dotykowym i przełącza się w „tryb mobilny”, który wyłącza nawigację klawiaturą. Klient z niepełnosprawnością ruchową, który używa tabletu z klawiaturą Bluetooth, nie może już przechodzić między polami formularza za pomocą klawisza Tab, nawigować po menu klawiszami strzałek ani używać skrótów klawiaturowych. Nie jest w stanie samodzielnie wykonać swoich zadań bankowych. To nie tylko porażka w zakresie dostępności, ale także potencjalne ryzyko prawne w świetle tureckich regulacji dotyczących dostępności.

\n

Z perspektywy użyteczności i SEO poszanowanie równoczesnych mechanizmów wprowadzania koreluje z lepszymi wynikami Core Web Vitals, niższymi współczynnikami odrzuceń i wyższą satysfakcją użytkowników w różnych kategoriach urządzeń — wszystkimi sygnałami, które wyszukiwarki nagradzają.

\n\n

Powiązane reguły Axe-core

\n

WCAG 2.5.6 wymaga ręcznego testowania — nie istnieje zautomatyzowana reguła axe-core, która mogłaby niezawodnie wykryć wszystkie naruszenia tego kryterium. Powód jest fundamentalny: narzędzia automatyczne mogą analizować statyczny DOM i CSS oraz wykrywać pewne wzorce JavaScriptu, ale nie są w stanie w pełni obserwować zachowania w czasie rzeczywistym nasłuchiwaczy zdarzeń, gdy reagują na różne modalności wejścia podczas rzeczywistej sesji użytkownika. Decyzja o ograniczeniu mechanizmu wprowadzania jest często zakodowana w logice aplikacji, która wykonuje się tylko w odpowiedzi na określone zdarzenia, co sprawia, że analiza statyczna jest niewystarczająca.

\n

\n
• Nie istnieje dedykowana zautomatyzowana reguła axe-core dla 2.5.6. Axe-core nie dostarcza reguły, która wprost sprawdzałaby ograniczenia równoczesnych mechanizmów wprowadzania, ponieważ naruszenie przejawia się jako dynamiczne zachowanie JavaScriptu, a nie strukturalny problem HTML lub ARIA. Strona może przejść wszystkie zautomatyzowane testy axe, a mimo to naruszać 2.5.6, jeśli jej procedury obsługi zdarzeń programowo usuwają lub wyłączają modalności wejścia w czasie działania.
\n
• Zdarzenia wskaźnika i wykrywanie zdarzeń dotykowych: Chociaż axe-core nie może wykryć samego ograniczenia, audytorzy ręczni powinni szukać JavaScriptu, który nasłuchuje zdarzeń touchstart lub pointerdown, a następnie modyfikuje DOM, usuwa zarządzanie fokusem lub ustawia flagi zmieniające zachowanie klawiatury. Podobnie, nasłuchiwacze keydown, które wywołują zmiany klas CSS ukrywające cele dotykowe, są sygnałami ostrzegawczymi wymagającymi ręcznej inspekcji.
\n
• Dlaczego automatyzacja jest niewystarczająca: Skanery automatyczne analizują dokument w określonym momencie. Ograniczenia mechanizmów wprowadzania są warunkowe — aktywują się dopiero po wywołaniu konkretnego zdarzenia wejściowego. Skaner uruchomiony przed interakcją użytkownika nie jest w stanie zobaczyć, że procedura obsługi touchstart później wywoła document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) i w praktyce zniszczy nawigację klawiaturą. Tylko tester ludzki, który kolejno użyje obu modalności wejścia, może wykryć takie naruszenie.
\n

\n\n

Jak testować

\n

\n
1. Zautomatyzowany skan bazowy: Uruchom axe DevTools lub Lighthouse na stronie, aby ustalić punkt odniesienia i wychwycić wszelkie współwystępujące problemy. Chociaż żadne z narzędzi nie ma dedykowanej reguły 2.5.6, kontrole best practices w axe DevTools mogą oznaczyć pułapki klawiaturowe lub problemy z zarządzaniem fokusem, które są symptomatyczne dla ograniczeń wejścia. Zanotuj wszelkie naruszenia do usunięcia wraz z ręcznymi kontrolami opisanymi poniżej.
\n
2. Inspekcja źródła JavaScript i nasłuchiwaczy zdarzeń: Otwórz Chrome DevTools, przejdź do panelu Elements i użyj panelu Event Listeners, aby sprawdzić, czy do dokumentu lub elementu body są podłączone nasłuchiwacze touchstart, pointerdown, pointermove lub MSPointerDown. W konsoli przeszukaj źródło JavaScript strony pod kątem wzorców takich jak ontouchstart in window, navigator.maxTouchPoints lub 'pointer' in navigator w połączeniu z modyfikacjami DOM. To typowe techniki używane do wykrywania modalności wejścia i warunkowego udostępniania funkcjonalności.
\n
3. Test interakcji multimodalnej (klawiatura + dotyk): Na urządzeniu obsługującym zarówno dotyk, jak i klawiaturę (np. Surface, iPad z klawiaturą lub laptop z ekranem dotykowym) zacznij nawigować po stronie wyłącznie za pomocą klawiatury (Tab, Shift+Tab, Enter, Spacja, klawisze strzałek). Zwróć uwagę, które elementy interaktywne są osiągalne i działają. Następnie, bez przeładowywania strony, przejdź do nawigacji dotykowej — stukaj w linki, przyciski i kontrolki formularzy. Zweryfikuj, że cała funkcjonalność dostępna za pomocą klawiatury pozostaje dostępna za pomocą dotyku i odwrotnie. Zanotuj każdy element, który staje się nieosiągalny lub nie działa po przełączeniu.
\n
4. Test łączonego wejścia ze screen readerem: Korzystając z NVDA z Firefoxem, nawiguj po stronie za pomocą klawiatury, aby aktywować tryb czytnika ekranu. Następnie użyj ekranu dotykowego (jeśli jest dostępny), aby spróbować wchodzić w interakcje z tymi samymi elementami. Potwierdź, że czytnik ekranu i strona poprawnie reagują na oba typy wejścia. Powtórz z VoiceOver w Safari na iPadzie, używając zarówno gestów dotykowych, jak i sparowanej klawiatury Bluetooth. Z JAWS w Chrome zweryfikuj, że przełączanie się między klawiaturą a myszą nie psuje zarządzania fokusem ani nie powoduje, że elementy interaktywne stają się nieaktywne.
\n
5. Przegląd kodu pod kątem wzorców blokowania modalności: Ręcznie przejrzyj wszelkie biblioteki JavaScript lub frameworki używane na stronie pod kątem wbudowanego wykrywania modalności. Niektóre biblioteki interfejsu użytkownika, szczególnie starsze frameworki mobile-first, zawierają kod, który wyłącza zdarzenia myszy lub klawiatury na urządzeniach wykrytych jako dotykowe. Sprawdź dokumentację i źródła biblioteki pod kątem takiego zachowania i upewnij się, że zostało ono nadpisane lub wyłączone.
\n
6. Ponowne testy po dynamicznych interakcjach: Wykonaj działania, które wywołują istotne zmiany w DOM — otwieranie modali, nawigację po trasach aplikacji typu single-page, wysyłanie formularzy — i po każdej takiej zmianie ponownie przeprowadź test multimodalności. Ograniczenia są czasem wprowadzane tylko w określonych stanach aplikacji.
\n

\n\n

Jak naprawić

\n

Wykrywanie dotyku w celu wyłączenia nawigacji klawiaturą — nieprawidłowe

\n

<!-- JavaScript wykrywa dotyk i usuwa wszystkie wartości tabindex,\n     psując nawigację klawiaturą dla użytkowników, którzy przełączają tryby wejścia -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Wykrywanie dotyku w celu wyłączenia nawigacji klawiaturą — prawidłowe

\n

<!-- Nie ograniczaj dostępności klawiatury na podstawie wykrycia dotyku.\n     Pozwól obu modalnościom wejścia działać równocześnie.\n     Jeśli musisz zarządzać stylami fokusu ze względów estetycznych, użyj\n     pseudoklasy CSS :focus-visible zamiast usuwania tabindex. -->\n<style>\n  /* Pokazuj obrysy fokusu tylko dla nawigacji klawiaturą, nie dla kliknięć myszy,\n     bez całkowitego usuwania dostępu klawiatury */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- Nie jest potrzebne żadne wykrywanie modalności w JavaScript -->

\n\n

Zdarzenie wskaźnika użyte do tłumienia zdarzeń klawiatury — nieprawidłowe

\n

<!-- Niestandardowy suwak, który po otrzymaniu wejścia wskaźnikiem przestaje\n     reagować na klawisze strzałek, zmuszając użytkownika do interakcji\n     wyłącznie za pomocą wskaźnika -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // klawiatura wyłączona po użyciu wskaźnika\n    if (e.key === 'ArrowRight') { /* zwiększ */ }\n    if (e.key === 'ArrowLeft') { /* zmniejsz */ }\n  });\n</script>

\n

Zdarzenie wskaźnika użyte do tłumienia zdarzeń klawiatury — prawidłowe

\n

<!-- Zarówno interakcje wskaźnikiem, jak i klawiaturą są obsługiwane niezależnie.\n     Nie jest ustawiana żadna flaga, która uniemożliwiałaby działanie jednej\n     modalności po użyciu drugiej. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Procedura obsługi wskaźnika — zawsze aktywna\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // oblicz nową wartość na podstawie położenia wskaźnika\n    }\n  });\n\n  // Procedura obsługi klawiatury — zawsze aktywna, nie wyłączana przez użycie wskaźnika\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Mobilny framework automatycznie wyłączający zdarzenia myszy — nieprawidłowe

\n\n

(Content truncated due to token limit — please retry this article.)