Zastanawiałem się ostatnio nad wykorzystaniem elementu label do oznaczania elementów błędu. Według specyfikacji ze stron W3C:
The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.
Uważam, że komunikat błędu można jak najbardziej podciągnąć pod tą definicję. Jest przecież bezpośrednio powiązany z daną kontrolką. Pytanie brzmi – jakie są korzyści takiego rozwiązania? Rozpatrzmy następujący formularz:
<form method="post" action="index.html">
<div id="errors">
<h2>Błędy</h2>
<ul>
<li><label for="name"><em>Imię i nazwisko</em>: Proszę podać imię i nazwisko</label></li>
<li><label for="email"><em>Email</em>: Podany adres e-mail jest nieprawidłowy</label></li>
</ul>
</div>
<div><label for="name">Imię i nazwisko <em>(wymagane)</em></label> <input type="text" name="name" id="name" value=""> <strong class="error"><label for="name">Proszę podać imię i nazwisko</label></strong></div>
<div><label for="email">Adres e-mail <em>(wymagany)</em></label> <input type="text" name="email" id="email" value="Lorem ipsum"> <strong class="error"><label for="email">Podany adres e-mail jest nieprawidłowy</label></strong></div>
<div><input type="submit" value="Wyślij formularz"></div>
</form>
Powyższy przykład na żywo
Takie rozwiązanie przypisuje bezpośrednio informację o popełnionym błędzie do danego pola formularza. Według mnie może to być bardzo istotne zwłaszcza przy długich formularzach, występujących poniżej linii zgięcia. Po przeładowaniu strony nie widzimy bezpośrednio formularza ani komunikatów błędu z nim powiązanych. Świadczy to przeważnie o niewłaściwym projekcie strony, ale przykra rzeczywistość jest taka, że od czasu do czasu musimy borykać się z tego typu problemami.
Moje pytanie brzmi – czy takie rozwiązanie jest prawidłowe (nie spotkałem się z nim na innych stronach) i czy przynosi użytkownikom jakąkolwiek korzyść? Osobiście zauważyłem już jeden problem. Kliknięcie na label w górnej liście błędów przenosi do odpowiedniego pola, ustawiając na nim focus. Nie ma jednak powrotu do listy błędów, i efekt może być taki, że znajdziemy się gdzieś w połowie formularza nie będąc jednocześnie całkowicie świadomym położenia swojego i innych pól, w których wystąpiły błędy.
Czuję, że ta technika ma przyszłość, ale obecnie nie jestem do końca pewien, jak to rozwiązać przy pomocy czystego HTML. Będę wdzięczny za wszelkie uwagi.
Dobry pomysł. Można też po przetworzeniu formularza kierować do pierwszego pola z błędem poprzez adres i odwołanie do id, no ale to się nie sprawdzi przy niskich stronach.
hej,
nie no jak dla mnie to zupelnie bezsensowna idea – tak jak gdybys na sile chcial wymyslec cos „nowego” :)
do niczego to nie prowadzi a tylko 2 razy wiecej kodu z tego…
pozdrawiam
Chodziło mi o powiązanie informacji o błędzie bezpośrednio z danym polem. Wyszedłem z założenia, że osoby, korzystające z przeglądarki odczytującej zawartość strony mają spory problem, jeśli do danego pola nie jest jasno przypisany
label, określający zawartość tego pola. To jest jasne i nie podlega dyskusji.Co jednak z komunikatami błędów, które tak samo odnoszą się do zawartości danego pola? Jeśli dana informacja nie zostanie w jasny sposób powiązana z kontrolką, to może zostać pominięta przez użytkownika.
Poza tym elementy
labelmają tę miłą cechę, że kliknięcie na nie ustawiafocusi jednocześnie przenosi do danego pola, jeśli nie jest ono widoczne na ekranie. Dlatego komunikaty błędu umieszczone na początku długiego formularza mogą pomóc w nawigacji wszystkim (a nie tylko niedowidzącym) użytkownikom.Co do ilości kodu – moim zdaniem każdy element, który wzbogaca semantykę dokumentu jest jak najmilej widziany. To zbędnych kontenerów trzeba się pozbywać, a nie np. przydatnych labeli…
hmmm przemyslalem ta idee troche glebiej i musze zwrocic honor i stwierdzic, ze jednak ma sens.
wyczytalem na W3C, ze z jednym polem moze byc powiazane wiele labeli wiec semantycznie to jest poprawne – no i gdybym byl niewidzacym widzialbym, ze z tym konkretnym polem powiazany jest komunikat bledu – chociaz glowy nie dam – musialbym to przez jakiegos screen readera przepuscic:)
pozdrawiam
To jest złe rozwiązanie!
Label służy do opisania (scharakteryzowania) pola – ma mówić co w danym polu ma się znajdować – np. Imię. Nie służy do przyklejania jakichkolwiek komunikatów (w tym tych o błędnym wypełnieniu!)
I bynajmniej nie jest to semantyczne, jak twierdzi @Grzesiek.
Grześku, czy Ty w ogóle wiesz z czym wiąże się semantyczność? Jeśli tak, to czemu nie wyjdziesz od samej nazwy elementu nie mówiąc już o czytaniu ze zrozumieniem dokumentacji?
Hmm w sumie chyba byłem za ostry trochę w powyższym komentarzu, za co przepraszam.
Zatem w wersji poprawniejszej politycznie powinienem dodać, że jest to złe rozwiązanie choćby dlatego iż programy udźwiękowiające nie zawsze radzą sobie z wieloma labelami.
Np. czytają tylko jeden (i to nie koniecznie pierwszy, wręcz przeciwnie). Zatem zatraca się „accesibility”.
No i pomysł padł już dość dawno temu i „umarł śmiercią naturalną”.
Ew. jako ułatwienie można komunikatom dodać onClicka z przenoszeniem focusa do odpowiedniego pola, jednakże to będzie tylko dla JSonUsers. Ale dostępność zostanie zapewniona zgodnie ze sztuką.
Kilka luźnych uwag:
To, że programy udźwiękowiające nie radzą sobie z kilkoma labelami przypisanymi do jednego pola to bardzo cenna uwaga. Cały pomysł miał na celu poprawienie czytelności formularzy dla użytkowników korzystających z takiego właśnie oprogramowania.
Staram się nie używać JS do dodawania funkcjonalności, którą można osiągnąć przy pomocy samego HTML.
Co do zgodności z dokumentacją – nie mnie to oceniać; techniczne specyfikacje W3C są czasami zbyt formalne (co wynika z samej natury specyfikacji), abym umiał w jednoznaczny sposób przełożyć opis danego elementu i jego zachowania na praktykę.
Znalazłem przykład na stronie Simply Accessible, gdzie autor również zagnieżdża błędy wewnątrz elementu
<label>. Robi to jednak tylko raz dla całego formularza (tzn. bez dodatkowej listy wszystkich błędów nad całym formularzem). Z kolei Peter Kranz w swoim artykule Communicating error messages accessibly proponuje takie rozwiązanie jak Michał (niestety zależne od JS).Wydaje mi się, że w świetle powyższych komentarzy, kombinacja tych dwóch technik dałaby najlepszy rezultat. Co o tym sądzicie?
@Michał Fikus: czy masz może jakieś linki do dyskusji na ten temat?
Rozwiązanie na SA jest całkiem ciekawe – i moim zdaniem poprawne semantycznie gdyż w jednym labelu zawiera nazwę pola jak i wytyczną (ale tpozostałbym przy samych wytycznych, nie komunikatach o błędach) która ściśle określa zawartość (jej format) i przez co może zapobiec powstaniu jakiegokolwiek błędu.
Wtedy JS jest niepotrzebne.
U Petera Kranza błędy są osobno – ja proponowałbym zamieszczać konkretny błąd obok pola w którym powstał.
Czemu? Wyobrażam sobie trochę obszerniejszy formularz, popełniam sporo błędów i…. dostaję n komunikatów. Jestem niewidomy, koszystam zklawiatury. Ale się naskaczę tak od kumunikatu do pola (nawet gdy JS mnie przeniesie to jest jeszcze droga powrotna)…. uff… już nie lubię tej strony ;)
Więc w takiej sytuacji usability dla niewidomych (lub ludzi korzystających tylko z klawiatury do nawigacji) leży i kwiczy o pomstę do nieba.
Zatem połączyłbym wersję z SA z moją propozycją:
- za SA wyświetlamy wytyczne w labelu
- jeśli pojawi się błąd, podajemy ładny opis obok pola z możliwością przeskoczenia na klawiaturze (zaprzęgamy JS).
Za pomocą JS nie zmieniamy wiele – wszyscy mają dostępny i jasno opisany formularz. Ci co mają JS włączony (a jest to zdecydowana większość) mają lekkiego bonusa w razie konieczności (a przy dobrym opisaniu błędy powinny występować niezwykle rzadko).
A że konieczność raczej rzadko wystąpi, to prawdopodobieństwo że ktoś „potrzebujący” nie będzie mógł skorzystać z „ułatwienia” jest znikome (jak to było… „statystycznie nieistotne”) ;)
Co do linka – nie mam… czytam wiele w sieci i raczej adresów nie zapisuje (z jednej strony sporo czasu oszczędzam…. ale momentami żałuje).
Ale jutro jak czas pozwoli to poszukam i jeśli znajdę to wrzucę tutaj.
Pozdrawiam.
http://www.access-matters.com/2005/09/10/speaking-form-labels-summary/
Proszę. Zarówno treść notki, linki z niej wychodzące i komentarze wiążą się z tym tematem.