WCAG 3.3.3: Sugestia dotycząca błędu

Co Oznacza Ta Zasada

WCAG 3.3.3 Error Suggestion (Sugestia Błędu) jest kryterium poziomu AA w ramach zasady Zrozumiałość (Understandable). Bezpośrednio opiera się na 3.3.1 (Error Identification – Identyfikacja Błędu), które wymaga, aby błędy były identyfikowane w tekście. Error Suggestion idzie dalej: gdy błąd wprowadzania jest automatycznie wykrywany, interfejs musi również zasugerować użytkownikowi, jak może go poprawić, o ile sugestia ta nie narusza bezpieczeństwa ani celu treści.

Kluczowe rozróżnienie dotyczy identyfikacji błędu i sugestii błędu. Komunikat „Twoja data urodzenia jest nieprawidłowa” to identyfikacja. Komunikat „Twoja data urodzenia jest nieprawidłowa — wprowadź datę w formacie DD/MM/RRRR” to sugestia. Oba są wymagane w ramach swoich kryteriów, ale Error Suggestion wymaga, aby wykonalne, korygujące wskazówki towarzyszyły komunikatowi o błędzie wszędzie tam, gdzie jest to możliwe.

Kryterium ma zastosowanie za każdym razem, gdy błąd wprowadzania jest automatycznie wykrywany — to znaczy, gdy logika walidacji po stronie klienta lub serwera określa, że przesłana lub wprowadzona wartość nie spełnia oczekiwanych kryteriów. Dotyczy wszystkich kontrolek formularza: pól tekstowych, list rozwijanych, pól wyboru (checkbox), przycisków opcji (radio), selektorów daty, pól przesyłania plików oraz dowolnego interaktywnego komponentu zbierającego dane użytkownika.

Co jest uznawane za spełnienie wymogu: Komunikat o błędzie jest prezentowany w formie tekstu (nie tylko kolorem lub ikoną), wyraźnie identyfikuje pole z błędem i zapewnia konkretne wskazówki, jak go poprawić. Na przykład: „Hasło musi mieć co najmniej 8 znaków i zawierać jedną wielką literę” zamiast samego „Nieprawidłowe hasło”. Sugestia musi pojawić się w pobliżu pola, być z nim powiązana programowo (za pomocą aria-describedby lub podobnego mechanizmu) i być postrzegalna dla technologii asystujących.

Co jest uznawane za niespełnienie wymogu: Każdy komunikat o błędzie, który jedynie stwierdza, że wystąpił błąd, bez wyjaśnienia, co jest nie tak lub jak to naprawić. Ogólne komunikaty, takie jak „Błąd”, „Nieprawidłowe dane” lub „Pole wymagane” bez dodatkowego kontekstu, nie spełniają tego kryterium. Błędy komunikowane wyłącznie za pomocą czerwonej ramki lub ikony ostrzegawczej, bez opisu tekstowego, również nie spełniają wymogu.

Zdefiniowane wyjątki: Kryterium zawiera dwa wyraźne wyjątki, w których sugestia nie jest wymagana. Po pierwsze, jeśli podanie sugestii zagrażałoby bezpieczeństwu — na przykład w formularzu logowania, gdzie dokładne wyjaśnienie, dlaczego hasło zostało odrzucone (złe hasło vs. zła nazwa użytkownika), mogłoby ułatwić ataki metodą brute force. Po drugie, jeśli podanie sugestii zagrażałoby celowi treści — na przykład w quizie edukacyjnym, gdzie ujawnienie poprawnej odpowiedzi niweczy cel oceny. Te wyjątki są wąskie i nie powinny być używane do unikania wymogu w standardowych kontekstach formularzy.

Dlaczego To Ma Znaczenie

