WCAG 2.4.3: Kolejność fokusu

Co Oznacza Ta Zasada

WCAG 2.4.3 Focus Order to kryterium sukcesu na poziomie A w ramach zasady Operable. Stanowi ono: „Jeśli stronę internetową można przeglądać sekwencyjnie, a sekwencje nawigacji wpływają na znaczenie lub działanie, elementy fokusowalne otrzymują fokus w kolejności, która zachowuje znaczenie i możliwość obsługi.”

W praktyce oznacza to, że gdy użytkownik naciska klawisz Tab, aby przechodzić przez interaktywne elementy na stronie — linki, przyciski, pola formularzy, niestandardowe widżety i inne elementy fokusowalne — kolejność, w jakiej te elementy otrzymują fokus, musi mieć logiczny sens. Użytkownicy nie powinni niespodziewanie przeskakiwać z środka formularza do linku w stopce, potem z powrotem do przycisku w modalu, a następnie do elementu menu nawigacyjnego.

Kryterium dotyczy sekwencyjnej nawigacji klawiaturą, która jest podstawowym sposobem poruszania się po stronie dla użytkowników korzystających wyłącznie z klawiatury oraz użytkowników czytników ekranu. Kolejność elementów w DOM jest domyślnym źródłem kolejności fokusu w przeglądarkach: elementy pojawiają się w sekwencji tabulacji w takiej kolejności, w jakiej występują w Document Object Model (DOM), chyba że CSS lub JavaScript celowo tę kolejność zmieniają. Problemy pojawiają się, gdy układ wizualny odbiega od kolejności w DOM (na przykład poprzez zmianę kolejności w CSS Flexbox lub Grid), albo gdy wartości tabindex narzucają nienaturalną sekwencję.

Co jest uznawane za spełnienie: Kolejność fokusu musi być logiczna i znacząca — niekoniecznie identyczna z wizualną kolejnością czytania, ale na tyle spójna, by użytkownicy mogli zrozumieć i obsługiwać stronę. Modalne okno dialogowe, które po otwarciu przenosi fokus na siebie, utrzymuje fokus wewnątrz siebie, dopóki jest otwarte, a po zamknięciu przywraca fokus do elementu wywołującego, spełnia to kryterium. Wieloetapowy formularz, w którym Tab przechodzi przez każde pole w kolejności, w jakiej użytkownik by je wypełniał (z góry na dół, z lewej na prawą w językach pisanych od lewej do prawej), również spełnia wymagania.

Co jest uznawane za niespełnienie: Fokus przeskakujący z pola „Username” formularza logowania do zupełnie niezwiązanego banera promocyjnego, zanim dotrze do pola „Password”, jest błędem. Aplikacja jednostronicowa, która otwiera okno dialogowe, ale pozostawia fokus na stronie w tle, jest błędem. Używanie dodatnich wartości tabindex (np. tabindex='2', tabindex='5'), które wymuszają nielogiczną sekwencję tabulacji na stronie, również jest błędem.

Oficjalne wyjątki: WCAG wyraźnie zaznacza, że kolejność fokusu nie musi odpowiadać wizualnej kolejności czytania, o ile zachowuje znaczenie i możliwość obsługi. Dopuszcza się także przypadki, w których sekwencje nawigacji nie wpływają na znaczenie ani działanie — na przykład strona z tylko jednym elementem fokusowalnym nie ma sekwencji do oceny. Dodatkowo, gdy istnieje wiele poprawnych kolejności, które wszystkie zachowują znaczenie, każda z tych kolejności jest akceptowalna.

Kluczowe mechanizmy HTML i JavaScript wpływające na kolejność fokusu obejmują: naturalną kolejność elementów interaktywnych w DOM, atrybut tabindex (szczególnie dodatnie wartości całkowite), właściwości CSS zmieniające układ wizualny bez zmiany DOM (takie jak order w Flexbox/Grid, position: absolute i float), zarządzanie fokusem sterowane przez JavaScript (wywoływanie .focus() na elementach) oraz wzorce dialogów ARIA wymagające jawnego zarządzania fokusem.

Dlaczego To Ma Znaczenie

Kolejność fokusu nie jest drobnym szczegółem technicznym — to kręgosłup nawigacji w sieci dla istotnej części użytkowników. Kilka odrębnych grup osób z niepełnosprawnościami polega na logicznej sekwencji fokusu, aby skutecznie korzystać z produktów cyfrowych.

