Re: Placeholder Text for Text Boxes

Quoting Lachlan Hunt <lachlan.hunt@lachy.id.au>:
> The
> purpose of this text is to provide a hint to the user about the purpose
> of the field or expected content.

I think that those are two separate issues. In many cases, the  
placeholder is used in situations where space is at a premium, and  
having a label element displayed next to the field would not be  
possible...so there the placeholder serves the purpose of an "in situ"  
label. Providing a hint as to the expected content format may be seen  
as a separate issue.

> There are numerous problems that need to be solved with the existing
> solutions:
> (Design Principle: Solve Real Problems).
>
> 1. Accessibility issues are caused because the value is typically
> cleared on focus, and so assistive technology would miss out on reading
> the value.
>
> 2. The technique doesn't work well with password fields, since the
> value is rendered as asterisks or dots.  The Uniwired example above
> actually positions text box on top of the password field which is then
> removed upon focus to achive the effect.
>
> 3. Depending on how well the JavaScript used to implement this,
> numerous accessibility and usability issues can occur.  In extreme
> cases, some scripts will clear the value every time the field is
> focussed without checking the value.  So a value previously entered by
> the user would be cleared. In the Unwired example, the text field
> containing "Password" is not removed upon focus, and so it's not
> possible for a user without JS enabled to enter a password.


4. The technique doesn't work well on longer forms when a user has  
filled in the form, an error occurred (or the user decides to go back  
after submitting), and the UA prefills the inputs with the values that  
the user had previously entered. In those situations, the entered  
values effectively obscure the hint/label. This can result in the form  
being practically impossible to understand, particularly if there was  
some error. This situation may also arise with browsers/toolbars doing  
automatic auto-filling of forms (again, the actual hints/labels are  
obscured by prefilled data).

> Possible Solutions:
>
> * Adopt the existing JavaScript solutions
> (Design Principle: Don't Reinvent the Wheel)
> Pro: Already in use
> Con: See major problems listed above
>
> (Note that even though Don't Reinvent the Wheel is being applied here,
> the existing solutions do need to be evaluated and not just blindly
> adopted.)
>
> * Re-purpose the title attribute
> Pro: Degrades gracefully in existing UAs.  The value is still available
> via a tooltip (or equivalent) in existing browsers.
> Con: Will potentially break many existing pages, since it introduces
> new and unexpected behaviour for an existing attribute.
>
> * Introduce a new attribute
> Pro: Solves the accessibility problems with the JavaScript solution
> Pro: WebKit already implements the placeholder attribute for this purpose
> Pro: Very simple for authors to use
> Con: Doesn't work in all existing UAs.
> Con: Difficult to simulate with JavaScript (see above problems with
> JavaScript techniques)  The value could be repeated in the title
> attribute as a workaround, which would at least make the value
> available to users.

For the first situation (placeholder being used as a label in small  
space situations), another solution could/should involve an associated  
label element (possibly coupled with a CSS rule that tells the browser  
to display the label text "in situ" on the form control).

P
-- 
Patrick H. Lauke
______________________________________________________________
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________
Take it to the streets ... join the WaSP Street Team
http://streetteam.webstandards.org/
______________________________________________________________

Received on Monday, 20 August 2007 15:39:35 UTC