Error Suggestion istnieje, ponieważ wypełnianie formularzy jest jedną z najbardziej obciążających poznawczo aktywności, jakie użytkownicy wykonują w sieci, a jednocześnie jedną z najbardziej doniosłych — błędy w formularzach płatności, wnioskach o świadczenia rządowe, formularzach medycznych czy portalach bankowych mogą mieć realne konsekwencje dla użytkowników, którzy nie są w stanie zrozumieć, co poszło nie tak ani jak się z tego wybrnąć.

Niepełnosprawności poznawcze: Użytkownicy z dysleksją, ADHD, trudnościami w uczeniu się lub ograniczoną umiejętnością czytania mogą mieć trudność z rozszyfrowaniem niejasnych komunikatów o błędach i powiązaniem ich z konkretnym polem lub wymaganym formatem. Bez jasnej sugestii korekty mogą całkowicie porzucić formularz lub przesłać nieprawidłowe informacje. Według Światowej Organizacji Zdrowia około 1 na 6 osób na świecie — ponad 1,3 miliarda — żyje z jakąś formą niepełnosprawności, a niepełnosprawności poznawcze należą do najbardziej rozpowszechnionych, a jednocześnie najsłabiej uwzględnianych kategorii.

Osoby niewidome i słabowidzące: Użytkownicy czytników ekranu polegają wyłącznie na opisach tekstowych, aby zrozumieć błędy walidacji. Gdy komunikat o błędzie mówi jedynie „Nieprawidłowe” i nie zawiera sugestii, użytkownik nie ma sposobu, by ustalić, co „nieprawidłowe” oznacza w kontekście danego pola. Nie może rzucić okiem na sąsiednie etykiety, tekst zastępczy (placeholder) czy wskazówki wizualne, aby wywnioskować oczekiwany format. Jasna sugestia, powiązana programowo z polem za pomocą aria-describedby, jest jedynym wiarygodnym kanałem informacji.

Użytkownicy z niepełnosprawnością ruchową: Użytkownicy polegający na przełącznikach, sterowaniu głosem lub alternatywnych urządzeniach wejściowych ponoszą znaczny wysiłek fizyczny podczas wypełniania formularzy. Konieczność ponownego przechodzenia przez formularz po nieudanym przesłaniu — bez zrozumienia, co należy zmienić — nakłada nieproporcjonalnie duże obciążenie. Jasne sugestie zmniejszają konieczność ponownego wprowadzania danych i liczbę cykli nieudanych przesłań.

Osoby niebędące rodzimymi użytkownikami języka oraz osoby starsze: Użytkownicy, którzy nie posługują się biegle językiem formularza lub mają mniejsze doświadczenie z konwencjami sieciowymi, również w dużym stopniu korzystają z jednoznacznych sugestii korekty. Komunikat taki jak „Wpisz numer telefonu bez spacji i kresek, np. 05321234567” usuwa niejednoznaczność dla użytkowników, którzy w przeciwnym razie mogliby nigdy nie ukończyć formularza.

Scenariusz z życia wzięty: Rozważ obywatela Turcji składającego wniosek o świadczenie socjalne za pośrednictwem portalu e-administracji. Wniosek wymaga podania numeru TR Identity Number (TC Kimlik Numarası), o specyficznym, 11-cyfrowym formacie. Jeśli użytkownik wpisze 10 cyfr i otrzyma jedynie komunikat „TC Kimlik Numarası hatalı” (numer TC jest nieprawidłowy), użytkownik z niepełnosprawnością poznawczą, osoba starsza lub użytkownik czytnika ekranu może nie wiedzieć, czy numer jest za krótki, zawiera nieprawidłowy znak, czy ma problem z formatem. Dodanie „TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901” (numer TC musi mieć 11 cyfr, np. 12345678901) natychmiast usuwa niejednoznaczność i umożliwia użytkownikowi samodzielną korektę.

Korzyści użytecznościowe i konwersyjne: Poza dostępnością, porzucanie formularzy jest kluczową metryką biznesową. Badania konsekwentnie pokazują, że niejasne komunikaty o błędach należą do głównych powodów, dla których użytkownicy porzucają procesy zakupowe w e-commerce i ścieżki rejestracji. Konkretne, wykonalne sugestie błędów zmniejszają wskaźniki porzucania formularzy i poprawiają wskaźniki ich ukończenia dla wszystkich użytkowników — czyniąc to kryterium zarówno silnym argumentem biznesowym, jak i wymogiem dostępności.

