Better Passwords #3: Caps-lock Warnings

    James Edwards

    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>
        <input type="password" id="pword" name="pword" />
        <strong class="capslock-warning" title="Caps-lock is ON!"
             Caps-lock is ON!

    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.


    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