WCAG 2.2.5: Ponowne uwierzytelnianie

Co Oznacza Ta Zasada

WCAG 2.2.5 Re-authenticating należy do Wytycznej 2.2 (Wystarczająca ilość czasu) i jest wymaganiem na poziomie AAA. Kryterium stanowi: „Gdy uwierzytelniona sesja wygasa, użytkownik może kontynuować aktywność bez utraty danych po ponownym uwierzytelnieniu.” W praktyce oznacza to, że jeśli użytkownik jest w trakcie wypełniania formularza, finalizowania zakupu, tworzenia wiadomości lub wykonywania jakiegokolwiek zadania wieloetapowego na uwierzytelnionej platformie i jego sesja wygaśnie, musi mieć możliwość ponownego zalogowania się i kontynuowania dokładnie od miejsca, w którym przerwał — z zachowaniem wszystkich wcześniej wprowadzonych danych.

To kryterium jest ściśle powiązane z WCAG 2.2.1 (Timing Adjustable, poziom A) oraz 2.2.4 (Interruptions, poziom AAA), ale dotyczy konkretnego scenariusza: momentu przekroczenia granicy sesji. Podczas gdy 2.2.1 wymaga zapewnienia użytkownikom wystarczającej ilości czasu lub możliwości przedłużenia sesji, 2.2.5 zajmuje się przypadkiem niepowodzenia — tym, co dzieje się po upływie czasu. Oba kryteria współdziałają: idealnie należy zarówno wydłużyć sesję, jak i zachować dane, jeśli mimo to wygaśnie.

Spełnienie tego kryterium wymaga, aby platforma zachowywała wszystkie dane wprowadzone przez użytkownika — pola tekstowe, wybrane opcje, załączone pliki, pola wyboru (checkboxy), przyciski opcji (radio) oraz wszelki inny stan formularza — w trakcie zdarzenia ponownego uwierzytelnienia. Po ponownym zalogowaniu użytkownik musi zostać przywrócony do tego samego miejsca w wykonywanej aktywności, z nienaruszonymi danymi i możliwością ukończenia zadania bez powtarzania kroków.

Niespełnienie ma miejsce, gdy limit czasu sesji powoduje którykolwiek z następujących efektów: użytkownik zostaje przekierowany na stronę logowania, a po pomyślnym zalogowaniu trafia na stronę główną zamiast na stronę, na której był; dane formularza wprowadzone przed wygaśnięciem sesji zostają utracone i użytkownik musi wprowadzić wszystko ponownie; stan częściowo ukończonego kreatora wieloetapowego zostaje zresetowany; lub użytkownik zostaje po prostu wylogowany bez mechanizmu ponownego uwierzytelnienia i wznowienia pracy.

Oficjalna specyfikacja WCAG nie definiuje minimalnego czasu trwania sesji dla tego kryterium — ma ono zastosowanie niezależnie od tego, jak długi lub krótki jest okres bezczynności. Należy jednak zauważyć, że nie przewidziano żadnego wyjątku dla utraty danych z powodu obaw związanych z bezpieczeństwem; oczekuje się, że implementacje znajdą bezpieczne sposoby zachowania stanu, takie jak przechowywanie sesji po stronie serwera powiązane z tożsamością użytkownika lub szyfrowane tokeny po stronie klienta, które przetrwają przepływ ponownego uwierzytelnienia.

Dlaczego To Jest Ważne

Limity czasu sesji, które powodują utratę danych, tworzą nieproporcjonalnie duże obciążenie dla osób z niepełnosprawnościami. Wiele osób z niepełnosprawnościami potrzebuje znacznie więcej czasu na wykonanie zadań cyfrowych niż ich rówieśnicy bez niepełnosprawności i często nie mogą po prostu „pisać szybciej” ani „obejść” arbitralnego limitu czasu.

Użytkownicy, którzy są niewidomi lub słabowidzący, nawigują po formularzach za pomocą czytników ekranu, co z natury jest wolniejsze niż skanowanie wzrokiem. Niewidomy użytkownik wypełniający długi formularz zgłoszenia szkody ubezpieczeniowej może spędzić 20 lub 30 minut, ostrożnie przechodząc pole po polu, tylko po to, by jego praca została skasowana, gdy zadziała 15‑minutowy limit sesji. Następnie musi zacząć od nowa — bez gwarancji, że to samo nie wydarzy się po raz drugi.