Powiązane Reguły Axe-core

WCAG 3.3.3 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie ocenić jakości ani kompletności tekstu komunikatów o błędach. Skaner automatyczny może wykryć, że komunikat o błędzie istnieje i że jest powiązany programowo z polem formularza, ale nie może określić, czy komunikat faktycznie zapewnia użyteczną sugestię korekty. Wymaga to oceny człowieka, czy tekst jest konkretny, wykonalny i wystarczający, aby poprowadzić użytkownika do poprawnego wpisu.

• Przegląd manualny — jakość treści komunikatu o błędzie: Testerzy muszą ręcznie wywołać każdy warunek walidacji (przesłać puste pole wymagane, wprowadzić dane w złym formacie, przekroczyć limity znaków itd.) i ocenić każdy pojawiający się komunikat o błędzie. Tester zadaje pytanie: czy ten komunikat mówi użytkownikowi nie tylko, że wystąpił błąd, ale konkretnie, co powinien zrobić, aby go poprawić? Jeśli komunikat jest ogólny („Nieprawidłowe”, „Błąd”, „Sprawdź to pole”), nie spełnia 3.3.3, niezależnie od tego, czy jest programowo eksponowany.
• Przegląd manualny — powiązanie programowe: Testerzy muszą zweryfikować, że tekst sugestii błędu jest programowo powiązany z odpowiednim polem wejściowym za pomocą aria-describedby, regionów aria-live lub powiązania inline, tak aby czytniki ekranu odczytywały go bez konieczności dodatkowej nawigacji. Częściowo pokrywa się to z regułami axe, takimi jak label i aria-input-field-name, ale sam tekst sugestii nie jest przez te reguły sprawdzany.
• Przegląd manualny — zasadność wyjątku bezpieczeństwa: Testerzy powinni zweryfikować, że każdy formularz pomijający sugestie korekty z powodów bezpieczeństwa (np. formularze logowania) faktycznie kwalifikuje się do zastosowania wyjątku bezpieczeństwa i że wyjątek ten nie jest używany do unikania wymogu w polach niesensytywnych.
• Częściowo zautomatyzowane — reguła label: Podczas gdy reguła label w axe-core sprawdza, czy pola formularza mają dostępne nazwy, nie sprawdza, czy komunikaty o błędach zawierają sugestie korekty. Może ujawnić brakujące etykiety, które pogłębiałyby problem z sugestiami błędów, a naprawienie problemów z etykietami jest warunkiem wstępnym skutecznej implementacji Error Suggestion.

Jak Testować

