Labelmask

Labelmask

I’ve recently been for more efficient ways for user inputs, especially around credit card input. In exploring using input mask solutions, a lot of people have weighed in on several important limitations/frustrations:

  • Accessibilty–One of the biggest concerns with input masks is that they’re pretty terrible for screen reader users. This video demonstrates that pretty clearly.
  • Distracting–Quite a few people have expressed frustration with input masks, as they move things around while they’re trying to input data. Because the input is simultaneously trying to be an input and a formatted display, it can lead to some weird shifting around that some people feel gets in the way of the task at hand.
  • Mystery behavior–I know I’m not a huge fan when I have to guess the behavior of a form field. Is this going to auto-advance? Will I have to hit tab? I don’t know! Messing with the default behavior of form inputs could lead to confusion.
  • Copying/Pasting, auto-fill, etc– Some input-masked solutions (granted it could just be an implementation issue) struggle with browser auto-fill solutions and copying/pasting.

Yesterday, the Filament Group released a nice little script called Politespace, which provides an alternative for input masking. Basically, Politespace adds spacing for input fields when the user exits the field, rather than trying to add that formatting while the user is trying to input data.

I really like this solution, however a lot of input masks’ benefits come from guiding the user while they are entering their information. So while I think Politespace is definitely great for reviewing data once it’s already entered, I wanted to explore ways to make the input process a little easier for users without having to rely on an input mask.

Labelmask

I stole Politespace’s code (thanks Zach!) and hacked it up to create a proof of concept.

What Labelmask does is inserts formatting hinting after the label, and updates as the user inputs their information. When the user leaves the field the formatting gets applied to the input value itself, Politespace-style.

Because the hinting isn’t being applied to the input itself, (I’m hoping) it’s more accessible to screen readers and doesn’t get in the way of the user’s input as much.

Wishlist

  • Proper development – I wouldn’t ever dare call myself a JavaScript developer. The demo I put together is merely a proof of concept, rather than a done-and-dusted solution. I’d love to see people develop it for real. The code is on Github if you want to take a look.
  • Roll in validation–It would be great if the script could let the user know when they’ve entered a valid credit card number, phone number, or whatever. This could be a simple color change, checkmark, or some other indicator that they’ve successfully entered their information.
  • More flexible destinations–Labels seem like a good place for the labelmask hinting, but it could easily go in a note after the input.
  • Optional label hiding–Especially on small screens, there might not be enough room to comfortably display the label and the labelmask hinting at the same time, so perhaps there could be an option to temporarily hide the label text while in focus.

You can view a demo here or check out the project on Github. All in all, I think it’s a pretty good balance between accessibility and unobtrusiveness. Curious to hear people’s thoughts!

16 Comments

  1. Joey Brennan

    I’m excited to see the progress of this. Keep it up good sir!

  2. Penny

    Love the thoughts here… but I’m a bit confused at the necessity of input formatting — why the need to style the inputs at all? Is this purely for design reasons?

    I think this still inadvertently implies a formatting requirement – i.e. on blur, the element “corrects” itself. For all the usability reasons you mentioned above, why can’t the input simply stay how the user entered it? Take a phone number, for example: why can’t a user enter 123-456-78901 or (123)456-78901 or 12345678901? The backend is easily smart enough to validate and accept any of those values. Perhaps I’m missing the point here? Cheers.

  3. Ronan Costello

    Great progress. I like it!

    I’m not sure there would be as much of a space issue on smaller screens. I suppose that would depend on the length of the labelmask but for a lot of inputs I think you would be ok. It would be great to see this tested though.

    I too would like to see some validation as you mentioned. Great progress though, I’m enjoying watching this one develop.

  4. Jordan Dobson

    I think the one issue I have with your demo is that the placeholder suggests entering in the “-” in the phone number and then fails to render it afterwards correctly. typing 555-555-5555 ends up converting to “555–55-5-5555”. Yuk.

    Ideally you wouldn’t have to worry about the format in the field and the labelmask would show you how it understands your entry currently or you handle it after you have a “successful” entry.

    I did something similar in a proof of concept here with the phone number: http://cl.ly/VAVg

    * Beware the prototype is for webkit browsers only. It’s also in a modal… boo!

    • Brad Frost

      Yeah, maybe it isn’t obvious that it’s a proof of concept, but ultimately all the input logic would be in place so that users wouldn’t have to worry about the dashes and formatting.

  5. Ibrahim Nergiz

    I guess, found a bug 🙂

    https://vimeo.com/92815190

    with pass: Labelmask

  6. Tom

    I like this. The only issue I’m seeing is that the ‘helper’ label disappears after I click outside of the field I’m typing in, but I haven’t yet matched the pattern. For example, say I only type the first three numbers of my phone number, click outside of the field, then click back in to finish typing, the helper is gone and I have to delete what I’ve already typed to see the pattern again. It’d be nice if the helper label is always there when my cursor is focused and until what I’ve typed matches the pattern.

  7. Tim Severien

    A fantastic concept, I love it! The experience is a little weird because I’m used to the dodgy input that moves my cursor around, but I could totally get used to this.

  8. Chirayu Dalwadi

    One thing I noticed was that when focus is on tel textbox, when I click some other application additional ‘-‘ is added.

  9. Eric Eggert

    Unfortunately when the credit card placeholder is in the field it actually gets read as “exexexexexexexexexex” in screen readers which is quite unpleasant. This happens again when the placeholder text is added to the label, further changes are not announced. (But this can be switched off by using aria-hidden, I think.)

    Did just a quick test with VO on iOS.

  10. pinkbigmac

    Agree with @Jordan… but anyway good thought

  11. Travis Miller

    Pretty dope good sir!

  12. Gaurav Mishra

    Thank you!

  13. Jon Humphrey

    Brad,
    Great work on this PoC … now I get to spend the morning forking the code! 😀

  14. Ara Pehlivanian

    I’d love to help with this. I’d previously written an input masker (http://typecast.arapehlivanian.com/) and was rewriting it but I find your approach better.

  15. David Mead

    Really like the look of this Brad.

    Are the ‘data-‘ attributes one’s you’ve made up as part of the custom data attributes in HTML5? Just for this use?

Comments are closed for this post. If you've got something to add, feel free to reach out on Twitter.