Better Passwords #3: Caps-lock Warnings

So far, I’ve looked at two possible solutions for improving the usability of password fields; of those, the second idea–adding a “show password” checkbox that converts the field to plain text–was vastly more popular than the first (creating iPhone-like “masked password” fields).

Overall, it seems the show-password approach is much simpler and direct, more meaningful to users, and solves the original problem better. But it’s n0t perfect, since it comes with usability issues of its own (according to how it’s implemented, as we saw).

More importantly, a problem with both ideas is that they have the potential to increase the risk of showing your password on the screen. Even though it’s only by user action, both expose some or all of your password to plain-text view, and that’s just a reality of what they do. Yet, that’s what started this issue in the first place!

Perhaps we just have to accept that the solution gives rise to the problem again, and passwords simply need to be obfuscated whenever they’re shown on the screen. We could go the other way and stop obfuscating passwords entirely, living with the consequences as some have advocated; personally, I’d find that hard to stomach.

With all that in mind, I have one more idea that doesn’t attempt to solve so complete a problem; it just addresses one specific and common user error. You’ll almost certainly have seen this before, in the primary user login field in most operating systems.

Caps-lock Warnings

The idea is simply that a warning is shown when the user types into a password field with caps-lock enabled. It might be a textual warning, or an icon of some kind. It’s a simple addition to password-field usability that protects against entering unintended capitals.


A login form with a caps-lock warning icon

This behavior is in fact already implemented in Mac/WebKit browsers such as Safari. So, I’m going to show you a script that adds it to all browsers’ "password" fields in a clean and progressive-enhancement way.

Have a look at the demo, and grab a copy of the script:

How the Script Works

First and foremost, we have to to create the warning element itself. This is simply an HTML <strong> element with a specified class name, and with a short message text that’s also duplicated to its title.

In this case, the message just says Caps-Lock is ON!; it’s styled so that the text is not visible, with only a small icon superimposed over the right-hand side of the input. It’s almost the same icon that’s used natively in Mac/WebKit browsers (and works in harmony with that existing functionality), so it will already be familiar to some.

It’s precisely so it can be styled in this way, that it has a tooltip as well as the text (the script copies the tooltip from the text). If you prefer, you can make it more visually obvious by showing the text as well; the demo includes some alternative styling you might like to try.

Ultimately then, the script converts markup like this:

<label for="pword">Password:</label>
<input type="password" id="pword" name="pword" />

… to markup like this:

<label for="pword">Password:</label>
<span>
    <input type="password" id="pword" name="pword" />
    <strong class="capslock-warning" title="Caps-lock is ON!"
         style="display:none;">
         Caps-lock is ON!
     </strong>
</span>

As you can see, the warning element is hidden by default using display. The only other job of the script then is to show and hide that warning when appropriate.

Detecting Caps-lock

It’s actually not possible to directly detect whether caps lock is enabled. In some browsers we can detect key events on the caps-lock key itself, but for that to be useful we’d have to know whether it was enabled or disabled in the first place–which we’re unable to!

We can, however, indirectly infer the use of caps lock by the input data we receive onkeypress; essentially: IF the input character is an uppercase letter A to Z, AND the Shift key is not pressed, THEN we can deduce the use of caps lock.

Given that situation, we show the warning element.

From that position, we can then infer that the next press on the caps-lock key itself is disabling caps lock, so we can go ahead and hide the warning. Not all browsers report this event (for example, Opera and WebKit browsers), but it’s inessential functionality, just an extra touch.

The final bit of housekeeping is to routinely hide the warning element if it’s visible when the password field loses focus.

Enchante

And that’s it! A really simple script for a really simple job. It fails to solve the password-obfuscation problem, but neither does it create any issues of its own.

Thumbnail credit: 123 Chroma Pixels

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • http://www.idoe.be/ GeertDD

    You could also add the opposite check: if the input character is a lowercase letter and the shift key is pressed, then caps-lock is enabled. Helpful for people who use uppercase characters in their password.

  • dylanstip

    Doesn’t seem to work with chrome stable on windows, works nicely in firefox 3.6

  • Daniel Sellers

    Should probably check both the way mentioned in the article and the way that @GeertDD mentioned above. Otherwise users who push shift for first character will not get the warning…

  • James Asher

    I wrote something like this a while ago, back in 2007 in fact, using the Ext JS Framework. I put it together after reading a 24 Ways article about detecting Caps Lock.

    You can see the post here if you’re interested: http://17thdegree.com/archives/2007/12/06/capturing-caps-lock-with-the-ext-js-framework/

  • http://www.magain.com/ Matthew Magain

    James you are a marvel. Great stuff.

  • http://twitter.com/adammessinger Adam Messinger

    The demo and download are 404ing. Is this still available somewhere?