1. Automatyczny skan bazowy: Uruchom axe DevTools lub Lighthouse na stronie zawierającej formularz. Zanotuj wszelkie istniejące naruszenia związane z etykietami formularzy, rolami ARIA lub identyfikacją błędów (3.3.1). Muszą one zostać najpierw rozwiązane, ponieważ są warunkiem wstępnym skutecznych sugestii błędów. Automatyczne skany nie wykryją brakujących sugestii — ustanawiają jedynie bazę strukturalną.
2. Wywołaj każdy warunek walidacji: Dla każdego pola formularza celowo wywołaj każdy możliwy stan błędu: prześlij puste pole wymagane, wprowadź dane w nieprawidłowym formacie (zły format daty, nieprawidłowy e-mail, zbyt krótkie hasło, wartość nienumeryczna w polu numerycznym) i przekrocz limity znaków. Udokumentuj każdy pojawiający się komunikat o błędzie.
3. Oceń jakość sugestii: Dla każdego komunikatu o błędzie zadaj pytania: (a) Czy identyfikuje konkretne pole? (b) Czy wyjaśnia, co jest nie tak? (c) Czy zapewnia wykonalne wskazówki, jak poprawić wpis? Komunikat, który odpowiada na wszystkie trzy pytania, spełnia 3.3.3. Komunikat, który odpowiada tylko na (a), spełnia 3.3.1, ale nie spełnia 3.3.3.
4. Testy z czytnikiem ekranu NVDA + Firefox: Przejdź do formularza za pomocą klawisza Tab. Wprowadź nieprawidłową wartość. Prześlij formularz lub przenieś fokus. Posłuchaj, co ogłasza NVDA. Zweryfikuj, że tekst sugestii błędu jest odczytywany automatycznie (za pomocą regionu aria-live lub zarządzania fokusem na błąd), bez konieczności ręcznego wyszukiwania.
5. Testy z czytnikiem ekranu VoiceOver + Safari (macOS/iOS): Wykonaj te same kroki. Użyj VO+strzałka w prawo, aby odczytać pole i jego powiązany opis. Potwierdź, że tekst sugestii jest ogłaszany jako część opisu dostępnego pola, a nie tylko jako pobliski tekst, który może zostać pominięty.
6. Testy z czytnikiem ekranu JAWS + Chrome: Po przesłaniu formularza z błędami potwierdź, że JAWS odczytuje sugestię błędu albo poprzez zarządzanie fokusem (fokus przeniesiony do podsumowania błędów), albo poprzez aktualizacje regionu aria-live. Użyj wirtualnego kursora JAWS, aby przejść do pola i potwierdzić, że sugestia jest częścią opisu pola.
7. Nawigacja wyłącznie klawiaturą: Bez czytnika ekranu przejdź przez formularz, używając tylko Tab, Shift+Tab i Enter. Zweryfikuj, że sugestie błędów są widoczne w obszarze widoku, a nie ukryte poza ekranem lub zasłonięte przez inne elementy, gdy pole otrzymuje fokus po nieudanym przesłaniu.
8. Zweryfikuj wyjątki bezpieczeństwa: Dla formularzy logowania i uwierzytelniania potwierdź, że pominięcie konkretnych sugestii jest zamierzone i udokumentowane oraz że wyjątek bezpieczeństwa jest ograniczony do absolutnie niezbędnych pól.

Jak Naprawić

Ogólny komunikat o błędzie — Niepoprawne

<!-- Komunikat o błędzie nie zawiera sugestii, jak naprawić problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Ogólny komunikat o błędzie — Poprawne

<!-- aria-describedby łączy tekst sugestii z polem;
     sugestia dokładnie wyjaśnia, jaki format jest oczekiwany -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Walidacja hasła bez wskazówek dotyczących formatu — Niepoprawne

<!-- Użytkownik jest informowany, że hasło jest błędne,
     ale nie wie dlaczego ani jak to naprawić -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Walidacja hasła bez wskazówek dotyczących formatu — Poprawne

<!-- Sugestia dokładnie wymienia, co musi zawierać hasło,
     umożliwiając użytkownikowi samodzielną korektę bez zgadywania -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Pole daty z niejednoznacznym błędem formatu — Niepoprawne

<!-- Brak wskazania, jaki format daty jest oczekiwany -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Pole daty z niejednoznacznym błędem formatu — Poprawne

<!-- Sugestia podaje wymagany format i konkretny przykład,
     usuwając wszelką niejednoznaczność -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Formularz wielopolowy z podsumowaniem błędów po stronie serwera — Niepoprawne

<!-- Podsumowanie błędów istnieje, ale linki nie łączą sugestii
     z poszczególnymi polami, a komunikaty są nieprecyzyjne -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Formularz wielopolowy z podsumowaniem błędów po stronie serwera — Poprawne

<!-- Podsumowanie błędów zawiera powiązane, konkretne sugestie;
     każdy element listy linkuje do odpowiedniego pola;
     błędy inline pojawiają się również obok każdego pola -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Najczęstsze Błędy