Osoby z niepełnosprawnościami ruchowymi — na przykład korzystające z urządzeń przełącznikowych (switch access), technologii śledzenia wzroku lub ustników — mogą potrzebować wielokrotnie więcej czasu niż przeciętnie, aby wprowadzać tekst i nawigować po formularzach. Użytkownik z ALS lub rdzeniowym zanikiem mięśni może wypełniać krytyczny formularz skierowania medycznego, wpisując zaledwie kilka znaków na minutę. Limity sesji, które niszczą ich pracę, nie są drobną niedogodnością; mogą stanowić całkowitą barierę uniemożliwiającą wykonanie kluczowych zadań.

Użytkownicy z niepełnosprawnościami poznawczymi, w tym osoby z dysleksją, ADHD, urazowymi uszkodzeniami mózgu lub demencją, mogą potrzebować wielokrotnego czytania instrukcji, przerw na przetworzenie informacji lub po prostu poruszać się wolniej przez procesy wieloetapowe. Badania konsekwentnie pokazują, że ta grupa jest w nieproporcjonalnym stopniu dotknięta presją czasu i utratą danych — obie te rzeczy zwiększają obciążenie poznawcze związane z próbą rozpoczęcia wszystkiego od zera.

Rozważmy konkretny scenariusz z życia: użytkownik z stwardnieniem rozsianym składa wniosek o państwowe świadczenie z tytułu niepełnosprawności za pośrednictwem portalu internetowego instytucji publicznej. Wniosek ma 8 kroków i wymaga przesłania dokumentacji medycznej, wprowadzenia historii zatrudnienia oraz napisania osobistego oświadczenia. Użytkownik przechodzi 6 kroków w 45 minut, sesja wygasa i wszystkie wprowadzone dane zostają utracone. Musi teraz ponownie zebrać te same dokumenty i powtórzyć cały proces, potencjalnie porzucając wniosek. To nie jest hipotetyczny przykład — jest to wzorzec wielokrotnie dokumentowany w badaniach nad dostępnością i testach z użytkownikami.

Poza kwestią niepełnosprawności, utrata danych po wygaśnięciu sesji dotyka wszystkich użytkowników i ma mierzalny wpływ biznesowy: porzucone koszyki zakupowe, niedokończone rejestracje i utracone leady. Zachowanie stanu sesji jest zarówno imperatywem dostępności, jak i dobrą praktyką UX oraz optymalizacji konwersji. Według Baymard Institute porzucanie formularzy jest istotnym czynnikiem wpływającym na wskaźniki porzucania koszyków w e‑commerce, a nieoczekiwana utrata danych jest jednym z najczęściej wskazywanych powodów, dla których użytkownicy nie finalizują zakupów online.

Powiązane Reguły Axe-core

WCAG 2.2.5 wymaga wyłącznie testów manualnych. Nie istnieją zautomatyzowane reguły axe-core, które mogłyby wiarygodnie wykrywać naruszenia tego kryterium. Poniżej wyjaśniono, dlaczego narzędzia automatyczne są niewystarczające i co muszą zrobić testerzy:

• Nie istnieje zautomatyzowana reguła dla zachowania stanu sesji: Axe-core i podobne zautomatyzowane silniki dostępności działają poprzez inspekcję bieżącego DOM i ocenę statycznych lub prawie statycznych warunków, takich jak współczynniki kontrastu kolorów, poprawność atrybutów ARIA czy brak tekstów alternatywnych. Nie są w stanie zasymulować upływu czasu, wywołać zdarzenia wygaśnięcia sesji, przesłać danych uwierzytelniających przy ponownym logowaniu, a następnie sprawdzić, czy wcześniej wprowadzone dane zostały przywrócone. Cała ta sekwencja to zachowanie stanowe, zależne od czasu, które wymaga obserwacji przez człowieka (lub skryptowy test end‑to‑end).
• Wykrywanie limitu sesji wykracza poza zakres analizy statycznej: Nawet jeśli narzędzie automatyczne mogłoby wykryć, że strona implementuje limit czasu sesji (na przykład poprzez odczytanie meta refresh lub wywołania JavaScript setTimeout), nie jest w stanie ocenić, co dzieje się z danymi użytkownika po zadziałaniu limitu. Zachowanie związane z zachowaniem danych znajduje się w logice zarządzania sesją po stronie serwera, a nie w strukturze DOM analizowanej przez narzędzia automatyczne.
• Złożoność przepływu ponownego uwierzytelnienia: Doświadczenie ponownego uwierzytelnienia może obejmować wiele stron (formularz logowania, MFA, przekierowanie), a przywrócenie stanu może zależeć od logiki po stronie serwera, ciasteczek, local storage lub parametrów URL. Żadne narzędzie inspekcji pojedynczej strony DOM nie jest w stanie prześledzić tego wielostronicowego, wielosystemowego przepływu.
• Dlaczego testy manualne są niezbędne: Wykwalifikowany tester musi ręcznie zainicjować uwierzytelniony przepływ, celowo poczekać na wygaśnięcie sesji lub je wywołać, przejść proces ponownego uwierzytelnienia, a następnie zweryfikować integralność danych. To jedyna wiarygodna metoda testowania zgodności. Automatyczne skany mogą być punktem wyjścia do oznaczania powiązanych problemów (jak brak mechanizmów ostrzegania o wygaśnięciu sesji objętych 2.2.1), ale nie mogą zastąpić testów manualnych dla 2.2.5.

Jak Testować

1. Zidentyfikuj uwierzytelnione przepływy z formularzami lub procesami wieloetapowymi. Zacznij od zmapowania wszystkich obszarów serwisu, które wymagają uwierzytelnienia i obejmują wprowadzanie danych przez użytkownika — przepływy zakupowe, edytory profilu, formularze aplikacyjne, systemy rezerwacji, interfejsy wiadomości oraz panele administracyjne. To obszary o najwyższym ryzyku niespełnienia 2.2.5.
2. Ustal czas trwania sesji. Sprawdź konfigurację serwera, ustawienia aplikacji lub skonsultuj się z zespołem deweloperskim, aby dowiedzieć się, kiedy sesje wygasają. Alternatywnie rozpocznij sesję i poczekaj, aż zostaniesz automatycznie wylogowany. Zanotuj czas. Typowe limity sesji wahają się od 15 minut do 2 godzin.
3. Rozpocznij zadanie i wprowadź znaczącą ilość danych. Zaloguj się i zacznij wypełniać reprezentatywny formularz — na przykład wielopolowy formularz rejestracji lub zakupu. Wprowadź tekst w polach tekstowych, dokonaj wyborów i przejdź przez kolejne kroki kreatora. Nie wysyłaj formularza.
4. Wywołaj wygaśnięcie sesji. Poczekaj, aż naturalny limit czasu zadziała, lub — jeśli masz dostęp deweloperski — sztucznie wygasij sesję, unieważniając cookie sesji w narzędziach deweloperskich przeglądarki (zakładka Application > Cookies > usuń cookie sesji) lub bezpośrednio wygaszając sesję po stronie serwera.
5. Zaobserwuj monit o ponowne uwierzytelnienie. Sprawdź, czy witryna prosi o ponowne uwierzytelnienie (spełnienie) czy po prostu przekierowuje na stronę logowania bez ostrzeżenia (powiązany problem użyteczności, choć 2.2.5 koncentruje się na zachowaniu danych, a nie na samym ostrzeżeniu). Spróbuj zalogować się ponownie.
6. Zweryfikuj zachowanie danych po zalogowaniu. Po pomyślnym ponownym uwierzytelnieniu zaobserwuj, dokąd zostajesz przekierowany i czy wcześniej wprowadzone dane są nienaruszone. Jeśli trafiasz na stronę główną i/lub dane formularza zniknęły, jest to naruszenie 2.2.5.
7. Przetestuj z technologiami asystującymi. Powtórz powyższą sekwencję testową, używając NVDA z Firefoxem, JAWS z Chrome oraz VoiceOver z Safari, aby upewnić się, że monit o ponowne uwierzytelnienie jest dostępny dla użytkowników czytników ekranu i że przywrócony stan strony jest prawidłowo ogłaszany. Użytkownik widzący może rozpoznać przywrócone dane wizualnie; użytkownik czytnika ekranu potrzebuje prawidłowego ustawienia fokusu i umieszczenia przywróconej treści w kolejności odczytu.
8. Przetestuj nawigację wyłącznie klawiaturą. Upewnij się, że cały proces ponownego uwierzytelnienia — od powiadomienia o wygaśnięciu sesji, przez ponowne logowanie, po powrót do zachowanego zadania — można ukończyć wyłącznie za pomocą klawiatury, bez konieczności użycia myszy.
9. Przetestuj z symulacjami wydłużonego limitu czasu. Jeśli to możliwe, skróć limit czasu sesji do 1–2 minut w środowisku deweloperskim i przeprowadź pełne testy ścieżek użytkownika, aby cykl testowy był szybszy i bardziej powtarzalny.

