WCAG 3.3.5: Pomoc

Co oznacza ta zasada

\n

Kryterium sukcesu WCAG 3.3.5 Help (poziom AAA) stwierdza: „Dostępna jest pomoc kontekstowa.” Oznacza to, że wszędzie tam, gdzie strona internetowa lub aplikacja prosi użytkowników o wprowadzenie informacji, musi zostać zapewniona odpowiednia pomoc wyjaśniająca, czego się oczekuje. Pomoc musi być kontekstowa — to znaczy musi odnosić się bezpośrednio do pola, zadania lub procesu, z którym użytkownik jest aktualnie związany, a nie być ogólną stroną pomocy ukrytą gdzieś w nawigacji.

\n

Kryterium ma zastosowanie do każdego komponentu interfejsu użytkownika, który wymaga wprowadzenia danych: pól tekstowych, rozwijanych list, selektorów dat, kontrolek przesyłania plików, pól wyboru (checkbox), przycisków opcji (radio) oraz formularzy wieloetapowych. Pomoc kontekstowa może przyjmować wiele form, w tym instrukcje w linii, opisowe etykiety, podpowiedzi w placeholderach, dymki (tooltips), ikony pomocy rozwijające objaśnienia, linki do odpowiednich artykułów pomocy, a nawet wsparcie na żywo na czacie — o ile pomoc jest dostępna w pobliżu pola, które jej wymaga.

\n

Zaliczenie jest osiągnięte, gdy dla każdego pola, które może powodować dezorientację użytkownika, występuje co najmniej jedno z następujących: jasno sformułowana etykieta w pełni wyjaśniająca oczekiwane dane wejściowe; uzupełniający tekst opisowy znajdujący się obok pola (nie tylko placeholder, który znika po rozpoczęciu pisania); widoczny link do pomocy lub rozwijany tooltip zapewniający dodatkowe wyjaśnienia; albo łatwo dostępny mechanizm pomocy (taki jak ikona z znakiem zapytania), który ujawnia wskazówki specyficzne dla bieżącego kontekstu. Pomoc nie musi być identyczna dla wszystkich pól — kluczowym wymaganiem jest to, aby wszędzie tam, gdzie użytkownik może mieć wątpliwości, co wpisać, pomoc była realnie dostępna i dostępna pod względem technicznym.

\n

Niezaliczenie występuje, gdy pola nie zapewniają żadnego wyjaśnienia tego, czego się oczekuje, gdy pomoc jest dostępna dopiero po wysłaniu formularza i wystąpieniu błędu, gdy tooltips lub tekst pomocy są niedostępne dla użytkowników klawiatury lub czytników ekranu, albo gdy linki do pomocy prowadzą do ogólnej strony FAQ zamiast do treści istotnych dla konkretnego pola. Co istotne, poleganie wyłącznie na komunikatach o błędach po fakcie nie spełnia tego kryterium — pomoc musi być dostępna przed lub w trakcie wprowadzania danych, a nie dopiero po popełnieniu błędu.

\n

WCAG 3.3.5 nie definiuje jednego, sztywnego sposobu wdrożenia. Uznaje, że pomoc kontekstowa może być realizowana na wiele poprawnych sposobów, dając deweloperom elastyczność, ale intencja jest jednoznaczna: użytkownicy nie powinni nigdy zgadywać, czego oczekuje pole formularza. Nie ma oficjalnych wyjątków od tego kryterium — ma ono zastosowanie wszędzie tam, gdzie wymagane jest wprowadzenie danych przez użytkownika.

\n\n

Dlaczego to ma znaczenie

\n

Formularze należą do najbardziej wymagających elementów każdego interfejsu cyfrowego. Dla użytkowników z niepełnosprawnościami poznawczymi — w tym osób z dysleksją, zaburzeniami uwagi, niepełnosprawnością intelektualną lub zaburzeniami pamięci — niejednoznaczne pola formularzy mogą stanowić barierę nie do pokonania. Bez jasnej, kontekstowej pomocy tacy użytkownicy mogą wielokrotnie nie być w stanie ukończyć zadań, doświadczać znacznej frustracji lub całkowicie porzucać proces. Według Światowej Organizacji Zdrowia około 1 na 6 osób na świecie żyje z istotną niepełnosprawnością, a zaburzenia funkcji poznawczych stanowią znaczną część tej populacji.

\n

Użytkownicy o niskich kompetencjach cyfrowych lub ograniczonym doświadczeniu z interfejsami internetowymi również odnoszą ogromne korzyści z pomocy kontekstowej. Użytkownik po raz pierwszy korzystający z portalu e-usług administracji, starsza osoba składająca online wniosek o świadczenie zdrowotne czy właściciel małej firmy wypełniający formularz podatkowy mogą nie wiedzieć, jaki format jest oczekiwany dla numeru identyfikacji podatkowej, jakie typy plików są akceptowane przy przesyłaniu dokumentów lub czym różnią się dwa podobnie nazwane pola. Bez wskazówek w kontekście tacy użytkownicy są narażeni na błędy i niepokój związany z tym, że nie wiedzą, co zrobili źle.