• Używanie placeholder jako substytutu sugestii błędów: Tekst zastępczy znika, gdy tylko użytkownik zaczyna pisać, i nie jest wiarygodnie ogłaszany przez czytniki ekranu jako błąd. Nigdy nie polegaj wyłącznie na placeholderze, aby komunikować wymagany format po wystąpieniu błędu.
• Wyświetlanie komunikatów o błędach wyłącznie w powiadomieniu typu „toast”, które znika po kilku sekundach: Przemijające powiadomienia nie są postrzegalne dla wszystkich użytkowników — użytkownicy czytników ekranu mogą przegapić ogłoszenie, a komunikat znika, zanim wolniej czytający zdąży go przetworzyć. Sugestie błędów muszą pozostać widoczne, dopóki błąd nie zostanie poprawiony.
• Używanie aria-invalid='true' bez aria-describedby wskazującego na tekst sugestii: Ustawienie aria-invalid sygnalizuje, że pole zawiera błąd, ale bez aria-describedby łączącego z elementem sugestii czytniki ekranu nie odczytają tekstu sugestii po ustawieniu fokusu na polu.
• Umieszczanie sugestii wyłącznie w projekcie wizualnym (np. dymek podpowiedzi przy najechaniu) i nie w DOM: Podpowiedzi dostępne tylko przy najechaniu kursorem są niedostępne dla użytkowników klawiatury i czytników ekranu. Tekst sugestii musi być obecny w DOM i programowo powiązany z polem.
• Używanie wyłącznie koloru lub ikonografii do wskazania, które pole zawiera błąd: Czerwona ramka lub ikona ostrzegawcza nie stanowi sugestii błędu. Sugestia musi być opisem tekstowym, który wyjaśnia działanie naprawcze, a nie wskaźnikiem wizualnym.
• Pisanie sugestii, które identyfikują problem, ale nie rozwiązanie: „Twoje hasło jest za krótkie” identyfikuje błąd, ale nie sugeruje rozwiązania. „Twoje hasło musi mieć co najmniej 8 znaków” zapewnia niezbędne wskazówki korekty. Obie części są wymagane dla zgodności z 3.3.3.
• Zbyt szerokie stosowanie wyjątku bezpieczeństwa: Wyjątek bezpieczeństwa ma wąskie zastosowanie do sytuacji, w których podanie sugestii rzeczywiście naruszałoby bezpieczeństwo — zazwyczaj ograniczone do pól uwierzytelniających. Nie dotyczy standardowych pól formularza, takich jak imiona, adresy czy numery telefonów, gdzie ogólne błędy są nieuzasadnione.
• Umieszczanie sugestii błędu za przyciskiem „Wyślij” lub daleko od pola: Sugestie błędów muszą być wizualnie i programowo blisko pola, którego dotyczą. Umieszczanie wszystkich błędów na dole długiego formularza, bez jednoczesnych sugestii inline przy każdym polu, zmusza użytkowników do przełączania kontekstu i zapamiętywania, która sugestia dotyczy którego pola.
• Brak przeniesienia fokusu do podsumowania błędów po nieudanym przesłaniu po stronie serwera: Gdy strona przeładowuje się po nieudanym przesłaniu, fokus zazwyczaj wraca na górę strony. Bez programowego zarządzania fokusem do podsumowania błędów lub pierwszego pola z błędem użytkownicy czytników ekranu muszą przejść przez całą stronę, aby dowiedzieć się, co poszło nie tak.
• Używanie niejasnych sformułowań, takich jak „Sprawdź swoje dane” lub „Coś poszło nie tak”: Takie komunikaty nie dostarczają informacji o tym, co jest nie tak ani jak to naprawić. Każda sugestia błędu musi być specyficzna dla pola i konkretnej reguły walidacji, która została naruszona.

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

