Placeholder text: clever, or too clever?

HTML5 allows you to have "placeholder" text - text in a form field to give hints about what you should put there.  There are a number of ways to use it incorrectly and poorly.  It should never be used as the label for the field, because it disappears as soon as you click on it or tab into it.  "Wait, is this the zip code field?"  And it shouldn't be used for important instructions, for the same reason.  "What date format did they want me to use?"

For simple forms, like a search box or a user name and passwrod login screen, you can sometimes get away with it.  How confused could people get with a login screen?

Well, it seems you can even mess up a login screen, if you get a little too clever.

The login form below uses placeholder text instead of labels.  The "name or email" is pretty clear.  And the use of dots, just like the ones that obscure your password from prying eyes is, too.  Isn't that cute?

Screenshot of login form with placeholder text being used as labels:

You click on the user name field and type in your name.  A very high percentage of users then think, "Oh, look, it remembered my password!" and click on the "Sign in" button.

Screenshot of login form, where the text for the first field has disappeared after selection, but the cute dots remain:

Of course the login fails, and your help desk is swamped with people who can't figure out why their password doesn't work.

If you come up with a very clever use of the placeholder feature, be sure you have some actual users do some testing, the ones who are just there to sign in, not admire how clever you are.  It's not good design if your users can't figure out how to use it correctly.

Further information on placeholder text:

Survival tips for accessibility leads

I received a request for some advice from a newly named Accessibility Lead for a government agency.  He said, "I am being asked to provide accessibility guidance on products / software I have never used before; and, in my opinion, this is a rather dangerous venture."  I knew exactly what he meant.  You feel like you are being asked to wave the magic accessibility wand over any old tech that happens to come along, while knowing that there is no magic.

This is what I told him.  If you are in the same position, I hope this helps you, too.

There is no way anybody can be an expert in every aspect of how to implement something accessibly in every technology.  I’m sure not!  So here are some survival tips.

  • Never claim to “know it all” or let others burden you with that.
    • Admitting that you don’t know everything gives you a lot more credibility.
    • It also leaves room to work cooperatively – let the devs, authors, etc. (“creators”) in on the discovery process and they will be more committed and learn more.  This is much preferable to a “dump it over the wall to the accessibility guy” approach, where it makes it look like you are the problem when issues are found.

  • The general principals are the same: Perceivable, Operable, Understandable, and Robust.  And the guidelines under them in WCAG2 track nicely to just about any technology area.  The actual implementation and authoring techniques are where things vary.

  • Always look to the technology provider (software vendor, for instance) for implementation guidance.  Look for their white papers or developer guides that address accessible implementation/configuration. If it’s not on their website, the creators need to contact the provider to get it (or to let them know that it’s important.)
    • Your creators should have found and been using these before they come to you.  If they didn’t, send them back to find it, compare the guidance with what they have done, and make needed changes before they return.

  • There may not be tools like we have for web-based technologies (accessibility checkers, code inspection tools) so you may end up having to do testing just with AT: screen readers, magnifiers, and speech recognition.  It takes longer and you’re more likely (as a human) to miss things.
    • QA discipline is your friend here.  Identify a matrix of AT, platforms, and browsers (when applicable) that you need to test on to find source errors (versus AT bugs) and write formal test scripts.
    • Involve the creators in testing so they can learn how to do at least some of it themselves, and so they understand the actual problem.
    • Get Actual Users to do testing, too, as a reality check and to prioritize the severity of any issues found.


When Dave was a toddler, I would sometimes tell him stories at bedtime.  It was a good way to get him to settle down: no lights on, like you need for reading.

I don't remember many of those stories. There was a series about Bob (because he bobbed on the water) the (magic) golden sailboat and David and their ocean and harbor adventures. There was a whale with a deep slow voice and a hyperactive dolphin named Joy and a storm or two. About when the underwater city with its underwater inhabitants came around, the story sort of petered out.

One night, I couldn't come up with a story. No main character, no plot, no moral - I just drew a blank. But at that age, Dave was mad about trains, and it was winter. So I talked about the little trains and trolley cars that just went back and forth all through the storm, clearing the tracks inches at a time. And then about the train plows that come through after the storm, with their pointy noses sending up great wings of snow on either side, glinting and glowing in the sun, as they power down the long overland stretches of rail.

It was description, not story. It had a tiny lesson about getting things done by a big-bang approach, or by taking it little by little, but no judgment about which is better.  Did that even qualify as a "story"?  I didn't think so at the time; I rather thought I had wimped out that night.  But not Dave! To my surprise, he requested that story again and again, and remembers it still.

Hops in the Spring

Our hop plants loved the early warm weather we had. By mid-April, the first sprouts were already six to eight inches tall. They say you can eat them like asparagas, but such sacrilege would not be tolerated here.

Just a few weeks later, the first plants are already about three feet tall. We had set up the tripods last week, before the weekend's torrential rain. They doubled in size in that time! Plenty of other bines are appearing and doing their best to catch up to the earlier ones. As they grow, they reach for something to grow on. When they do, they start growing in a spiral aorund it. They don't have tendrils to hold on with, like vines do, but they do have hard nubs to give them a little traction.

They grow very quickly once they start climbing. They'll reach beyond the tripods by next week, so we're now rigging a trellis with rope, twine, a two-by-four and an old flag pole, and a hub cap. This has been used succesfully before. Really!

Once all the ropes are attached on the other side, to various bits of our house, we'll hoist the hub cap up the flag pole and pull it across, where the bits of twine tied to it and the ropes will dangle down in reach of the growing bines.

Sunday Morning Country with Sparrows

Every Sunday from 10 a.m. to 2 p.m., we listen to Sunday Morning Country on Boston College's radio station, WZBC (90.3FM, streaming at hosted by the incomparable Cousin Kate. That's what you're hearing in the background. The sparrows were very excited because we had just refilled the birdfeeder. It was mesmerizing to watch them swoop in and out, sometimes singly, sometimes en masse, seemingly in time to the music.

Early Fall In the West

Jon and I took a little jaunt to see the Rocky Mountains. We had a blast! When we came back, Jon wrote a narrative of our adventures, and then I added more pictures - selecting only the best of the thousands I took. The daily narratives are on Jon's blog and the pictures are on this blog, but here's a list of all the bits and pieces, for your convenience.