Użytkownicy z niepełnosprawnością ruchową, którzy nie mogą używać myszy, polegają wyłącznie na klawiaturze (lub urządzeniach równoważnych klawiaturze, takich jak przełączniki sip-and-puff, wskaźniki głowowe czy systemy śledzenia wzroku) do nawigacji. Dla tych użytkowników chaotyczna kolejność fokusu nie jest tylko niedogodnością — może uczynić stronę całkowicie nieużyteczną. Jeśli klawisz Tab przenosi użytkownika w niewłaściwe miejsce na stronie, może on nie mieć efektywnego sposobu dotarcia do potrzebnego kontrolki i nie może po prostu przesunąć ręki, aby kliknąć gdzie indziej.

Osoby niewidome i słabowidzące, które używają czytników ekranu, takich jak NVDA, JAWS czy VoiceOver, słyszą zapowiedzi elementów w momencie, gdy fokus na nie trafia. Logiczna kolejność fokusu oznacza, że strumień audio, który otrzymują, odzwierciedla zamierzony przepływ interfejsu. Gdy fokus przeskakuje w sposób nieprzewidywalny, użytkownicy tracą mentalny model tego, gdzie znajdują się na stronie. Według Światowej Organizacji Zdrowia około 2,2 miliarda osób na świecie ma jakąś formę upośledzenia wzroku, a dla wielu z tych, którzy używają czytników ekranu, kolejność fokusu jest głównym sposobem doświadczania struktury strony.

Użytkownicy z niepełnosprawnościami poznawczymi również korzystają z przewidywalnych sekwencji fokusu. Niespodziewany skok fokusu w środku formularza może powodować dezorientację, zmuszać użytkowników do ponownego rozpoczynania procesów lub sprawiać, że przeoczą wymagane pola. Użytkownicy z trudnościami z koncentracją lub pamięcią krótkotrwałą potrzebują spójnej, przewidywalnej nawigacji, aby zbudować zaufanie do korzystania z witryny.

Konkretny scenariusz z życia wzięty: Wyobraź sobie turecką stronę e-commerce z procesem realizacji zamówienia. Projekt wizualny używa CSS Grid, aby umieścić podsumowanie zamówienia po lewej, a formularz płatności po prawej. Jednak w DOM formularz płatności znajduje się jako pierwszy, a podsumowanie zamówienia jako drugie. Układ wizualny wygląda poprawnie dla widzących użytkowników myszy, ale użytkownik klawiatury naciskający Tab trafi najpierw w pola formularza płatności, zanim będzie miał szansę przejrzeć podsumowanie zamówienia. Może nieświadomie potwierdzić błędne zamówienie. Co gorsza, jeśli przycisk „Confirm Purchase” otrzyma fokus przed polem „Apply Coupon” z powodu niewłaściwego zarządzania dodatnimi wartościami tabindex, użytkownik może przypadkowo złożyć zamówienie, które zamierzał objąć rabatem. To bezpośrednia, realna konsekwencja finansowa zepsutej kolejności fokusu.

Poza dostępnością, logiczna kolejność fokusu poprawia doświadczenie zaawansowanych użytkowników, którzy preferują nawigację klawiaturą ze względu na szybkość. Pośrednio wspiera także SEO: dobrze ustrukturyzowany DOM, który generuje naturalną kolejność fokusu, zwykle odzwierciedla znaczące semantyczne oznaczenie, którego wyszukiwarki używają do zrozumienia hierarchii treści i ich ważności.

Powiązane Zasady Axe-core

WCAG 2.4.3 wymaga ręcznego testowania dla ostatecznej oceny. Narzędzia automatyczne, takie jak axe-core, nie są w stanie algorytmicznie określić, czy dana sekwencja fokusu „zachowuje znaczenie i możliwość obsługi” — ten osąd wymaga człowieka, który rozumie cel strony i relacje między treściami. Jednak axe-core i powiązane narzędzia mogą wskazywać pewne wzorce, które są silnymi sygnałami problemów z kolejnością fokusu:

• tabindex (wartości dodatnie) — heurystyczna flaga: Niektóre narzędzia lintujące i audytowe ostrzegają, gdy elementy mają dodatnie wartości całkowite tabindex (dowolna wartość większa niż 0). Dodatnie wartości tabindex nadpisują naturalną kolejność DOM i umieszczają te elementy na początku sekwencji tabulacji, co prawie zawsze tworzy nielogiczną i nieprzewidywalną kolejność fokusu. Chociaż podstawowy zestaw reguł axe-core nie zawiera dedykowanej automatycznej reguły „focus-order” (ponieważ logicznej poprawności sekwencji nie da się obliczyć), narzędzia takie jak axe DevTools Pro oraz audyty ręczne w szczególności sprawdzają użycie dodatniego tabindex jako wskaźnika pośredniego.
• scrollable-region-focusable: Axe-core zawiera regułę, która oznacza przewijalne regiony, które nie są fokusowalne z klawiatury. Choć nie jest to bezpośrednio reguła dotycząca kolejności fokusu, przewijalny region, który nie może otrzymać fokusu, zaburza ogólną sekwencję nawigacji, powodując, że użytkownicy klawiatury pomijają treści, z którymi muszą wchodzić w interakcję.
• Ręczna inspekcja treści przestawionej przez CSS: Narzędzia automatyczne nie są w stanie wykryć, kiedy użycie order w CSS Flexbox lub rozmieszczenie w Grid powoduje rozbieżność między kolejnością wizualną a kolejnością w DOM. Tester ludzki musi wizualnie porównać układ na ekranie z sekwencją fokusu obserwowaną podczas nawigacji klawiaturą. Jest to najczęstsze źródło błędów 2.4.3 we współczesnych responsywnych projektach i jest całkowicie niewidoczne dla skanerów automatycznych.
• Ręczna inspekcja zarządzania fokusem w dynamicznych treściach przez JavaScript: Aplikacje jednostronicowe, implementacje nieskończonego przewijania, modale i wysuwane menu wymagają JavaScriptu do odpowiedniego przenoszenia fokusu w miarę zmiany treści. Narzędzia automatyczne uruchamiają statyczny zrzut DOM i nie mogą symulować sekwencji interakcji użytkownika potrzebnych do wywołania tych scenariuszy zarządzania fokusem. Tylko ręczne testowanie klawiaturą może zweryfikować, że fokus przechodzi do nowo otwartego modalu, wraca do właściwego wyzwalacza po zamknięciu i nie pozostawia użytkownika uwięzionego w niedostępnej warstwie tła.

Jak Testować

1. Automatyczne skanowanie jako punkt wyjścia: Uruchom axe DevTools (rozszerzenie przeglądarki) lub Google Lighthouse na stronie. Poszukaj ostrzeżeń dotyczących dodatnich wartości tabindex oraz oznaczonych przewijalnych regionów. Zwróć uwagę, że czysty wynik automatyczny nie oznacza spełnienia 2.4.3 — testy ręczne są zawsze wymagane. Zanotuj wszystkie zgłoszone problemy do dalszego zbadania.
2. Odłącz mysz i nawiguj wyłącznie klawiszem Tab: Zaczynając od paska adresu przeglądarki lub od góry strony, wielokrotnie naciskaj Tab, aby przejść przez każdy element fokusowalny. Uważnie obserwuj sekwencję. Zadaj sobie pytania: czy fokus przemieszcza się w kolejności odpowiadającej logicznemu przepływowi czytania i interakcji na stronie? Czy fokus kiedykolwiek przeskakuje w nieoczekiwane miejsce? Czy kiedykolwiek zostaje uwięziony (brak możliwości przejścia dalej lub wstecz) poza zamierzonym dialogiem?
3. Przetestuj komponenty dynamiczne: Aktywuj klawiaturą wszystkie modale, okna dialogowe, rozwijane menu, akordeony, panele kart, selektory dat i inne interaktywne widżety. Zweryfikuj, że fokus natychmiast po aktywacji przechodzi do nowo ujawnionej treści. Po zamknięciu dialogu potwierdź, że fokus wraca do elementu, który wywołał dialog — a nie na górę strony czy w losowe miejsce.
4. Testuj z NVDA + Firefox: Uruchom NVDA, otwórz Firefox i przejdź do strony. Używaj Tab, aby przechodzić przez elementy interaktywne i słuchaj zapowiedzi. Zweryfikuj, że zapowiadana sekwencja ma sens kontekstowy. Użyj trybu przeglądania NVDA (klawisze strzałek), aby czytać treści statyczne i potwierdzić, że kolejność czytania jest zgodna z kolejnością fokusu dla elementów interaktywnych w obrębie tej treści.
5. Testuj z VoiceOver + Safari (macOS/iOS): Włącz VoiceOver i używaj Tab (na komputerze) lub gestów przesunięcia (iOS), aby przechodzić przez elementy fokusowalne. Potwierdź, że sekwencja fokusu jest logiczna. Na iOS przetestuj, czy modale i nakładki prawidłowo „uwięziają” fokus i przywracają go po zamknięciu.
6. Testuj z JAWS + Chrome: Użyj nawigacji Tab w JAWS i potwierdź, że zapowiadana sekwencja fokusu jest spójna. Użyj wirtualnego kursora JAWS, aby porównać kolejność czytania z interaktywną kolejnością fokusu i zidentyfikować wszelkie rozbieżności.
7. Porównaj DOM z układem wizualnym: Otwórz DevTools przeglądarki i zbadaj strukturę DOM. Porównaj kolejność elementów interaktywnych w DOM z ich pozycją wizualną na ekranie. Jeśli właściwości CSS, takie jak order, position: absolute lub float, powodują istotne różnice, ręcznie prześledź sekwencję tabulacji, aby ustalić, czy znaczenie lub możliwość obsługi są naruszone.
8. Sprawdź wartości tabindex w DOM: W konsoli przeglądarki uruchom document.querySelectorAll('[tabindex]'), aby wyświetlić wszystkie elementy z jawnymi atrybutami tabindex. Zbadaj każdy element z dodatnią wartością całkowitą i oceń, czy jego pozycja w zmodyfikowanej kolejności tabulacji jest logiczna.

