WCAG 3.3.9: Dostępne uwierzytelnianie (rozszerzone)

Co oznacza ta zasada

WCAG 3.3.9 — Accessible Authentication (Enhanced) to kryterium na poziomie AAA odpowiadające WCAG 3.3.8 (Accessible Authentication — Minimum, AA). Razem tworzą parę kryteriów wprowadzonych w WCAG 2.2, zaprojektowanych tak, aby proces potwierdzania tożsamości w witrynie lub aplikacji sam w sobie nie stawał się barierą w dostępności.

Na poziomie AAA 3.3.9 znacząco zaostrza wymagania. Kryterium stanowi: Test funkcji poznawczych nie może być wymagany na żadnym etapie procesu uwierzytelniania, chyba że na tym etapie zapewniono co najmniej jedno z następujących rozwiązań: alternatywną metodę uwierzytelniania, która nie opiera się na teście funkcji poznawczych; mechanizm wspomagający użytkownika w ukończeniu testu funkcji poznawczych; lub test funkcji poznawczych polega na rozpoznawaniu obiektów. Co kluczowe, w odróżnieniu od wersji AA (3.3.8), kryterium AAA usuwa wyjątek dopuszczający rozpoznawanie treści niebędących obiektami (takich jak obrazy elementów niebędących obiektami, wybranych wcześniej przez użytkownika). Na tym poziomie jedynie prawdziwe rozpoznawanie obiektów — rozpoznawanie powszechnych obiektów ze świata rzeczywistego, takich jak obrazy kota, roweru czy domu — jest dopuszczalne jako test funkcji poznawczych i tylko wtedy, gdy pozostałe warunki nie są spełnione.

Test funkcji poznawczych jest zdefiniowany jako każde zadanie wymagające od użytkownika zapamiętania, przetworzenia lub przepisania informacji. Obejmuje to: zapamiętanie nazwy użytkownika lub hasła, rozwiązanie zadania matematycznego, wypełnienie CAPTCHA wymagającej odczytania zniekształconego tekstu, odpowiedź na pytanie zabezpieczające dotyczące historii osobistej (np. „Jak miał na imię Twój pierwszy zwierzak?”) lub przepisanie sekwencji znaków. Wszystkie te zadania stanowią czynności pamięciowe lub transkrypcyjne, których wiele osób nie jest w stanie wiarygodnie wykonać.

Co uznaje się za spełnienie: Etap uwierzytelniania spełnia 3.3.9, jeśli nie wymaga żadnego testu funkcji poznawczych lub jeśli spełnia jeden z następujących warunków: (1) oferowana jest całkowicie odrębna ścieżka uwierzytelniania niewymagająca funkcji poznawczych (np. magiczny link wysłany e-mailem, WebAuthn/passkey, logowanie biometryczne); (2) mechanizm wspomaga ukończenie testu (np. menedżer haseł przeglądarki nie jest blokowany lub dozwolone jest kopiowanie i wklejanie); lub (3) jedynym testem funkcji poznawczych jest rozpoznanie powszechnego obiektu ze świata rzeczywistego z zestawu obrazów.

Co uznaje się za niespełnienie: Każdy przebieg, który zmusza użytkownika — bez obejścia lub alternatywy — do przypomnienia sobie hasła z pamięci, przepisania kodu, którego nie można wkleić, rozwiązania wizualnej lub dźwiękowej CAPTCHA bez alternatywy, odpowiedzi na pytania zabezpieczające oparte na wiedzy lub zidentyfikowania wcześniej wybranych obrazów treści niebędących obiektami (np. abstrakcyjnych kształtów lub osobistych zdjęć) bez alternatywnej ścieżki uwierzytelniania.

Oficjalne wyjątki: Specyfikacja WCAG wskazuje, że rozpoznawanie obiektów (fotografii rzeczy ze świata rzeczywistego) jest jedynym zadaniem rozpoznawania obrazów dopuszczonym na tym poziomie AAA. Kryterium AA (3.3.8) dopuszczało również rozpoznawanie „nieobiektowych” obrazów wybranych osobiście, ale 3.3.9 całkowicie usuwa ten wyjątek. Nie ma wyjątku dla „powszechnie stosowanych” wzorców uwierzytelniania — jeśli wzorzec wymaga testu funkcji poznawczych bez alternatywy, nie spełnia 3.3.9.

