W formularzach liczy się tempo: użytkownik szybko skanuje etykiety, rozumie pole i uzupełnia dane. Problem zaczyna się wtedy, gdy to, co widać jako label, nie jest tym samym, co technologia asystująca rozpoznaje jako nazwę elementu (accessible name). Wtedy użytkownik z czytnikiem ekranu może usłyszeć inną treść niż tę, którą widzi na ekranie.
WCAG 2.5.3 “Label in Name” koncentruje się właśnie na dopasowaniu widocznej etykiety do dostępnej nazwy kontrolki. To kryterium jest dobrym punktem odniesienia dla copywritingu: pozwala pisać etykiety tak, by były jednoznaczne, przewidywalne i “spinały się” z tym, co trafia do accessible name. A przy okazji porządkuje mikrocopy w całym polu formularza: placeholder, tooltipy i ikonki nie powinny konkurować z rolą etykiety.
Dlaczego etykieta i accessible name muszą mówić „to samo”
Wersja prosta: co użytkownik widzi vs co słyszy
Wyobraź sobie zwykłe pole formularza. Na ekranie widzisz tekst obok pola, np. “E-mail”. Dla Ciebie to jest jasne: to pole do podania adresu. Dla technologii asystującej to samo pole ma jednak programową “nazwę celu” (accessible name) wyliczaną z treści strony. Jeśli w tym wyliczeniu pojawia się inny fragment tekstu, użytkownik może usłyszeć coś innego niż “E-mail”.
WCAG 2.5.3 “Label in Name” wymaga dopasowania: gdy istnieje widoczna etykieta (tekst lub tekst na obrazie), accessible name elementu powinna zawierać ten sam tekst, który jest prezentowany wizualnie. To ma szczególne znaczenie w dialogach typu “mówię to, co widzę” — a w formularzach to normalna i potrzebna logika.
W praktyce redakcyjnej oznacza to, że nie wystarczy, by etykieta “ładnie wyglądała”. Liczy się jej tekst oraz to, czy jest to przewidywalne źródło “nazywania” pola w dostępności. Jeśli w pobliżu pola masz więcej tekstu, który mógłby zostać wzięty do wyliczenia accessible name, to ryzykujesz rozjazd. Dlatego kryterium przekłada się na konkretną zasadę copywriterską: pisz etykiety tak, żeby ich treść była jednoznaczną etykietą kontrolki, a nie tylko elementem tła.
Label w praktyce: co uznajemy za „etykietę” przy polu formularza
Jedno pole = jedna etykieta (w sensie komunikacyjnym)
W codziennej pracy redakcyjnej etykieta bywa traktowana “szeroko”: wszystko, co jest obok pola, ma działać jako etykieta. W podejściu pod WCAG 2.5.3 lepiej jednak myśleć precyzyjnie. Zwykle chodzi o tekst znajdujący się w bliskiej, konwencjonalnej relacji do kontrolki — najczęściej to tekst obok pola lub nad nim, który jednoznacznie identyfikuje, czego dotyczy pole.
Dla zespołu contentowego to bardzo praktyczny kierunek. Jeśli obok pola pojawiają się różne fragmenty (np. “Adres e-mail firmowy”, potem doprecyzowanie, potem wymóg w nawiasie), zaczynasz mieć kilka intencji naraz. A dopasowanie “label ↔ accessible name” staje się mniej przewidywalne, bo pojawia się więcej kandydatów na treść, która mogłaby zostać użyta jako nazwa elementu.
Reguła “jedno pole = jedna etykieta” dotyczy komunikacji. Etykieta ma identyfikować pole. Reszta treści może wspierać, ale powinna mieć inną rolę: hint ma informować, tooltip ma uzupełniać kontekst, a wymagania mogą być opakowane w sposób, który nie miesza się z nazwą pola. Najprościej: trzymaj etykietę jako główny tekst identyfikujący, a dodatkowe informacje porządkuj tak, by nie wyglądały jak alternatywna etykieta.
Accessible name: skąd się bierze i czemu copy ma znaczenie
Accessible name jako „krótka etykieta celu elementu”
Accessible name to nazwa elementu dostępności, z której korzystają technologie asystujące. Wyliczanie tej nazwy odbywa się według mechanizmu opisującego, jak user agent buduje nazwę z treści na stronie i ich relacji w drzewie dostępności. To kluczowe: accessible name nie jest “zrobione na oko” ani wzięte z jednego miejsca. System może korzystać z różnych źródeł, zależnie od tego, jak treść jest ułożona w interfejsie.
Algorytm “Accessible Name and Description Computation 1.1” jest opisem tego procesu: w praktyce copywriter i redaktor muszą rozumieć, że układ i treść przy polu to źródła informacji, z których “składa się” nazwa. Dlatego copy ma znaczenie nie tylko na poziomie słów. Ma znaczenie także w tym, czy tekst etykiety jest tym tekstem, do którego dostępność “wraca” jako do nazwy.
W języku redakcji można to sprowadzić do prostej metafory: accessible name to krótka etykieta celu elementu, a WCAG 2.5.3 każe utrzymać spójność między tym, co widoczne jako label, a tym, co jest deklarowane programowo jako nazwa. Jeśli twoja etykieta jest konkretna i jednoznaczna, a dodatkowe komunikaty nie mieszkają “w roli etykiety”, masz większą szansę, że użytkownik usłyszy to samo, co widzi.
ARIA i nadpisania: kiedy tekst widoczny przestaje być „tym, co słyszysz”
ARIA jako „nadpisanie” w praktyce komunikacyjnej
W teorii etykieta to tekst obok pola. W praktyce dostępność bywa konfigurowana przez rozwiązania interfejsu, w tym atrybuty ARIA. I tu pojawia się ryzyko rozjazdu. Materiał wyjaśniający WCAG 2.5.3 wskazuje, że mechanizmy ARIA mogą wpływać na końcowe wyliczenie accessible name. Innymi słowy: użytkownik może usłyszeć treść pochodzącą z atrybutu, a nie z widocznej etykiety.
To ważne dla redakcji, bo rozjazd nie zawsze wynika z “złych słów” w label. Czasem wynika z tego, że w implementacji nazwa kontrolki jest oparta o inne źródło niż ten tekst, który widzisz. Dla copywritera to sygnał, że planowanie etykiet nie kończy się na brzmieniu. Trzeba myśleć o tym, które elementy “nazywają” pole w dostępności.
ARIA APG opisuje accessible name jako etykietę przekazywaną użytkownikom technologii asystujących i podkreśla potrzebę spójności oraz przewidywalności. W praktyce: jeśli label jest inne niż accessible name, kryterium 2.5.3 mówi “dopasuj”. A jeśli ARIA nadpisuje wynik, to copy i mikrocopy muszą być dopasowane również do tego mechanizmu. Wniosek jest prosty: nie zakładaj, że to, co widzisz na ekranie, jest tym, co ostatecznie zostaje “wypowiedziane”. Spójność label ↔ accessible name wymaga weryfikacji w logice dostępności.
Checklist redakcji etykiet pod WCAG 2.5.3 (formularze na stronach i w e-commerce)
Jak pisać label, żeby był „dopasowany” w rozumieniu techniki
Poniższa checklista jest zaprojektowana dla pracy redakcyjnej. Nie zastępuje testów, ale pomaga ustawić treść tak, żeby spełnienie “Label in Name” było realistyczne. Dobrze działa na formularzach na stronach i w e-commerce, gdzie pola często mają różne tryby (logowanie, rejestracja, adres dostawy, wysyłka faktury).
- Zidentyfikuj wszystkie pola z widocznym label i traktuj je jak osobne “pozycje” w redakcji.
- Napisz label tak, aby identyfikował pole jednoznacznie (bez zawierania kilku intencji naraz).
- Upewnij się, że etykieta nie miesza się z innymi tekstami “obok” w sposób, który może sprawiać, że dostępność wybierze inny fragment jako nazwę.
- Rozdziel role: label to nazwa pola, a wskazówki mają wspierać wypełnianie, nie przejmować roli etykiety.
- Gdy obok jest więcej komunikatów (np. doprecyzowanie, wymagania, skrót), sprawdź, czy nie tworzą alternatywnej “etykiety” dla dostępności.
- Unikaj dopisywania w label treści, która ma charakter instrukcji niezwiązanej z samą identyfikacją (zostaw ją jako opis, hint albo tekst dodatkowy o innej roli).
Jeśli chcesz myśleć jeszcze prościej: w label ma dominować treść identyfikująca. Wszystko inne powinno być dopisane w taki sposób, by nie “konkurowało” o to, co trafi do accessible name. W redakcji to ustawienie priorytetów w słowach i w układzie komunikatów przy kontrolce.
Test zgodności: jak sprawdzić dopasowanie label ↔ accessible name
Co porównujesz, zanim zaczniesz iteracje copy
Żeby nie zgadywać, możesz oprzeć test na logice proponowanej w technice dopasowania accessible name do widocznej etykiety. Sedno jest takie: dla każdego inputa z widocznym label porównujesz tekst etykiety z tym, co jako dostępna nazwa elementu jest wyliczane programowo.
W praktyce podejście testowe wygląda tak: bierzesz widoczny label i traktujesz go jako “kandydata” do accessible name. Następnie sprawdzasz, jaka nazwa elementu jest udostępniana technologiom asystującym. Jeśli to jest inny tekst, przechodzi się do korekty redakcji (i/lub ułożenia treści wokół pola), bo celem jest dopasowanie.
W technice dopasowania opisywana jest też logika, zgodnie z którą można dopuścić pewne drobne różnice w zapisie etykiety (na przykład w obrębie interpunkcji czy wielkości liter, oraz przy specyficznych sytuacjach w obrębie nawiasów), ale kierunek jest zawsze ten sam: accessible name ma odpowiadać widocznej etykiecie. To oznacza, że jeśli w label jest np. “Numer telefonu”, a accessible name zostanie zbudowane z innego tekstu lub z innej etykiety z otoczenia, kryterium 2.5.3 nie jest spełnione w praktyce.
Warto też podejść do pracy etapami, zanim zaczniecie poprawiać copy “na ślepo”. Najpierw spisz pola, potem dla każdego porównaj “co widać” z “co jest nazwą”. Jeśli widać rozjazd, zmieniaj przede wszystkim to, co jest źródłem nazwy: etykietę, jej jednoznaczność oraz separację dodatkowych elementów od roli label. Dzięki temu iteracje są krótsze, a poprawki trafiają w sedno problemu.
Przykłady zapisów etykiet: jak pisać, gdy obok są ikonki/tooltipy/placeholder
Rozdzielenie ról: label jako nazwa, a reszta jako kontekst
Najczęstszy scenariusz w formularzach wygląda tak: obok pola jest ikona, czasem pojawia się tooltip z wyjaśnieniem, a w samym polu może być placeholder. To wszystko może pomagać użytkownikowi, ale w kontekście WCAG 2.5.3 najważniejsze jest rozdzielenie ról. Label ma być nazwą pola. Reszta elementów powinna działać jako kontekst, a nie jako zamiennik etykiety.
Jeśli masz ikonę w polu, potraktuj ją jak element ozdobny lub wspierający, który nie ma przejmować funkcji etykiety. Przykładowo: label powinien zawierać pełny i jednoznaczny tekst identyfikujący pole, a ikonka ma jedynie sygnalizować typ danych. Tooltip z wyjaśnieniem może opisywać “jak wypełnić” albo “co wpisać”, ale nie powinien być jedynym miejscem, gdzie użytkownik dostaje nazwę pola.
Placeholder bywa zdradliwy, bo jest tekstem widocznym wewnątrz kontrolki i użytkownicy często go czytają jako podpowiedź. W podejściu pod “Label in Name” placeholder nie powinien zastępować label. Jeśli label brzmi “Kod pocztowy”, to placeholder może podpowiadać format, ale etykieta pozostaje etykietą. Tooltip może doprecyzać, kiedy ten kod jest wymagany, jednak nadal nazwą kontrolki ma być label, a nie treść tooltipu.
W praktyce redakcyjnej możesz prowadzić takie reguły zapisów:
- Label pisz jako pełną nazwę pola, bez “ukrywania” sensu w tooltipie.
- Placeholder traktuj jako przykład formatu lub krótką wskazówkę, nie jako tożsamość pola.
- Jeśli tooltip zawiera słowa, które mogłyby brzmieć jak etykieta, dopilnuj, by label nadal zawierał te same podstawowe słowa identyfikujące (tak, aby dopasowanie miało szansę się utrzymać).
Takie podejście redukuje ryzyko, że użytkownik z czytnikiem ekranu usłyszy inną nazwę niż tę, którą widzi. A co najważniejsze, porządkuje mikrocopy: etykieta ma prowadzić, a dodatkowe elementy mają wspierać wypełnianie formularza bez przejmowania roli nazwy.
Skontaktuj się z Aleteksty.pl, aby omówić artykuły, teksty na stronę, opisy produktów lub regularną obsługę treści.