Jak Naprawić

Dodatnie wartości tabindex tworzące nielogiczną kolejność — Niepoprawne

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

Dodatnie wartości tabindex tworzące nielogiczną kolejność — Poprawne

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

Wizualne przestawianie CSS niezgodne z kolejnością DOM — Niepoprawne

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

Wizualne przestawianie CSS niezgodne z kolejnością DOM — Poprawne

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

Modalne okno dialogowe bez zarządzania fokusem — Niepoprawne

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

Modalne okno dialogowe z prawidłowym zarządzaniem fokusem — Poprawne

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

Typowe Błędy

• Używanie dodatnich wartości całkowitych tabindex (np. tabindex='1', tabindex='5') do „kontrolowania” kolejności fokusu zamiast poprawienia struktury DOM. Dodatnie wartości tabindex umieszczają elementy przed wszystkimi naturalnie fokusowalnymi elementami na stronie, tworząc chaotyczną globalną sekwencję tabulacji, którą niezwykle trudno utrzymać i która prawie zawsze wprowadza błędy.
• Stosowanie order w Flexbox lub CSS Grid do wizualnego przestawiania treści bez zmiany kolejności w DOM, a następnie brak testów nawigacji klawiaturą. Układ wizualny wygląda poprawnie dla widzących użytkowników, ale sekwencja tabulacji podąża za kolejnością DOM, a nie kolejnością wizualną — to niewidoczna, lecz poważna rozbieżność dla użytkowników klawiatury.
• Otwieranie modala lub okna dialogowego bez programowego przeniesienia fokusu do jego wnętrza za pomocą metody .focus() w JavaScript. Użytkownicy czytników ekranu i klawiatury pozostają uwięzieni w treści tła, często nie mogąc w ogóle znaleźć lub obsłużyć dialogu.
• Brak przywrócenia fokusu do elementu wywołującego po zamknięciu modala, szuflady lub rozwijanego menu. Przywracanie fokusu na górę strony lub pozostawianie go na teraz ukrytym elemencie zmusza użytkowników do ponownej nawigacji od początku, co powoduje utratę miejsca w potencjalnie długiej stronie.
• Wstawianie dynamicznie ładowanej treści (np. komunikatu o błędzie inline, powiadomienia typu toast lub sekcji ładowanej leniwie) do DOM po elementach fokusowalnych, które ją poprzedzają wizualnie, przez co użytkownicy klawiatury napotykają nową treść poza kolejnością lub wcale.
• Używanie tabindex='-1' do usuwania elementów z sekwencji tabulacji bez zapewnienia alternatywnego sposobu dostępu z klawiatury. Choć samo tabindex='-1' jest poprawnym narzędziem (sprawia, że element jest programowo fokusowalny, ale usuwa go z naturalnej kolejności tabulacji), niewłaściwe stosowanie go do kontrolek, do których użytkownicy naprawdę muszą mieć dostęp, w praktyce ukrywa te kontrolki przed użytkownikami klawiatury.
• Budowanie przejść tras w aplikacjach jednostronicowych, które resetują fokus do elementu body dokumentu lub interfejsu przeglądarki zamiast przenosić fokus do nagłówka nowej strony lub punktu „skip navigation”. Użytkownicy są wtedy zmuszeni do przechodzenia Tabem przez całą nawigację przy każdej zmianie trasy.
• Implementowanie niestandardowych karuzel lub suwaków, w których nie zaimplementowano nawigacji klawiszami strzałek, a Tab przenosi fokus przez każdy ukryty slajd, zmuszając użytkowników do przechodzenia Tabem przez dziesiątki elementów poza ekranem, zanim dotrą do dalszej treści strony.
• Umieszczanie „niewidocznego” linku pomijającego nawigację w DOM, który zawsze ma display:none (zamiast być wizualnie ukrytym techniką .sr-only / clip). Link z display:none jest całkowicie usunięty z kolejności tabulacji i nie daje żadnej korzyści, podczas gdy prawidłowo zaimplementowany link pomijający otrzymuje fokus po naciśnięciu Tab i staje się widoczny, bezpośrednio wspierając logiczny przepływ fokusu do głównej treści.
• Zagnieżdżanie elementów interaktywnych wewnątrz innych elementów interaktywnych (na przykład <button> wewnątrz znacznika <a>), co powoduje niespójne zachowanie tabulacji między przeglądarkami i może sprawić, że fokus trafi na tę samą logiczną kontrolkę wielokrotnie lub pominie ją całkowicie.