Jak Naprawić

Prosty formularz logowania z limitem sesji — nieprawidłowy

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Prosty formularz logowania z limitem sesji — prawidłowy

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Wieloetapowy kreator tracący postęp — nieprawidłowy

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Wieloetapowy kreator tracący postęp — prawidłowy

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Ostrzeżenie o wygaśnięciu sesji bez zachowania danych — nieprawidłowe

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Ostrzeżenie o wygaśnięciu sesji bez zachowania danych — prawidłowe

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Typowe Błędy

• Przekierowywanie na stronę główną po ponownym uwierzytelnieniu zamiast na pierwotną stronę: Najczęstszy wzorzec niepowodzenia. Po zalogowaniu aplikacja wysyła użytkownika na /dashboard lub / zamiast na adres URL, na którym znajdował się w momencie wygaśnięcia sesji, zmuszając go do ręcznego powrotu do zadania — a dane są już utracone.
• Przechowywanie stanu formularza wyłącznie w pamięci JavaScript lub stanie komponentu React/Vue: Stan frameworka po stronie klienta nie przetrwa przeładowania strony wywołanego przekierowaniem na stronę logowania po wygaśnięciu sesji. Stan musi być utrwalony po stronie serwera lub w mechanizmie przechowywania (np. localStorage), który jest niezawodnie przywracany po powrocie.
• Zapisywanie „return URL” bez danych formularza: Niektóre implementacje przechowują adres URL, na który należy przekierować po zalogowaniu, ale nie zapisują faktycznych wartości pól formularza. Użytkownik trafia na właściwą stronę, ale z pustymi polami, co nadal narusza 2.2.5.
• Automatyczne zapisywanie do sessionStorage, które jest czyszczone po zamknięciu karty: Jeśli wygaśnięcie sesji powoduje, że karta przeglądarki nawiguję gdzie indziej (np. przekierowanie na logowanie), sessionStorage jest czyszczone. Użyj localStorage z przestrzenią nazw powiązaną z użytkownikiem lub, najlepiej, przechowywania szkiców po stronie serwera.
• Brak testów z polami przesyłania plików: Pola plików nie mogą być wstępnie wypełniane przez HTML ze względów bezpieczeństwa. Jeśli formularz zawiera pole przesyłania pliku, które zostało uzupełnione przed wygaśnięciem sesji, odwołanie do pliku zostaje utracone. Aplikacje muszą obsłużyć to poprzez przechowywanie odwołań do przesłanych plików po stronie serwera i pokazywanie użytkownikowi, że plik nadal jest dołączony.
• Natychmiastowe czyszczenie zapisanych szkiców po ponownym uwierzytelnieniu: Niektóre implementacje usuwają szkic natychmiast po zalogowaniu użytkownika, zanim upewnią się, że użytkownik faktycznie zobaczył i potwierdził przywrócone dane. Szkic powinien być zachowany do momentu, gdy zadanie zostanie wyraźnie ukończone lub anulowane.
• Brak ogłaszania przywróconych danych użytkownikom czytników ekranu: Po ponownym uwierzytelnieniu i przekierowaniu użytkownicy czytników ekranu potrzebują regionu aria-live lub komunikatu z fokusem, potwierdzającego, że ich dane zostały przywrócone i mogą kontynuować od miejsca, w którym przerwali. Bez tego mogą nie wiedzieć, że ich praca została zachowana.
• Odmienne traktowanie sesji opartych na AJAX od sesji opartych na stronach: Aplikacje jednostronicowe (SPA) używające uwierzytelniania tokenowego (np. wygaśnięcie JWT) często po cichu odrzucają wywołania API po wygaśnięciu tokena, nie dając użytkownikowi szansy na ponowne uwierzytelnienie i wznowienie pracy. Mechanizm ponownego uwierzytelnienia musi być równie solidny w architekturach SPA.
• Używanie <meta http-equiv='refresh'> do wymuszenia wylogowania bez wcześniejszego zapisu danych: Meta refresh, który uruchamia się po upływie limitu, natychmiast przekierowuje użytkownika bez jakiegokolwiek zachowania stanu po stronie serwera, co uniemożliwia odzyskanie danych. Zarządzanie sesją musi być obsługiwane na poziomie aplikacji z odpowiednim utrwalaniem stanu.
• Założenie, że krótkie sesje eliminują potrzebę spełnienia tego kryterium: Nawet 5‑minutowy limit sesji może dotknąć wolno piszącego użytkownika, osobę z niepełnosprawnością poznawczą ponownie czytającą instrukcje lub kogoś, komu przerwał opiekun. Czas trwania limitu nie zmienia obowiązku zachowania danych podczas ponownego uwierzytelnienia.

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 krajowe ramy dostępności cyfrowej i wskazuje WCAG 2.2 jako techniczną podstawę standardu. Okrężnica nakłada obowiązek zgodności na szeroką gamę podmiotów działających w Turcji, w tym instytucje i agencje publiczne, platformy e‑commerce, banki i dostawców usług finansowych, 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 prywatne instytucje edukacyjne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE).