\n

Rozważmy konkretny scenariusz: użytkownik z niepełnosprawnością poznawczą składa wniosek o dofinansowaną kartę podróżną za pośrednictwem portalu internetowego miejskiego zarządu transportu. Formularz prosi o „Numer referencyjny” bez żadnego wyjaśnienia. Użytkownik ma kilka dokumentów — dowód osobisty, kartę miejską i potwierdzenie poprzedniego wniosku — każdy z innym identyfikatorem numerycznym. Bez pomocy kontekstowej wskazującej, którego konkretnego dokumentu lub formatu się oczekuje, użytkownik prawdopodobnie wpisze niewłaściwy numer, wywoła błąd walidacji i być może zrezygnuje. Gdyby dostępna była prosta ikona pomocy lub opis w linii — „Wpisz 10-cyfrowy numer z prawego górnego rogu swojej karty miejskiej” — cała interakcja zakończyłaby się powodzeniem za pierwszym razem.

\n

Dla użytkowników, którzy są niewidomi lub słabowidzący, pomoc kontekstowa również ma znaczenie. Czytniki ekranu mogą odczytywać powiązany tekst pomocy, opisy aria-describedby lub połączoną treść pomocy, ale tylko wtedy, gdy są one poprawnie zaimplementowane. Gdy pomoc jest przekazywana wyłącznie wizualnie (jako wskaźnik koloru lub ikona bez dostępnego tekstu), użytkownicy czytników ekranu są wykluczeni. Zapewnienie, że pomoc jest zarówno obecna, jak i dostępna, wzmacnia inkluzywność w różnych grupach osób z niepełnosprawnościami.

\n

Poza dostępnością, pomoc kontekstowa poprawia ogólną użyteczność i współczynniki konwersji. Strony z jasnymi wskazówkami w formularzach odnotowują niższy współczynnik porzuceń, mniej zgłoszeń do działu wsparcia i wyższy odsetek ukończonych formularzy. W przypadku serwisów e-commerce każdy punkt procentowy poprawy w ukończeniu procesu zakupu ma bezpośredni wpływ na przychody. Wyszukiwarki również premiują strony z przejrzystą, dobrze ustrukturyzowaną treścią, a dobrze oznaczone i opisane formularze pozytywnie wpływają na sygnały jakości strony.

\n\n

Powiązane reguły Axe-core

\n

WCAG 3.3.5 wymaga testów manualnych, ponieważ zgodność zależy od jakości, trafności i kontekstowej adekwatności treści pomocy — czynników, których narzędzia automatyczne nie są w stanie ocenić. Automatyczny skaner może potwierdzić, że etykieta istnieje lub że atrybut aria-describedby wskazuje na rzeczywisty element, ale nie może określić, czy treść tej etykiety lub opisu jest faktycznie pomocna, dokładna lub wystarczająca dla danego pola.

\n

\n
• Przegląd manualny — obecność pomocy kontekstowej: Narzędzia automatyczne nie są w stanie ocenić, czy tekst pomocy rzeczywiście odpowiada na prawdopodobne pytania użytkownika dotyczące konkretnego pola. Narzędzie może wykryć, że istnieje element <label>, ale nie może ocenić, czy „Wpisz swój numer” jest wystarczająco opisowe dla pola oczekującego sformatowanego numeru rejestracji VAT. Testerzy manualni muszą ocenić, czy każde pole, które może powodować dezorientację, jest opatrzone wskazówkami, które w istotny sposób tę dezorientację zmniejszają.
\n
• Przegląd manualny — dostępność pomocy: Nawet jeśli pomoc jest widoczna wizualnie, narzędzia automatyczne mogą nie wychwycić przypadków, w których ta pomoc jest niedostępna dla technologii asystujących. Na przykład tooltip wywoływany wyłącznie na najechaniu myszą, bez równoważnego mechanizmu dostępnego z klawiatury, przejdzie wiele automatycznych testów, ale zawiedzie rzeczywistych użytkowników. Testerzy muszą zweryfikować, że wszystkie mechanizmy pomocy — tooltips, sekcje rozwijane, linki do pomocy — są osiągalne i obsługiwalne za pomocą klawiatury oraz są poprawnie odczytywane przez czytniki ekranu.
\n
• Przegląd manualny — umiejscowienie i bliskość pomocy: Automatyczne skanery nie są w stanie ocenić, czy tekst pomocy jest umieszczony wystarczająco blisko odpowiedniego pola, aby był z nim sensownie kojarzony. Akapit pomocy na dole strony lub w oknie modalnym, do którego dotarcie wymaga wielu interakcji, może technicznie istnieć, ale nie spełnia idei pomocy kontekstowej. Przegląd manualny musi potwierdzić, że pomoc jest dostępna w momencie potrzeby.
\n
• Przegląd manualny — kompletność w kontekście złożonych formularzy: Złożone, wieloetapowe formularze wprowadzają dodatkowe wyzwania. Narzędzia automatyczne sprawdzają pojedyncze pola w izolacji, ale nie są w stanie ocenić, czy łączna pomoc zapewniona w całym kreatorze wieloetapowym jest wystarczająca, aby poprowadzić użytkownika przez złożony proces. Konieczne są manualne przejścia przez formularz, aby zidentyfikować luki w wskazówkach, które ujawniają się dopiero podczas doświadczania formularza jako całości.
\n