Związek z Przepisami Dostępności w Turcji

WCAG 2.4.3 Focus Order ma bezpośrednie znaczenie dla przełomowego tureckiego ustawodawstwa dotyczącego dostępności: Okólnika Prezydenckiego 2025/10, opublikowanego w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r. Okólnik ten ustanawia obowiązkowe standardy dostępności stron internetowych dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji, wymagając zgodności z międzynarodowo uznanymi wytycznymi — w tym wszystkimi kryteriami sukcesu WCAG 2.x na poziomie A, do których należy 2.4.3.

Okólnik obejmuje szeroki zakres typów podmiotów. Instytucje publiczne — w tym ministerstwa, gminy, uniwersytety państwowe i agencje rządowe — muszą osiągnąć pełną zgodność w ciągu jednego roku od daty publikacji okólnika. Podmioty sektora prywatnego w objętych kategoriach muszą osiągnąć ten sam poziom zgodności w ciągu dwóch lat. Objęte kategorie sektora prywatnego obejmują platformy e-commerce, banki i instytucje finansowe, szpitale i prywatnych świadczeniodawców 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 wszystkich tych organizacji zepsuta lub nielogiczna kolejność fokusu nie jest jedynie mankamentem użyteczności — stanowi niezgodność regulacyjną, która może narazić podmiot na konsekwencje prawne i administracyjne na mocy przepisów egzekucyjnych okólnika. Rozważ portal bankowości internetowej tureckiego banku, w którym kolejność fokusu na ekranie przelewu środków przeskakuje z pola kwoty do przycisku potwierdzenia, omijając pole IBAN beneficjenta. Użytkownik korzystający wyłącznie z klawiatury — być może klient z niepełnosprawnością ruchową — mógłby nieumyślnie zainicjować przelew bez prawidłowego wypełnienia wszystkich wymaganych pól. Taki scenariusz jednocześnie stanowi błąd WCAG 2.4.3, naruszenie wymogów okólnika oraz potencjalnie poważną szkodę finansową dla użytkownika.

Podobnie, strona e-commerce objęta okólnikiem, która używa przestawiania CSS Grid do wyświetlania atrakcyjnej wizualnie strony produktu, ale której sekwencja tabulacji przeskakuje z obrazów produktu do linków w stopce, zanim dotrze do przycisku „Add to Cart”, byłaby w bezpośrednim naruszeniu 2.4.3, a zatem niezgodna z okólnikiem. Terminy jednego i dwóch lat oznaczają, że organizacje powinny traktować naprawę kolejności fokusu jako priorytet w swoich planach dostępności — a nie odłożone ulepszenie. Biorąc pod uwagę, że problemy z kolejnością fokusu często wynikają z decyzji architektonicznych dotyczących struktury DOM i wzorców interakcji JavaScript, zajęcie się nimi na wczesnym etapie procesu tworzenia jest znacznie mniej kosztowne niż ich poprawianie po wdrożeniu.

SDK nakładki Accsible wspiera organizacje w drodze do zgodności, zapewniając konfigurowalne ulepszenia zarządzania fokusem, ale ważne jest, aby pamiętać, że rozwiązania nakładkowe najlepiej działają obok — a nie zamiast — poprawnej semantycznej struktury HTML i odpowiedzialnego zarządzania fokusem w samym kodzie aplikacji. Osiągnięcie trwałej, możliwej do audytowania zgodności z Okólnikiem Prezydenckim 2025/10 wymaga, aby podstawowy produkt spełniał 2.4.3 poprzez właściwe praktyki deweloperskie.