Obszar dostępności w Turcji znacząco się rozwinął wraz z wydaniem Okrężnika Prezydenckiego 2025/10, opublikowanego w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r. Okrężnik ten ustanawia obowiązkowe wymagania dostępności dla stron internetowych i aplikacji mobilnych, zgodne z WCAG 2.2, z wymaganą zgodnością na poziomie AA dla podmiotów ubiegających się o Erişilebilirlik Logosu (Logo Dostępności) wydawane przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.3.3 Error Suggestion, jako kryterium poziomu AA, mieści się w zakresie tego obowiązkowego wymogu. Każdy objęty podmiot, który obsługuje formularze — do rejestracji, płatności, wniosków o usługi lub zarządzania kontem — musi zapewnić, że jego komunikaty o błędach nie tylko identyfikują błędy, ale dostarczają wykonalnych sugestii korekty, zgodnie z opisem w tym kryterium.

Podmioty objęte Okrężnikiem Prezydenckim 2025/10 obejmują szeroki zakres sektorów. Instytucje publiczne i agencje rządowe są zobowiązane do przestrzegania wymogów, co oznacza, że wszystkie portale e-administracji (np. usługi e-Devlet, portale miejskie, systemy składania wniosków o świadczenia) muszą zapewniać zgodne implementacje sugestii błędów. Biorąc pod uwagę, że wiele usług rządowych wymaga od obywateli podawania złożonych danych osobowych — numerów identyfikacyjnych, kodów adresowych, numerów podatkowych — jasne sugestie błędów są w tym kontekście szczególnie krytyczne.

Banki i instytucje finansowe są objęte wymogami, w tym platformy bankowości internetowej, formularze rejestracji kont inwestycyjnych i portale wniosków kredytowych. Formularze te rutynowo zbierają wrażliwe i precyzyjnie sformatowane dane, a brak sugestii korekty tworzy realne bariery dla klientów z niepełnosprawnościami i potencjalne ryzyko prawne.

Szpitale i świadczeniodawcy opieki zdrowotnej również muszą przestrzegać wymogów, co obejmuje systemy rejestracji pacjentów, formularze rezerwacji wizyt i portale zgłaszania roszczeń ubezpieczeniowych. Formularze medyczne często zawierają złożone wymagania dotyczące pól (kody diagnoz, numery polis ubezpieczeniowych, precyzyjne formaty dat), co sprawia, że jasne sugestie błędów są szczególnie ważne dla pacjentów starszych i z niepełnosprawnościami poznawczymi.

Przedsiębiorstwa telekomunikacyjne z 200,000 lub większą liczbą abonentów są objęte wymogami, co obejmuje portale klienta głównych operatorów, formularze rejestracji kart SIM i interfejsy zarządzania kontem. Platformy e-commerce — w tym procesy zakupowe i rejestracji kont — muszą być zgodne z wymogami, co sprawia, że Error Suggestion ma bezpośrednie znaczenie dla formularzy zarządzania produktami i koszykiem, które są kluczowe dla ich działalności.

Biura podróży, prywatne firmy transportowe i szkoły prywatne autoryzowane przez Ministerstwo Edukacji Narodowej (MoNE) również mieszczą się w zakresie. Formularze rezerwacji, wnioski rekrutacyjne i interfejsy płatności obsługiwane przez te podmioty muszą spełniać standardy poziomu AA, w tym 3.3.3.

Z praktycznego punktu widzenia zgodności, organizacje ubiegające się o Erişilebilirlik Logosu powinny traktować WCAG 3.3.3 jako kluczowy punkt audytu podczas każdej oceny dostępności. Wymagane są testy manualne wszystkich przepływów walidacji formularzy — obejmujące zarówno błędy po stronie klienta, jak i serwera — a dokumentacja uzasadnienia zastosowania wyjątku bezpieczeństwa powinna być utrzymywana dla wszystkich pól, w których sugestie korekty są celowo pomijane. Niespełnienie wymogów poziomu AA, w tym Error Suggestion, uniemożliwi przyznanie logo i może narazić objęte podmioty na konsekwencje administracyjne wynikające z okrężnika.