Dlaczego to ma znaczenie

Uwierzytelnianie jest często pierwszą istotną interakcją użytkownika z usługą cyfrową. Jeśli ta interakcja sama w sobie jest niedostępna, pozostała dostępność witryny staje się bez znaczenia — użytkownik w ogóle nie może „wejść do środka”. WCAG 3.3.9 bezpośrednio adresuje tę barierę, a jego wpływ obejmuje szerokie spektrum grup osób z niepełnosprawnościami.

Użytkownicy z niepełnosprawnościami poznawczymi — w tym osoby z dysleksją, ADHD, pourazowym uszkodzeniem mózgu, demencją lub trudnościami w uczeniu się — mogą uznać za niezwykle trudne lub niemożliwe zapamiętanie złożonych haseł, ręczne przepisanie ograniczonych czasowo jednorazowych kodów lub odczytanie zniekształconego tekstu CAPTCHA. Światowa Organizacja Zdrowia szacuje, że około 1 na 6 osób na świecie doświadcza jakiejś formy istotnej niepełnosprawności, a niepełnosprawności poznawcze stanowią jedną z największych i najbardziej zaniedbanych kategorii w dostępności sieci.

Użytkownicy z niepełnosprawnościami ruchowymi — tacy jak osoby z chorobą Parkinsona, drżeniem samoistnym, urazami rdzenia kręgowego lub korzystające z przełączników czy technologii śledzenia wzroku — mogą mieć trudności z dokładnym wpisywaniem haseł lub przepisywaniem kodów znak po znaku. Blokowanie wklejania ze schowka (powszechny środek antyfraudowy, który jest aktywnie szkodliwy) oznacza, że użytkownicy ci muszą mozolnie wprowadzać każdy znak za pomocą swojego urządzenia wspomagającego, co dramatycznie zwiększa liczbę błędów i zmęczenie.

Użytkownicy niewidomi lub słabowidzący mogą całkowicie polegać na czytnikach ekranu lub narzędziach powiększających. Wizualne CAPTCHA są całkowicie niedostępne bez alternatywy dźwiękowej, a nawet CAPTCHA dźwiękowe są notorycznie trudne dla użytkowników z ubytkiem słuchu lub zaburzeniami przetwarzania słuchowego. Wyzwania oparte na obrazach typu „zaznacz wszystkie sygnalizatory świetlne” również mogą być problematyczne, gdy opisy obrazów są nieobecne lub mylące.

Użytkownicy głusi lub słabosłyszący mogą napotykać bariery w metodach uwierzytelniania opierających się wyłącznie na połączeniach telefonicznych do dostarczania jednorazowych kodów, szczególnie gdy są to połączenia wyłącznie głosowe, bez alternatywy SMS.

Konkretny scenariusz z życia: Wyobraźmy sobie 72-letniego użytkownika z łagodnym otępieniem poznawczym, próbującego uzyskać dostęp do swojego internetowego portalu bankowego. Bank wymaga nazwy użytkownika (którą trzeba zapamiętać, nie adresu e-mail), złożonego hasła (wklejanie ze schowka jest zablokowane) oraz CAPTCHA ze zniekształconym tekstem. Użytkownik dwukrotnie nie przechodzi CAPTCHA, zostaje zablokowany i musi zadzwonić na infolinię banku — to 40-minutowy proces. Gdyby bank wdrożył passkeys lub magiczny link, użytkownik uwierzytelniłby się w kilka sekund. Taki scenariusz rozgrywa się codziennie miliony razy w sieci i jest całkowicie możliwy do uniknięcia.

Poza niepełnosprawnością, dostępne uwierzytelnianie przynosi korzyści wszystkim użytkownikom. Menedżery haseł, z których korzystają setki milionów osób, zależą od możliwości wklejania danych logowania. Blokowanie wklejania, wymaganie ręcznego przepisywania lub osadzanie niedostępnych CAPTCHA frustruje również użytkowników głównego nurtu. Istnieją także argumenty bezpieczeństwa: wymuszanie złożonego ręcznego wprowadzania haseł zwiększa prawdopodobieństwo, że użytkownicy wybiorą prostsze, słabsze hasła lub będą je powtarzać na wielu witrynach. Passkeys i magiczne linki, zalecane alternatywy, są zarówno bardziej dostępne, jak i bezpieczniejsze niż tradycyjne przepływy hasło plus CAPTCHA.

