Kryteria sukcesu WCAG · Level A
WCAG 2.1.4: Skróty klawiszowe znaków
WCAG 2.1.4 wymaga, aby każdy skrót klawiaturowy zaimplementowany przy użyciu tylko pojedynczego klawisza znaku (litery, cyfry, znaku interpunkcyjnego lub symbolu) mógł zostać wyłączony, przypisany na nowo lub aktywowany wyłącznie po uzyskaniu fokusu — zapobiegając przypadkowemu wywołaniu, które szkodzi użytkownikom polegającym na sterowaniu głosem lub mającym niepełnosprawności ruchowe.
Co oznacza ta zasada
WCAG 2.1.4 — Skróty klawiszowe z użyciem pojedynczego znaku (Character Key Shortcuts) to kryterium sukcesu na poziomie A wprowadzone w WCAG 2.1. Dotyczy ono konkretnego, ale poważnego zagrożenia dla dostępności: sytuacji, gdy aplikacja webowa przypisuje skróty klawiaturowe składające się z pojedynczego drukowalnego znaku — litery, cyfry, znaku interpunkcyjnego lub symbolu — bez wymagania klawisza modyfikującego, takiego jak Ctrl, Alt, Meta lub Shift użytego razem z nim.
Kryterium stanowi, że jeśli w treści zaimplementowano skrót klawiaturowy używający wyłącznie pojedynczego klawisza znaku, to co najmniej jeden z poniższych warunków musi być spełniony:
- Wyłączenie: Dostępny jest mechanizm pozwalający użytkownikowi całkowicie wyłączyć skrót.
- Przypisanie na nowo: Dostępny jest mechanizm pozwalający użytkownikowi przypisać skrót tak, aby używał jednego lub więcej niedrukowalnych klawiszy modyfikujących (takich jak Ctrl lub Alt).
- Aktywny tylko przy fokusie: Skrót klawiaturowy dla komponentu interfejsu użytkownika jest aktywny tylko wtedy, gdy ten komponent ma fokus.
Skrót klawiszowy z użyciem pojedynczego znaku to skrót aktywowany przez naciśnięcie pojedynczego klawisza, który generuje drukowalny znak — na przykład naciśnięcie G, aby otworzyć galerię, naciśnięcie /, aby ustawić fokus na pasku wyszukiwania, lub naciśnięcie N, aby utworzyć nową wiadomość. Różnią się one zasadniczo od skrótów takich jak Ctrl+S czy Alt+F4, które wymagają niedrukowalnego klawisza modyfikującego i dlatego znajdują się poza zakresem tego kryterium.
Skrót spełnia to kryterium, jeśli aplikacja: (1) udostępnia stronę ustawień lub preferencji, na której skróty jednoklawiszowe można wyłączyć lub zmienić na kombinacje wieloklawiszowe; (2) automatycznie mapuje je na skróty oparte na klawiszach modyfikujących; lub (3) wywołuje skrót tylko wtedy, gdy element wyzwalający sam ma fokus klawiatury — co oznacza, że naciśnięcie klawisza, gdy fokus jest gdzie indziej, nie powoduje żadnego działania.
Skrót nie spełnia kryterium, jeśli pojedyncze naciśnięcie klawisza znaku wywołuje globalne działanie w dowolnym momencie, niezależnie od tego, który element ma fokus, i nie istnieje sposób, aby użytkownik mógł je wyłączyć lub zmienić. Powszechnym przykładem z rzeczywistości jest aplikacja jednostronicowa, która wywołuje akcję nawigacyjną za każdym razem, gdy użytkownik naciśnie klawisz litery, nawet gdy wypełnia on pole tekstowe lub dyktuje tekst.
Kryterium zawiera jeden istotny oficjalny wyjątek: nie ma zastosowania, gdy skrót jest aktywny tylko wtedy, gdy konkretny komponent ma fokus. Na przykład niestandardowy widżet rozwijanego menu, który nasłuchuje klawiszy liter tylko wtedy, gdy samo menu jest otwarte i ma fokus, jest akceptowalny, ponieważ ograniczenie do obszaru fokusu zmniejsza ryzyko przypadkowej aktywacji.
Dlaczego to ma znaczenie
Kryterium to istnieje przede wszystkim po to, aby chronić dwie grupy użytkowników, choć jego korzyści sięgają dalej.
Użytkownicy sterowania głosowego są najbardziej bezpośrednio dotknięci. Osoby z niepełnosprawnościami ruchowymi często kontrolują swoje komputery wyłącznie za pomocą oprogramowania do rozpoznawania mowy, takiego jak Dragon NaturallySpeaking (obecnie Dragon Professional). Podczas dyktowania tekstu lub wydawania poleceń głosowych narzędzia te generują naciśnięcia klawiszy, które mogą nieumyślnie wywołać jednoliterowe skróty na aktywnej stronie. Wyobraź sobie użytkownika dyktującego formularz medyczny i mówiącego „next” — jeśli aplikacja globalnie nasłuchuje litery N, może przejść do następnej strony, niszcząc pracę użytkownika. Według CDC około 61 milionów dorosłych w Stanach Zjednoczonych żyje z niepełnosprawnością, a znacząca część z nich polega na alternatywnych metodach wprowadzania, w tym na rozpoznawaniu mowy.
Użytkownicy z niepełnosprawnościami ruchowymi, którzy korzystają z przełączników, urządzeń typu sip-and-puff lub nawigacji wyłącznie klawiaturą, również są narażeni. Użytkownicy ci mogą przypadkowo naciskać klawisze lub „przetaczać się” przez wiele klawiszy, próbując trafić w cel. Pojedyncze błędne naciśnięcie, które wywoła nieodwracalne działanie — takie jak archiwizacja e-maila, usunięcie pliku czy wysłanie formularza — może powodować znaczącą frustrację i utratę danych.
Użytkownicy z niepełnosprawnościami poznawczymi również mogą ponieść szkody. Użytkownicy z zaburzeniami uwagi lub osoby, które nie znają interfejsu, mogą naciskać klawisze eksperymentalnie, aby eksplorować stronę, nie zdając sobie sprawy, że aktywne są skróty jednoliterowe. Nieoczekiwane nawigacje lub zmiany stanu zwiększają obciążenie poznawcze i dezorientację.
Rozważmy taki scenariusz z życia: turecka platforma e-commerce wdraża jednoklawiszowe skróty dla zaawansowanych użytkowników — naciśnięcie C, aby przejść do koszyka, naciśnięcie F, aby przejść do ulubionych. Użytkownik sterowania głosowego próbuje podyktować swój adres dostawy w polu formularza. Gdy mówi „Caddesi” (tureckie słowo oznaczające „ulica”), oprogramowanie rozpoznające mowę generuje literę C, zanim fokus w pełni wejdzie do pola, co wywołuje nawigację do strony koszyka. Częściowo wprowadzony adres zostaje utracony. Użytkownik musi zacząć od nowa, a jeśli sytuacja się powtarza, może całkowicie porzucić korzystanie z serwisu.
Poza dostępnością, spełnienie tego kryterium poprawia ogólną użyteczność. Udostępnienie interfejsu do dostosowywania skrótów sygnalizuje dojrzały produkt, który szanuje użytkownika. Może to również zmniejszyć liczbę zgłoszeń do działu wsparcia od sfrustrowanych użytkowników, którzy przypadkowo wywołują skróty.
Powiązane reguły Axe-core
WCAG 2.1.4 wymaga ręcznego testowania, ponieważ narzędzia automatyczne nie są w stanie wiarygodnie wykryć wszystkich jednoliterowych skrótów klawiaturowych ani sprawdzić, czy istnieje mechanizm ich ponownego przypisania/wyłączenia. Oto dlaczego automatyzacja zawodzi i na co testerzy muszą zwracać uwagę ręcznie:
- Brak dedykowanej reguły axe-core (wymagana ręczna kontrola): Axe-core i Lighthouse nie mają zautomatyzowanej reguły, która wprost oznacza skróty klawiaturowe z pojedynczym znakiem. Powód jest architektoniczny: zachowanie skrótów klawiaturowych jest implementowane w nasłuchiwaczach zdarzeń JavaScript (
keydown,keyup,keypress), a statyczna analiza DOM nie jest w stanie określić, jakie działanie wywoła dane naciśnięcie klawisza, czy działanie to jest globalne czy ograniczone do fokusu, ani czy istnieje mechanizm wyłączenia/ponownego przypisania dostępny dla użytkownika. Narzędzie musiałoby symulować naciśnięcia klawiszy dla wszystkich możliwych znaków i obserwować wynikające zmiany stanu aplikacji — to zadanie o kombinatorycznej złożoności i zależne od kontekstu, wykraczające poza obecne możliwości automatycznych testów. - Inspekcja nasłuchiwaczy zdarzeń (częściowa automatyzacja): Narzędzia deweloperskie przeglądarki mogą wyliczyć nasłuchiwacze zdarzeń dołączone do elementów
document,windowlubbody. Jeśli strona dołącza nasłuchiwaczkeydowndodocument, a inspekcja jego kodu ujawnia logikę dopasowywania pojedynczych znaków, jest to silny sygnał wymagający ręcznej weryfikacji. Jednak samo narzędzie nie jest w stanie określić, czy wynikające zachowanie stanowi skrót, ani czy istnieje mechanizm wyłączenia. - Biblioteki skrótów specyficzne dla frameworków: Wiele aplikacji React, Vue lub Angular używa bibliotek takich jak
react-hotkeys-hook,tinykeysczyMousetrap, które rejestrują globalne skróty. Ręczny audyt powinien sprawdzić obecność tych zależności w kodzie strony lub w zakładce sieci, a następnie przetestować każdy zarejestrowany skrót pod kątem wymogów kryterium.
Jak testować
- Przejrzyj aplikację pod kątem znanych skrótów z pojedynczym znakiem: Przeczytaj dostępne dokumentacje, strony pomocy lub okna dialogowe z listą skrótów klawiaturowych (często otwierane klawiszem ? lub dostępne z menu Pomoc). Wypisz wszystkie udokumentowane skróty, które używają pojedynczego znaku bez klawisza modyfikującego.
- Sprawdź nasłuchiwacze zdarzeń JavaScript: Otwórz Chrome DevTools lub Firefox DevTools, przejdź do panelu Elements lub Sources i użyj zakładki Event Listeners, aby sprawdzić nasłuchiwacze na
document,windowibody. Szukaj obsługikeydown,keyuplubkeypress. Rozwiń i przeczytaj kod obsługi, aby sprawdzić, czy testowane są pojedyncze klawisze znaków bez sprawdzania klawiszy modyfikujących (tzn. kod sprawdzaevent.key === 'n'bez równoczesnego sprawdzaniaevent.ctrlKey || event.metaKey || event.altKey). - Testuj skróty klawiaturowe, gdy fokus jest w polu tekstowym: Kliknij w pole tekstowe, pole wyszukiwania lub textarea. Następnie naciśnij każdy skrót z pojedynczym znakiem, który zidentyfikowałeś. Jeśli skrót się uruchamia (następuje nawigacja, wywoływana jest akcja, zmienia się stan), jest to błąd — skrót nie jest ograniczony do fokusu i jest aktywny nawet wtedy, gdy użytkownik pisze.
- Testuj z NVDA + Firefox: Włącz tryb przeglądania NVDA (Insert+Spacja, aby przełączać). W trybie przeglądania NVDA używa jednoliterowych klawiszy nawigacyjnych (H dla nagłówków, B dla przycisków itd.). Uruchom testowaną aplikację webową. Przełącz się w tryb fokusu (Insert+Spacja) i dyktuj lub wpisuj tekst. Upewnij się, że jednoliterowe skróty strony nie kolidują z klawiszami trybu przeglądania NVDA i że nie są wywoływane niezamierzone akcje.
- Testuj z JAWS + Chrome: Podobnie, JAWS używa jednoliterowej szybkiej nawigacji. Uruchom aplikację, nawiguj za pomocą wirtualnego kursora JAWS i upewnij się, że skróty aplikacji nie uruchamiają się niespodziewanie, gdy JAWS przetwarza naciśnięcia klawiszy.
- Testuj z VoiceOver + Safari (macOS): Włącz VoiceOver (Cmd+F5). Użyj VO+Shift+Strzałka w dół, aby wejść w interakcję z obszarami treści. Upewnij się, że skróty literowe na stronie nie kolidują z poleceniami nawigacyjnymi VoiceOver.
- Symuluj sterowanie głosowe: Jeśli dostępny jest Dragon NaturallySpeaking lub Windows Speech Recognition, dyktuj tekst w polu formularza, gdy aplikacja jest otwarta. Wypowiadaj popularne słowa i frazy zaczynające się od liter używanych jako skróty. Upewnij się, że nie są wywoływane niezamierzone akcje.
- Zweryfikuj mechanizm wyłączania lub ponownego przypisania: Jeśli istnieją skróty z pojedynczym znakiem, znajdź interfejs ustawień lub preferencji, który pozwala je wyłączyć lub przypisać na nowo. Potwierdź, że jest on dostępny wyłącznie za pomocą klawiatury i działa poprawnie. Przetestuj, że po wyłączeniu skrótu naciśnięcie danego znaku nie wywołuje już akcji.
Jak naprawić
Globalny skrót z pojedynczym znakiem bez sprawdzania klawisza modyfikującego — niepoprawne
<!-- JavaScript dołączony do document uruchamia się przy każdym naciśnięciu 'n' globalnie -->
<script>
document.addEventListener('keydown', function(event) {
if (event.key === 'n') {
// Przejdź do tworzenia nowej wiadomości
openComposeWindow();
}
});
</script>
Globalny skrót z pojedynczym znakiem — poprawne: dodaj wymaganie klawisza modyfikującego i przełącznik wyłączania
<!-- Poprawne podejście 1: Wymagaj klawisza modyfikującego (Ctrl+N), aby zapobiec przypadkowemu uruchomieniu -->
<script>
document.addEventListener('keydown', function(event) {
// Uruchamiaj tylko wtedy, gdy wciśnięty jest także Ctrl lub Meta (Cmd na Macu)
if ((event.ctrlKey || event.metaKey) && event.key === 'n') {
openComposeWindow();
}
});
</script>
<!-- Poprawne podejście 2: Jeśli skrót jednoliterowy jest wymagany, zapewnij przełącznik wyłączania -->
<button type='button' id='toggle-shortcuts' aria-pressed='true'>
Keyboard shortcuts enabled
</button>
<script>
let shortcutsEnabled = true;
document.getElementById('toggle-shortcuts').addEventListener('click', function() {
shortcutsEnabled = !shortcutsEnabled;
this.setAttribute('aria-pressed', shortcutsEnabled.toString());
this.textContent = shortcutsEnabled ? 'Keyboard shortcuts enabled' : 'Keyboard shortcuts disabled';
});
document.addEventListener('keydown', function(event) {
if (!shortcutsEnabled) return; // Uszanuj preferencje użytkownika
if (event.key === 'n') {
openComposeWindow();
}
});
</script>
Skrót aktywny wewnątrz widżetu z fokusem — niepoprawne
<!-- Skrót nasłuchuje na całym dokumencie, a nie jest ograniczony do widżetu -->
<div id='autocomplete-list' role='listbox'>
<div role='option'>Istanbul</div>
<div role='option'>Ankara</div>
</div>
<script>
// BŁĄD: dołączony do document, uruchamia się nawet, gdy autocomplete nie ma fokusu
document.addEventListener('keydown', function(e) {
if (e.key === 'Enter') selectHighlightedOption();
});
</script>
Skrót aktywny wewnątrz widżetu z fokusem — poprawne: ogranicz nasłuchiwacz do widżetu
<!-- Poprawne: nasłuchiwacz jest na elemencie widżetu; skrót uruchamia się tylko, gdy ma on fokus -->
<div id='autocomplete-list' role='listbox' tabindex='0'>
<div role='option'>Istanbul</div>
<div role='option'>Ankara</div>
</div>
<script>
var widget = document.getElementById('autocomplete-list');
// Nasłuchiwacz na samym widżecie: Enter uruchamia się tylko, gdy listbox ma fokus
widget.addEventListener('keydown', function(e) {
if (e.key === 'Enter') selectHighlightedOption();
});
</script>
Brak interfejsu do ponownego przypisania dostępnego dla użytkownika — niepoprawne
<!-- Aplikacja rejestruje skróty za pomocą biblioteki, ale nie oferuje strony ustawień -->
<!-- Użytkownik nie ma możliwości zmiany lub wyłączenia 'g' (przejdź do galerii) ani 'c' (przejdź do koszyka) -->
<script src='hotkeys.min.js'></script>
<script>
hotkeys('g', function() { goToGallery(); });
hotkeys('c', function() { goToCart(); });
</script>
Brak interfejsu do ponownego przypisania dostępnego dla użytkownika — poprawne: dodaj dostępny panel ustawień
<!-- Panel ustawień dostępny z klawiatury; pozwala użytkownikowi przełączać wszystkie skróty jednoliterowe -->
<nav aria-label='Accessibility settings'>
<button type='button' id='open-shortcut-settings'>Keyboard shortcut settings</button>
</nav>
<dialog id='shortcut-settings-dialog' aria-labelledby='dialog-title'>
<h2 id='dialog-title'>Keyboard Shortcuts</h2>
<label>
<input type='checkbox' id='enable-single-char' checked />
Enable single-character keyboard shortcuts (G, C, N...)
</label>
<p>Disable this if you use speech recognition software or experience accidental activations.</p>
<button type='button' id='close-dialog'>Save and close</button>
</dialog>
<script src='hotkeys.min.js'></script>
<script>
var checkbox = document.getElementById('enable-single-char');
function applyShortcuts() {
if (checkbox.checked) {
hotkeys('g', function() { goToGallery(); });
hotkeys('c', function() { goToCart(); });
} else {
hotkeys.unbind('g');
hotkeys.unbind('c');
}
}
applyShortcuts();
checkbox.addEventListener('change', applyShortcuts);
document.getElementById('open-shortcut-settings').addEventListener('click', function() {
document.getElementById('shortcut-settings-dialog').showModal();
});
document.getElementById('close-dialog').addEventListener('click', function() {
document.getElementById('shortcut-settings-dialog').close();
});
</script>
Typowe błędy
- Rejestrowanie skrótów na
documentlubwindowbez sprawdzania, czy aktualnie fokus ma element wejściowy: Nawet jeśli istnieje mechanizm wyłączania, wiele implementacji zapomina sprawdzićdocument.activeElementi wyłączyć skrót, gdy użytkownik znajduje się w elemencie<input>,<textarea>lubcontenteditable, co prowadzi do zakłócania normalnego pisania. - Traktowanie skrótu
?(otwarcie pomocy) jako zwolnionego z wymogu: Znak zapytania jest znakiem drukowalnym i skrótem z pojedynczym znakiem. Nie jest zwolniony z tego kryterium, chyba że jest ograniczony do fokusu lub istnieje mechanizm wyłączenia/ponownego przypisania. - Wyłączanie skrótów tylko w polach tekstowych, ale nie w regionach
contenteditablelub edytorach tekstu sformatowanego: Użytkownicy sterowania głosowego często dyktują do elementówcontenteditableużywanych przez edytory tekstu sformatowanego (takie jak w platformach CMS). Niewyłączanie globalnych skrótów w tych kontekstach nadal narusza kryterium. - Przechowywanie preferencji użytkownika dotyczącej skrótów wyłącznie w pamięci sesji: Jeśli użytkownik wyłączy skróty, a następnie odświeży stronę, preferencja powinna zostać zachowana (w
localStoragelub ustawieniu profilu użytkownika), aby nie musiał wyłączać skrótów przy każdej wizycie. - Uczynienie samego interfejsu ustawień skrótów niedostępnym: Umieszczenie opcji wyłączenia/ponownego przypisania głęboko w menu, do którego nie można dotrzeć klawiaturą, lub użycie niestandardowego widżetu przełącznika bez odpowiedniego
role='switch'iaria-checkedoznacza, że mechanizm naprawczy jest nieużywalny dla użytkowników, którym ma pomagać. - Zakładanie, że liczą się tylko klawisze liter: Klawisze cyfr (1–9), klawisze interpunkcyjne (/, ., przecinek, średnik) oraz klawisze symboli (#, @, !) są wszystkimi znakami drukowalnymi. Skróty jednoklawiszowe używające tych znaków w równym stopniu podlegają kryterium.
- Brak dokumentowania, jakie skróty istnieją: Nawet jeśli istnieje mechanizm wyłączania, użytkownicy nie mogą skutecznie z niego korzystać, jeśli nie wiedzą, jakie skróty są aktywne. Zdecydowanie zaleca się udostępnienie widocznego, dostępnego z klawiatury odniesienia do skrótów (np. okna dialogowego otwieranego przyciskiem Pomoc).
- Używanie domyślnej konfiguracji biblioteki skrótów, która wiąże globalnie, bez czytania jej dokumentacji: Biblioteki takie jak Mousetrap, Hotkeys.js i tinykeys domyślnie wiążą skróty w globalnym zakresie. Deweloperzy często używają ich bez czytania dokumentacji dotyczącej ograniczania zakresu lub wymagań klawiszy modyfikujących, nieumyślnie tworząc naruszenia kryterium na dużą skalę.
- Brak testów z użyciem rozpoznawania mowy przed wdrożeniem: Zespoły, które nie mają Dragon NaturallySpeaking w swoim zestawie narzędzi QA, często odkrywają konflikty skrótów jednoliterowych dopiero po wdrożeniu, gdy użytkownicy sterowania głosowego zgłaszają problemy.
- Przekonanie, że ponieważ skrót jest „opcjonalny” lub „dla zaawansowanych użytkowników”, jest zwolniony z wymogu: Kryterium dotyczy wszystkich skrótów z pojedynczym znakiem, niezależnie od tego, czy są one reklamowane jako funkcje zaawansowane. Opcjonalność funkcji nie zwalnia jej z wymogu zgodności.
Związek z tureckimi regulacjami dotyczącymi dostępności
Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności stron internetowych i aplikacji mobilnych, zgodne z WCAG 2.2. WCAG 2.1.4 — Skróty klawiszowe z użyciem pojedynczego znaku (Character Key Shortcuts) to kryterium sukcesu na poziomie A, co stawia je w najwyższej kategorii priorytetów zobowiązań wynikających z okrężnicy.
Okrężnica obejmuje szeroki zakres podmiotów działających w Turcji. Instytucje publiczne — w tym ministerstwa, gminy, uniwersytety państwowe, szpitale publiczne i agencje rządowe — muszą osiągnąć pełną zgodność z poziomem A w ciągu jednego roku od daty publikacji okrężnicy. Podmioty sektora prywatnego w objętych kategoriach otrzymują dwuletnie okno na zapewnienie zgodności. Do objętych podmiotów prywatnych należą platformy e-commerce, banki i instytucje finansowe, szpitale i świadczeniodawcy opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne działające na podstawie upoważnienia Ministerstwa Edukacji Narodowej (MoNE).
Dla tych organizacji niespełnienie wymogów WCAG 2.1.4 nie jest jedynie kwestią dobrych praktyk — jest to obowiązek prawny. Turecka strona e-commerce, która implementuje jednoliterowe skróty przeglądania produktów bez mechanizmu ich wyłączenia, lub portal bankowości internetowej tureckiego banku, który używa skrótów literowych w przebiegu transakcji, byłby w bezpośrednim naruszeniu wymogów okrężnicy.
W praktyce zespoły ds. zgodności w objętych podmiotach powinny przeprowadzić audyt swoich baz kodu JavaScript oraz wszelkich bibliotek widżetów stron trzecich pod kątem globalnie zarejestrowanych skrótów z pojedynczym znakiem jako odrębne zadanie w ramach projektów naprawczych WCAG 2.2 na poziomie A. Ponieważ to kryterium wymaga testów ręcznych, same automatyczne skany dostępności nie ujawnią naruszeń — konieczne jest dedykowane testowanie z użyciem klawiatury i sterowania głosowego. Organizacje korzystające z systemów zarządzania treścią lub frameworków front-endowych powinny przejrzeć implementacje skrótów na poziomie platformy (na przykład domyślne skróty klawiaturowe panelu administracyjnego CMS ujawnione na stronach skierowanych do klientów) oprócz własnego kodu aplikacji.
SDK nakładki Accsible pomaga objętym podmiotom, udostępniając panel preferencji dostępności dostępny dla użytkownika, który może wystawić przełącznik wyłączania skrótów dla użytkowników końcowych, pomagając organizacjom spełnić wymóg WCAG 2.1.4 dotyczący „mechanizmu wyłączenia” bez konieczności pełnej refaktoryzacji bazy kodu. Jest to szczególnie cenne dla organizacji zarządzających aplikacjami typu legacy, w których modyfikacja podstawowej logiki skrótów JavaScript jest zasobochłonna. Organizacje powinny jednak zauważyć, że poleganie wyłącznie na nakładce w celu zapewnienia zgodności nie zastępuje konieczności zajęcia się podstawowymi implementacjami skrótów, a podejście warstwowe, łączące narzędzia nakładkowe z naprawą kodu źródłowego, zapewnia najbardziej solidną drogę do zgodności z okrężnicą prezydencką.
Źródła i odniesienia
- W3C Understanding 2.1.4 Character Key Shortcuts
- W3C Techniques for 2.1.4
- WebAIM: Keyboard Accessibility
- Deque University: WCAG 2.1.4 Character Key Shortcuts
- MDN: KeyboardEvent.key
- MDN: EventTarget.addEventListener
- W3C Technique G217: Providing a mechanism to allow users to remap or turn off character key shortcuts