WCAG 2.2.5 Re-authenticating jest kryterium na poziomie AAA, co oznacza, że nie należy do minimalnych wymogów prawnych określonych w Okrężnicy (która koncentruje się na zgodności z poziomem A i AA). Jednak organizacje, które chcą wykazać przywództwo w obszarze dostępności, obsługiwać zróżnicowane grupy użytkowników, w tym osoby z niepełnosprawnościami, lub pozycjonować się jako najlepsi dostawcy usług cyfrowych, powinny traktować kryteria poziomu AAA — zwłaszcza tak praktycznie istotne jak 2.2.5 — jako aspiracyjne cele warte realizacji.

Niektóre kategorie objętych podmiotów mają szczególnie silne powody, by wdrożyć 2.2.5. Banki i platformy finansowe często wymagają od użytkowników wypełniania długich formularzy dotyczących wniosków kredytowych, otwierania rachunków czy produktów inwestycyjnych, a ich krótkie, motywowane bezpieczeństwem limity sesji pozostają w bezpośrednim napięciu z obowiązkiem zachowania danych. Szpitale i portale opieki zdrowotnej narażają pacjentów na utratę danych podczas krytycznych zadań, takich jak rezerwacja wizyt czy wypełnianie kwestionariuszy zdrowotnych, co może mieć realne konsekwencje dla ciągłości opieki. Instytucje publiczne obsługujące e‑usługi rządowe — takie jak rozliczanie podatków, wnioski o pozwolenia czy świadczenia — obsługują obywateli z niepełnosprawnościami, którzy mogą potrzebować wydłużonego czasu na wypełnienie złożonych formularzy urzędowych.

Nawet jeśli zgodność z poziomem AAA nie jest wymagana prawnie, tureckie organizacje powinny być świadome, że regulatorzy, organizacje społeczeństwa obywatelskiego i rzecznicy praw osób z niepełnosprawnościami coraz częściej analizują jakość i kompletność wdrożeń dostępności cyfrowej. Udokumentowanie zgodności z kryteriami poziomu AAA, takimi jak 2.2.5, wzmacnia oświadczenie organizacji o dostępności, zmniejsza ryzyko sporów prawnych i pokazuje rzeczywiste zaangażowanie w projektowanie inkluzywne wykraczające poza minimalne wymogi formalne. Dla podmiotów o zasięgu międzynarodowym, szczególnie działających na rynkach UE równolegle z Turcją, kryteria poziomu AAA mogą krzyżować się z wymaganiami wynikającymi z Europejskiego Aktu o Dostępności (EAA) i powiązanych wdrożeń krajowych.