Powiązane reguły Axe-core

WCAG 3.3.9 jest sklasyfikowane jako wymagające wyłącznie testów manualnych. Od wersji axe-core 4.10 nie istnieje zautomatyzowana reguła, która w pełni ocenia to kryterium. Zrozumienie, dlaczego narzędzia automatyczne nie mogą wykryć tych naruszeń, wymaga zrozumienia, co dokładnie mierzy to kryterium.

• Wymagane testy manualne — wykrywanie testów funkcji poznawczych: Automatyczne skanery mogą wykryć obecność określonych elementów HTML (takich jak <input type='password'> lub iframe osadzający zewnętrzny widget CAPTCHA), ale nie są w stanie ustalić, czy kompletny przepływ uwierzytelniania wymaga testu funkcji poznawczych bez dostępnej alternatywy. Kryterium dotyczy całej ścieżki użytkownika, potencjalnie obejmującej wiele kroków i stron, a nie właściwości pojedynczego elementu. Skaner nie może ocenić, czy wklejanie jest programowo blokowane za pomocą JavaScript, czy limit czasu na polu wprowadzania kodu jest rozsądny ani czy alternatywna ścieżka uwierzytelniania rzeczywiście unika testów funkcji poznawczych. Są to kwestie zachowania i architektury, które wymagają, aby człowiek przeszedł przez faktyczny proces uwierzytelniania.
• Wymagane testy manualne — weryfikacja alternatywnej ścieżki: Nawet jeśli skaner wykryje widget CAPTCHA, nie może zweryfikować, czy na tej samej stronie lub w tym samym przepływie istnieje dostępna alternatywna metoda uwierzytelniania. Nie może ocenić, czy opcja „użyj zamiast tego passkey” jest rzeczywiście równoważna, czy też jest ukryta na drugorzędnej stronie ustawień, do której dostęp wymaga najpierw przejścia przez niedostępną CAPTCHA. Ocena równoważności alternatywnych ścieżek wymaga ludzkiej oceny kompletności i widoczności tych alternatyw.
• Wymagane testy manualne — zachowanie przy wklejaniu ze schowka: JavaScript przechwytujący zdarzenia paste i anulujący je (event.preventDefault() w nasłuchiwaczu wklejania) jest niewidoczny dla statycznej analizy HTML. Skaner widzi poprawny element <input>; nie może wiedzieć, że wklejanie do niego zostało wyłączone. Tylko testy manualne — fizyczna próba wklejenia hasła lub kodu — mogą ujawnić tę niezgodność.
• Wymagane testy manualne — kompatybilność widżetów uwierzytelniania z technologiami asystującymi: Zewnętrzne SDK uwierzytelniania (przyciski logowania społecznościowego, dostawcy CAPTCHA, monity biometryczne) mogą renderować się w iframe’ach lub Shadow DOM, do których skanery automatyczne nie mają pełnego dostępu. Testy manualne z użyciem czytników ekranu, takich jak NVDA, JAWS i VoiceOver, są niezbędne, aby potwierdzić, że wszystkie elementy interaktywne w przepływie uwierzytelniania są obsługiwalne i zrozumiałe.

Jak testować