\n\n

Jak testować

\n

\n
1. Uruchom automatyczne skanowanie dostępności jako punkt wyjścia. Użyj axe DevTools (rozszerzenie przeglądarki lub CLI), Lighthouse w Chrome DevTools lub IBM Equal Access Checker na stronie zawierającej formularz. Choć narzędzia te nie wskażą bezpośrednio naruszeń 3.3.5, ujawnią powiązane problemy, takie jak brakujące etykiety (element label niepowiązany z polem), brakujące cele aria-describedby lub niedostępne implementacje tooltipów. Najpierw rozwiązanie tych podstawowych problemów zapewnia, że gdy pomoc kontekstowa zostanie dodana, będzie również technicznie dostępna.
\n
2. Ręcznie przeanalizuj każde pole formularza pod kątem dostępności pomocy. Dla każdego pola wejściowego zadaj pytania: (a) Czy sama etykieta w pełni wyjaśnia, jakie dane są wymagane, w tym wszelkie wymagania dotyczące formatu? (b) Czy obok pola widoczny jest uzupełniający tekst pomocy? (c) Czy istnieje ikona pomocy, tooltip lub sekcja rozwijana zapewniająca dodatkowe wskazówki? (d) Czy istnieje link do odpowiedniej treści pomocy? Jeśli odpowiedź na wszystkie te pytania brzmi „nie”, a pole jest w jakikolwiek sposób niejednoznaczne, jest to naruszenie 3.3.5.
\n
3. Przetestuj dostępność z klawiatury wszystkich mechanizmów pomocy. Przejdź przez formularz, używając wyłącznie klawiatury (bez myszy). Zweryfikuj, że każdy tooltip, ikona pomocy, rozwijany opis lub link do pomocy jest osiągalny i aktywowalny za pomocą klawiatury. Tooltips powinny pojawiać się zarówno przy fokusie, jak i przy najechaniu. Przyciski pomocy powinny być wyzwalane klawiszami Enter lub Spacja. Każdy mechanizm pomocy dostępny wyłącznie za pomocą myszy nie przechodzi tego testu.
\n
4. Przetestuj z NVDA + Firefox. Przechodź do kolejnych pól formularza za pomocą klawisza Tab. Słuchaj, co NVDA ogłasza dla każdego pola — czy odczytuje etykietę? Czy odczytuje powiązany opis (przez aria-describedby)? Aktywuj ikony pomocy lub tooltips i potwierdź, że ich treść jest odczytywana. Spróbuj przejść do połączonej treści pomocy i zweryfikuj, że odnosi się ona do bieżącego pola.
\n
5. Przetestuj z VoiceOver + Safari (macOS lub iOS). Użyj VoiceOver, aby nawigować po formularzu. W macOS używaj klawisza Tab, aby przechodzić między polami i słuchać pełnego komunikatu dla każdego z nich. W iOS używaj nawigacji gestami (przeciągnięcia). Zweryfikuj, że cała treść pomocy powiązana z polami jest odczytywana na głos oraz że wyzwalacze pomocy (przyciski, linki) są dostępne i poprawnie oznaczone przez VoiceOver.
\n
6. Przetestuj z JAWS + Chrome. Użyj trybu formularzy JAWS (aktywuj klawiszem Enter, gdy fokus jest na elemencie formularza). Przechodź między polami za pomocą Tab i zweryfikuj, że JAWS odczytuje powiązane instrukcje i opisy. Użyj wirtualnego kursora JAWS, aby sprawdzić, czy treść pomocy umieszczona poza standardowymi powiązaniami etykiet jest również osiągalna.
\n
7. Przeprowadź „cognitive walkthrough”. Poproś osobę, która nie zna formularza (lub zasymuluj to, przeglądając formularz po przerwie), aby spróbowała go wypełnić bez zewnętrznych wskazówek. Zanotuj każdy moment, w którym się waha, zadaje pytanie lub popełnia błąd z powodu niejasnych oczekiwań. Każdy taki punkt jest kandydatem do poprawy pomocy kontekstowej w ramach 3.3.5.
\n

\n\n

Jak naprawić

\n

Niejednoznaczne pole tekstowe bez wyjaśnienia — niepoprawne

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Niejednoznaczne pole tekstowe z pomocą w linii — poprawne

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Ikona pomocy z tooltipem niedostępna dla użytkowników klawiatury — niepoprawne

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Ikona pomocy z tooltipem dostępna dla wszystkich użytkowników — poprawne

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

Złożony, wieloetapowy formularz bez wskazówek na poziomie kroku — niepoprawne

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Złożony, wieloetapowy formularz z kontekstową pomocą dla kroku — poprawne

\n\n

(Content truncated due to token limit — please retry this article.)