
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>CssGlance gallery &#187; Forms</title>
	<atom:link href="http://www.cssglance.com/category/news/forms/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cssglance.com</link>
	<description>CssGlance is the first italian website focused on providing a gallery of well designed and innovative CSS based websites from all around the world.</description>
	<lastBuildDate>Mon, 05 Apr 2010 11:52:20 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Accessibility of pre-filled input fields</title>
		<link>http://www.cssglance.com/news/accessibility-of-pre-filled-input-fields/</link>
		<comments>http://www.cssglance.com/news/accessibility-of-pre-filled-input-fields/#comments</comments>
		<pubDate>Wed, 25 Feb 2009 23:06:03 +0000</pubDate>
		<dc:creator>Andrea - CSSGlance Staff</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[Forms]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[Usability]]></category>
		<category><![CDATA[Xhtml reference]]></category>

		<guid isPermaLink="false">http://www.cssglance.com/?p=2882</guid>
		<description><![CDATA[In the last few days I found myself facing a tough question: <strong>are pre-filled input fields considered accessible yet</strong>? It took me some time, asking my colleagues and consulting accessibility experts, to find out a possible answer.]]></description>
			<content:encoded><![CDATA[<p>In the last few days I found myself facing a tough question: <strong>are pre-filled input fields considered accessible yet</strong>? It took me some time, asking my colleagues and consulting accessibility experts, to find out a possible answer.</p>
<p>Let&#8217;s take a <strong>common search form</strong> as an example. For the input field which lets you type in the text you want to search, so far I&#8217;ve always been using a default pre-filled text, something like &#8220;Search the site&#8221;, &#8220;Looking for something?&#8221; or &#8220;Can we help you find something?&#8221;.</p>
<p><img  class="general-image-post" src="http://www.cssglance.com/wp/wp-content/themes/cssglance2_0/images/pre-filled-input-field.jpg" alt="Example 1 - Search form with pre-filled text input" /></p>
<p>This was because <a href="http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-place-holders">Checkpoint 10.4</a> of <a href="http://www.w3.org/TR/WCAG10/">WCAG 1.0</a> recommended that until user agents  (such as browsers or screen readers) handle empty controls correctly, we had to include default, place-holding characters in edit boxes and text areas.</p>
<p>To avoid the inconvenience for the users to have to remove the default text before typing in their keywords, I used to add a small <strong>inline JavaScript to clean up the field</strong> as soon as the user clicks on it or the field gets the focus on. This was obviously only a partial solution because users who browse the page with JavaScript disabled would have to select the default text and delete it. That could be a nuisance indeed and would affect usability as well.</p>
<p>Things have changed since December 11th 2008, when <a href="http://www.w3.org/TR/WCAG20/">WCAG 2.0</a> became <a href="http://www.w3.org/">W3C</a> recommendation. Simply reading WCAG 2.0 you don&#8217;t find any reference to pre-filled text though. This could be a bit confusing and actually that&#8217;s what disoriented me when I was trying to get an answer to my question.  </p>
<p>But, reading carefully the W3C documentation,  I finally found my answer! Within the <a href="http://www.w3.org/WAI/WCAG20/from10/comparison/">comparison of WCAG 1.0 Checkpoints to WCAG 2.0</a>, you can find the following sentence referring to Checkpoint 10.4 of WCAG 1.0:</p>
<p>Checkpoint 10.4: Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3].  This &#8220;until user agents&#8221; condition has been met. Therefore, <strong>this checkpoint is no longer required</strong>. </p>
<p>WCAG 2.0 states that we do not have to include the default text anymore, because now user agents are capable to handle correctly empty fields. This helps to clarify a bit, but I think it&#8217;s not enough yet. In fact, it is not clear if we simply can avoid to use pre-filled texts or if we don&#8217;t have to use them at all.</p>
<p>Finally, I cleared my doubts chatting with a <strong>guy who is part of the W3C project</strong> and who usually runs usability and accessibility tests in <a href="http://www.cfit.ie">CFIT</a>, the Center for Inclusive Technology, based in Dublin, Ireland. He told me that <strong>users testing</strong> show that adding pre-filled text is no longer necessary for accessibility. Research, in fact, has shown that <strong>pre-filled text fields can cause difficulties for some modern screen readers</strong>, especially if JavaScript is disabled.</p>
<p>Based on these tests and on WCAG 2.0 we should definitely stop using pre-filled text inputs. Anyway, I think that having some explanatory text might improve usability. The easiest solution, in my opinion, is to <strong>replace pre-filled texts</strong> (as &#8220;Search the site&#8221; in search forms or &#8220;dd/mm/yyyy&#8221; in date input fields) <strong>with labels</strong>. Labels are strictly related to inputs fields, by the use of the FOR and ID attributes, and describe the input they refer to. This kind of helpful info should be added to the label text. Taking our example once again, I would replace the use of the default text in the input filed with the label as follow:</p>
<p><img  class="general-image-post" src="http://www.cssglance.com/wp/wp-content/themes/cssglance2_0/images/input-field-label.jpg" alt="Example 2 - Search form with label" /></p>
<p>In this case we can be sure we comply with WCAG 2.0 and we can also sort out the accessibility issue that we would encounter when users browse the page with JavaScript disabled. Hope this article helps to clarify the matter. I&#8217;d like you guys to <strong>tell us your experience</strong> on the subject because I&#8217;m sure that something interesting could come up! </p>
]]></content:encoded>
			<wfw:commentRss>http://www.cssglance.com/news/accessibility-of-pre-filled-input-fields/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Gallery of registration/sign up forms</title>
		<link>http://www.cssglance.com/news/gallery-registrationsign-up-forms/</link>
		<comments>http://www.cssglance.com/news/gallery-registrationsign-up-forms/#comments</comments>
		<pubDate>Thu, 13 Sep 2007 14:50:13 +0000</pubDate>
		<dc:creator>Roberto</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Forms]]></category>
		<category><![CDATA[News]]></category>

		<guid isPermaLink="false">http://www.cssglance.com/news/forms/gallery-registrationsign-up-forms/</guid>
		<description><![CDATA[Christian Watson, author of a design blog named Smiley Cat, posted a showcase of 50 registration/sign-up forms which combine form design with visual appeal. The aim is to show that aesthetics and functionality/usability can coexist.]]></description>
			<content:encoded><![CDATA[<p>Christian Watson, author of a design blog named <a href="http://www.smileycat.com/">Smiley Cat</a>, posted a <a href="http://www.smileycat.com/design_elements/registration_forms/">showcase of 50 registration/sign-up forms</a> which combine form design with visual appeal. The aim is to show that aesthetics and functionality/usability can coexist.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.cssglance.com/news/gallery-registrationsign-up-forms/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Dynamic Help in Web Forms</title>
		<link>http://www.cssglance.com/news/dynamic-help-in-web-forms/</link>
		<comments>http://www.cssglance.com/news/dynamic-help-in-web-forms/#comments</comments>
		<pubDate>Tue, 19 Jun 2007 17:13:37 +0000</pubDate>
		<dc:creator>Andrea - CSSGlance Staff</dc:creator>
				<category><![CDATA[Forms]]></category>
		<category><![CDATA[News]]></category>

		<guid isPermaLink="false">http://www.cssglance.com/post/dynamic-help-in-web-forms/</guid>
		<description><![CDATA[Luke Wroblewski, author of UXmatters.com, analyzes four different dynamic Help systems for Web forms. Each of these systems has its distinct advantages and disadvantages. As with all design decisions, an understanding of user needs and business goals should inform which of these dynamic Help systems is right for your Web forms.]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.lukew.com/">Luke Wroblewski</a>, author of <a href="http://uxmatters.com/">UXmatters.com</a>, analyzes four different <a href="http://uxmatters.com/MT/archives/000191.php">dynamic Help systems for Web forms</a>. Each of these systems has its distinct advantages and disadvantages. As with all design decisions, an understanding of user needs and business goals should inform which of these dynamic Help systems is right for your Web forms.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.cssglance.com/news/dynamic-help-in-web-forms/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>