1. Zidentyfikuj wszystkie punkty wejścia do uwierzytelniania: Przed testowaniem zmapuj wszystkie miejsca w aplikacji, w których użytkownik musi się uwierzytelnić lub potwierdzić tożsamość. Obejmuje to początkowe logowanie, tworzenie konta, reset hasła, monity o uwierzytelnienie dwuskładnikowe, ponowne uwierzytelnienie po wygaśnięciu sesji, ekrany potwierdzenia płatności i bramki weryfikacji wieku. Każdy z tych przepływów musi być oceniany niezależnie.
2. Uruchom automatyczny skan bazowy: Użyj axe DevTools (rozszerzenie przeglądarki) lub Lighthouse w Chrome DevTools na każdej stronie uwierzytelniania. Choć narzędzia te nie wskażą bezpośrednio naruszeń 3.3.9, ujawnią powiązane problemy — brakujące etykiety pól formularza, niedostępną zawartość iframe, brak zarządzania fokusem — które potęgują bariery w uwierzytelnianiu. Zanotuj wykryte problemy jako kontekst do oceny manualnej. W axe DevTools sprawdź kartę „Needs Review” pod kątem elementów wymagających oceny manualnej.
3. Przeprowadź audyt pod kątem testów funkcji poznawczych: Dla każdego etapu uwierzytelniania zapytaj: czy ten etap wymaga od użytkownika (a) zapamiętania czegoś, (b) przepisania czegoś lub (c) rozwiązania zagadki? Jeśli tak, zweryfikuj, że obecne i równie wyeksponowane jest co najmniej jedno z następujących: ścieżka alternatywna niewymagająca funkcji poznawczych; mechanizm (taki jak dozwolone wklejanie ze schowka lub pole kompatybilne z autouzupełnianiem) wspomagający ukończenie; lub że jedynym zadaniem poznawczym jest rozpoznanie powszechnego obiektu ze świata rzeczywistego.
4. Przetestuj zachowanie przy wklejaniu ze schowka: W każdym polu hasła i kodu skopiuj ciąg tekstu do schowka i spróbuj go wkleić za pomocą Ctrl+V (Windows/Linux) lub Cmd+V (macOS). Jeśli wklejanie jest zablokowane, jest to niezgodność. Sprawdź też, czy autouzupełnianie menedżera haseł przeglądarki nie jest tłumione (poszukaj autocomplete='off' lub JavaScriptu, który czyści wartości autouzupełniania przy fokusie).
5. Przetestuj z NVDA + Firefox: Przejdź przez cały przepływ uwierzytelniania, używając wyłącznie klawiatury i czytnika ekranu NVDA. Zweryfikuj, że wszystkie pola formularza są ogłaszane z sensownymi etykietami, wszystkie elementy interaktywne (przyciski, linki, wyzwania CAPTCHA) są osiągalne i obsługiwalne oraz że wszelkie komunikaty o błędach są programowo powiązane z odpowiednim polem i ogłaszane natychmiast, bez konieczności dodatkowej nawigacji.
6. Przetestuj z VoiceOver + Safari (macOS/iOS): Powtórz cały przepływ uwierzytelniania. Na iOS zweryfikuj również, że tam, gdzie używane jest natywne uwierzytelnianie, oferowane jest uwierzytelnianie biometryczne (Face ID / Touch ID) jako alternatywa oraz że przepływ webowy jest w pełni obsługiwalny za pomocą Switch Control, jeśli biometryka jest niedostępna.
7. Przetestuj z JAWS + Chrome: Powtórz przepływ, zwracając szczególną uwagę na to, jak ogłaszane są widżety zewnętrzne (logowanie społecznościowe OAuth, iframe’y CAPTCHA). JAWS obsługuje niektóre wzorce ARIA inaczej niż NVDA; oba muszą być przetestowane.
8. Oceń alternatywne ścieżki pod kątem rzeczywistej równoważności: Jeśli istnieje alternatywna metoda uwierzytelniania (np. „Zaloguj się magicznym linkiem”), przejdź cały przepływ, używając wyłącznie tej alternatywy. Potwierdź, że prowadzi do tego samego stanu uwierzytelnienia bez wymagania jakiegokolwiek testu funkcji poznawczych. Jeśli alternatywna ścieżka sama zawiera CAPTCHA lub test pamięci, nie jest ważną alternatywą w rozumieniu 3.3.9.
9. Udokumentuj ustalenia z dowodami: Dla każdej niezgodności wykonaj nagranie ekranu lub zrzut ekranu z adnotacjami, pokazujące dokładnie, który etap zawodzi i dlaczego. Ta dokumentacja jest kluczowa dla przekazania zadań naprawczych zespołom deweloperskim oraz dla celów audytowych.

Jak naprawić

CAPTCHA bez alternatywy — niepoprawne

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

  <button type='submit'>Log In</button>
</form>

CAPTCHA zastąpiona passkey i magicznym linkiem — poprawne

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

  <button type='submit'>Log In</button>
</form>

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Blokowanie wklejania w polu OTP — niepoprawne

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

