Let’s take a common search form as an example. For the input field which lets you type in the text you want to search, so far I’ve always been using a default pre-filled text, something like “Search the site”, “Looking for something?” or “Can we help you find something?”.

This was because Checkpoint 10.4 of WCAG 1.0 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.

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 inline JavaScript to clean up the field 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.

Things have changed since December 11th 2008, when WCAG 2.0 became W3C recommendation. Simply reading WCAG 2.0 you don’t find any reference to pre-filled text though. This could be a bit confusing and actually that’s what disoriented me when I was trying to get an answer to my question.

But, reading carefully the W3C documentation, I finally found my answer! Within the comparison of WCAG 1.0 Checkpoints to WCAG 2.0, you can find the following sentence referring to Checkpoint 10.4 of WCAG 1.0:

Checkpoint 10.4: Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3]. This “until user agents” condition has been met. Therefore, this checkpoint is no longer required.

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’s not enough yet. In fact, it is not clear if we simply can avoid to use pre-filled texts or if we don’t have to use them at all.

Finally, I cleared my doubts chatting with a guy who is part of the W3C project and who usually runs usability and accessibility tests in CFIT, the Center for Inclusive Technology, based in Dublin, Ireland. He told me that users testing show that adding pre-filled text is no longer necessary for accessibility. Research, in fact, has shown that pre-filled text fields can cause difficulties for some modern screen readers, especially if JavaScript is disabled.

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 replace pre-filled texts (as “Search the site” in search forms or “dd/mm/yyyy” in date input fields) with labels. 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:

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’d like you guys to tell us your experience on the subject because I’m sure that something interesting could come up!

This has been declared in WCAG 2.0, published as a W3C Recommendation on December 11th, 2008, where Guideline 1.3 states that we should always create content that can be presented in different ways (for example simpler layout) without losing information or structure.

The easiest way to meet this guideline is to develop our websites starting from a good semantic XHTML structure. We should organize the code so that the most important content always comes as close to the top of the page as possible. Once we have the structure we can then use CSS to change the presentation. But content has to come first. As you know on the Internet content is king and always will be.

The main issue with this approach is that sometime it’s not that easy to get the positioning we need without moving bits of XHTML around. Obviously this practice could mess up the content order, jeopardizing the accessibility of the page.

Dan Johnson published a cool article on how to use CSS floats to achieve any column layout, while keeping the most relevant content highest on the page.

In his example, he uses the exact same HTML markup to create six different layouts by the clever use of CSS styles. This is a great sample of how we can get the design we need, keeping the content in order of priority and safeguarding accessibility.

Try it out!

The first idea was not our own. I think you can easily remember the great success made by what was called “The Million Dollar Homepage”. A simple page covered by a lot of mini banners which has led the owner to become millionaire and to leap to fame.

Quite a few websites adopted this useful way of making money. You can see good examples on CSS Remix and Italian Web Gallery.

In the most cases, you can get more information about the single banner by passing the mouse pointer over it. By doing this action, a small tooltip will appear, providing additional info as the name, the tagline or simply a link back to the website who bought the adv block.

This feature is often realized by using a small JavaScript. But what will happen to those users browsing a page without JavaScript enabled? The answer is simple. They won’t see the tooltip and the adv info. That means the content is not accessible.

So, what can we do to get the same nice tooltip feature and to improve accessibility? The solution is CSS. In fact, we can create pure CSS tooltips which are simple, useful and accessible, ‘cos they work even if the user browse the page without JavaScript enabled. This is the way we followed on CSSGlance.

This is what we’re looking for and now let’s go into details.

We just need a plain list of links. The XHTML code is something like this:

<ul>
<li><a href="http://www.google.com"> <span>Google.com</span></a></li>
<li><a href="http://www.yahoo.com"> <span>Yahoo.com</span></a></li>
<li><a href="http://www.cssbeauty.com"> <span>CSSBeauty.com</span></a></li>
...
</ul>

Now we have to float the <li> elements in order to put side by side each block. Then we can add a relative position to the links, in order to allow the span element inside to position absolutely respect the parent link. The span have also a display:none property which is changed into a display:block one when the mouse pointer pass over the block. You can easily solve ie bug adding some z-index.

Here you have the basic CSS code:

#miniadv ul{margin:0;padding:0;list-style:none}
#miniadv ul li {float:left;margin:0 2px 2px 0}
#miniadv a{float:left;position:relative;z-index:5; width:18px;height:18px}
#miniadv a:hover{z-index:10}
#miniadv a span{display:none}
#miniadv a:hover span {display:block;position:absolute; bottom:2em;right:2em;width:135px}

Let’s take a look at the example! You can download this example (zip-9KB) and use it however you like, but please give a link back to CSSGlance.