Pole OTP z włączonym wklejaniem i podpowiedzią autocomplete — poprawne

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Pytania zabezpieczające oparte na wiedzy — niepoprawne

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Weryfikacja tożsamości z alternatywami niewymagającymi funkcji poznawczych — poprawne

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Typowe błędy

• Dodawanie autocomplete='off' do pól hasła w celu zablokowania autouzupełniania przeglądarki. Wyłącza to podstawowy mechanizm pozwalający użytkownikom uniknąć zapamiętywania haseł i bezpośrednio narusza 3.3.9. Usuń autocomplete='off' i użyj zamiast tego autocomplete='current-password' lub autocomplete='new-password'.
• Dołączanie nasłuchiwacza zdarzenia JavaScript paste, który wywołuje event.preventDefault() na polach wprowadzania danych uwierzytelniających, w przekonaniu, że poprawia to bezpieczeństwo. W rzeczywistości blokuje to menedżery haseł i technologie asystujące oraz stanowi wymóg transkrypcji w rozumieniu 3.3.9.
• Traktowanie dźwiękowej alternatywy CAPTCHA jako wystarczającego obejścia dla wizualnych CAPTCHA. CAPTCHA dźwiękowe nadal stanowią test funkcji poznawczych (przepisywanie zniekształconych znaków audio) i nie spełniają 3.3.9. Wymagana jest prawdziwa ścieżka alternatywna niewymagająca funkcji poznawczych.
• Oferowanie opcji passkey lub logowania społecznościowego, ale umieszczanie jej za wyzwaniem CAPTCHA. Jeśli użytkownik musi przejść test funkcji poznawczych, aby uzyskać dostęp do dostępnej alternatywy, alternatywa nie jest rzeczywiście równoważna, a przepływ nie spełnia 3.3.9.
• Używanie sześciu oddzielnych jednoliterowych pól <input> do wprowadzania OTP (powszechny wzorzec UI) bez obsługi wklejania wypełniającego wszystkie pola. Wiele implementacji wkleja tylko do pierwszego pola i wymaga ręcznego wprowadzania pozostałych pięciu znaków, co stanowi barierę transkrypcyjną.
• Poleganie na „Zapamiętaj mnie” lub trwałych ciasteczkach sesyjnych jako jedynym ułatwieniu dla użytkowników, którzy nie mogą się wielokrotnie uwierzytelniać. Choć zmniejszenie częstotliwości uwierzytelniania pomaga, nie naprawia niedostępnego procesu uwierzytelniania — użytkownicy nadal muszą przynajmniej raz przejść test funkcji poznawczych, a sesje wygasają lub są czyszczone.
• Implementowanie pól OTP z ograniczeniem czasowym, które po upływie czasu są czyszczone bez ostrzeżenia, zmuszając użytkowników do żądania nowego kodu i ponownej próby transkrypcji. Zwiększa to obciążenie poznawcze użytkowników z wolniejszą motoryką lub przetwarzaniem poznawczym.
• Używanie wyzwań CAPTCHA opartych na obrazach, które wymagają rozpoznawania treści niebędących obiektami — takich jak abstrakcyjne wzory, kolory lub sekwencje osobistych zdjęć — przy założeniu, że spełnia to 3.3.9. Kryterium AAA dopuszcza wyłącznie rozpoznawanie obiektów (obiekty ze świata rzeczywistego, takie jak samochody, rowery, sygnalizatory świetlne); rozpoznawanie obrazów niebędących obiektami nie jest na tym poziomie zwolnione.
• Blokowanie dostępu do menedżera poświadczeń przeglądarki poprzez autocomplete='new-password' w polach logowania (w przeciwieństwie do pól rejestracji). Wartość new-password sygnalizuje przeglądarkom, że jest to pole do tworzenia nowego hasła, co uniemożliwia autouzupełnianie zapisanych danych logowania.
• Brak testowania przepływów uwierzytelniania z użyciem rzeczywistych technologii asystujących i poleganie wyłącznie na wynikach skanów automatycznych. Ponieważ 3.3.9 jest kryterium testowalnym wyłącznie manualnie, zespoły, które pomijają manualne testy z czytnikami ekranu i klawiaturą, systematycznie przeoczą niezgodności z tym kryterium w każdym cyklu wydawniczym.

Związek z tureckimi regulacjami dotyczącymi dostępności

Turecka Okrężnica Prezydencka nr 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia kompleksowe obowiązki w zakresie dostępności serwisów internetowych i mobilnych dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okrężnica nakazuje zgodność z WCAG 2.2, czyniąc z niej pierwszy turecki akt prawny, który wprost odwołuje się do wersji 2.2 standardu.

Podmioty objęte okrężnicą obejmują: instytucje i agencje publiczne na wszystkich szczeblach administracji; platformy e-commerce i rynki internetowe; banki i instytucje finansowe; szpitale i świadczeniodawców opieki zdrowotnej; operatorów telekomunikacyjnych z 200,000 lub większą liczbą abonentów; biura podróży; prywatne firmy transportowe oraz szkoły niepubliczne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Dla tych organizacji usługi cyfrowe — w tym portale logowania, portale pacjentów, pulpity bankowości, systemy biletowe i systemy informacji o uczniach — muszą spełniać wymagania dostępności zdefiniowane w okrężnicy.

WCAG 3.3.9, jako kryterium na poziomie AAA, nie jest minimalnym obowiązkiem prawnym wynikającym z okrężnicy. Prawnie wymagany poziom bazowy odpowiada zgodności z WCAG 2.2 na poziomie A i AA. Jednak duch i zakres okrężnicy sprawiają, że 3.3.9 ma w praktyce duże znaczenie z kilku powodów.

Po pierwsze, WCAG 3.3.8 (Accessible Authentication — Minimum) jest wymaganiem na poziomie AA, a zatem jest prawnie wiążące dla wszystkich objętych podmiotów. Organizacje dążące do zgodności z 3.3.8 odkryją, że droga do spełnienia 3.3.9 jest często niewielkim krokiem dodatkowym — głównie usunięciem wyjątku dotyczącego rozpoznawania obrazów, który dopuszcza 3.3.8, oraz zapewnieniem, że wszystkie testy funkcji poznawczych mają alternatywy niewymagające funkcji poznawczych, a nie tylko mechanizmy wspomagające.

Po drugie, dla podmiotów świadczących usługi populacjom o wyższym odsetku niepełnosprawności poznawczych lub ruchowych — w szczególności szpitalom, publicznym portalom opieki zdrowotnej i portalom usług rządowych — osiągnięcie zgodności AAA w kryteriach uwierzytelniania stanowi istotne zobowiązanie do równego dostępu, które jest zgodne z szerszymi konstytucyjnymi zasadami równości Turcji oraz zobowiązaniami kraju wynikającymi z Konwencji ONZ o prawach osób z niepełnosprawnościami (CRPD), którą Turcja ratyfikowała.

Po trzecie, tureckie banki i dostawcy usług fintech podlegają szczególnej kontroli w zakresie uwierzytelniania. Banking Regulation and Supervision Agency (BDDK) oraz Financial Crimes Investigation Board (MASAK) nakładają rygorystyczne wymagania dotyczące weryfikacji tożsamości, a organizacje często wdrażają złożone, wieloetapowe przepływy uwierzytelniania, aby je spełnić. Wdrożenie uwierzytelniania zgodnego z 3.3.9 — z użyciem passkeys, WebAuthn lub przepływów magic link — jest zarówno bardziej dostępne, jak i zgodne z nowoczesnymi, bezpiecznymi praktykami uwierzytelniania zalecanymi przez międzynarodowych regulatorów finansowych, co czyni je celem projektowym, który jednocześnie wspiera zgodność na wielu frontach.

Organizacje, które chcą wyróżnić się pod względem dostępności, przygotować się na potencjalne przyszłe zaostrzenie regulacji lub świadczyć usługi w sposób dostępny i inkluzywny, są zdecydowanie zachęcane do traktowania WCAG 3.3.9 jako standardu projektowego, a nie jedynie opcjonalnego ulepszenia. Wdrożenie w pełni niewymagających funkcji poznawczych ścieżek uwierzytelniania jest coraz bardziej wykonalne dzięki nowoczesnym API przeglądarek (WebAuthn/passkeys) i SDK uwierzytelniania, co sprawia, że koszt zgodności jest niższy niż kiedykolwiek, podczas gdy korzyść — eliminacja jednej z najbardziej znaczących barier dostępności w dowolnym produkcie cyfrowym — jest ogromna.