Labels

[michaelspellacy]

Gang,

@JakeRuef and I are are looking to come up with best practices surrounding the use of labels. We all know they should be included in forms, but are often not seen as aesthetically pleasing and are therefore not included. Would love a lengthy conversation here on the matter. :-)

[viciouskitten]

I include labels but then do something like:

label { text-indent: -999999px; position: absolute; }

or left: -9999999px;

That way they are still available to screen readers

[DrewRHill]

Like Hannah, we typically just add a “visually-hidden” class to it if the design doesn’t call for labels. Having them is good for 508 compliance, but also is a “value add” to our customers. Many are trying to diversify their workforce, including but not limited to reaching those with disabilities. Having a career site that works with screen readers is a huge bonus for those candidates and may make them more interested in working for a company who had the forethought to include it.

[JakeRuef]

So the web designer side of my brain says "sweet the developers have a fix for the whole disabilities issue with not including labels. Now my designs can be clean and sexy" but then the ux side of my brain (that has been infiltrated by Luke W and co.) says "wait there are a lot of other issues to take into account than just giving ther ability for screen readers to be happy." It's a constant battle but as much of a right-brained person that i truly am, numbers and logic always get me.

I can include multiple links to great stories and videos speaking about this subject but what it all boils down to is that people who design for the web can't forget that there are a large majority of users out there that are not as internet-savvy as we'd like to believe. I mena i can't really think of any time i've ran into an issue with inline labels, but i also havent really been paying attention to whether anyting ive filled out had inline labels or not. But no matter how familiar you are with surfing the web, a luke w phrase (or maybe it was brad frost?) stuck with me after seeing them speak last summer..."obvious always wins".

When it comes to forms, not having a label can cause a lot of issues that we may not think about like: if you start filling out the fields, you now have no way of knowing what the field was for except for looking at what you typed in the box. True, but im sure we have all taken a standardized test with those little bubbles and got a bunch of questions wrong because we skipped a question and the follwing answers were just one line off. Also, there is the whole thing about having suggestions in the field makes it look like the fields are completed to some people and if you "ghost" them out to differntiate them from an actual answer, it can make it difficult to read to people with poor eye sight. The list goes on and on...

Spell and I discussed the thought of inline labels being more of a case by case basis, agreeing that for a simple search field it may be perfectly fine for inline labels, but when it comes to something like a job alert module, we need to make sure they are always there. And just because, i'll slap some of those links below this novel i just wrote incase anyone wants to read more. :D

http://www.uxmatters.com/mt/archives/2013/02/dont-put-labels-inside-text-boxes-unless-youre-luke-w.php

http://www.lukew.com/ff/entry.asp?1502

http://uxmovement.com/forms/faster-with-top-aligned-labels/

* interesting solution * http://uxmovement.com/forms/why-infield-top-aligned-form-labels-are-quickest-to-scan/

[michaelspellacy]

Thanks. Yes, I understand the techniques, but here is what I wrestle with:

1. Using a technique like this might be acceptable on, say, a single input field (as it is only call to action), but what about multiple fields (Keyword, Location, Radius, etc.)? Is it truly right to hide then?
2. If labels are that important to the blind, might all users benefit from them? We all know that placeholder text used to substitute labels is wrong, so why not include labels for sighted users as well? Because they are not aesthetically pleasing? That seems a bit irresponsible to me. I'm sure that people who are not blind and who suffer from low-vision might appreciate a label. ;-)

We build job sites, right? All of our clients are "Equal Opportunity Employers", right? That journey to employment within these companies starts with us, so I feel that we are obligated to ensure that we are catering to the needs of all potential job candidates no matter the disability or device they are using. My concern here is that we ultimately risk harming a client's brand when we do not attempt to be all-inclusive designers and developers.

Ah, such moral dilemmas, but it keeps the job interesting. :-)

[michaelspellacy]

"Obvious always wins" Boom! And it was Luke who said it. :-)

[JakeRuef]

Here's a great article that is somewhat related to this argumetn as well.

http://uxmyths.com/post/115783813605/myth-34-simple-minimal

I would like to point out something own of our art directors noticed that i think is pretty funny...The very last bullet speaks out against the "hamburger icon" yet the site itself uses one...oops.

[viciouskitten]

There's always this! https://css-tricks.com/float-labels-css/

[JakeRuef]

I really dig a few of these solutions! most of them utilize javascript, is that something that could be an issue or do you guys feel like te majority of these solutions could work?

[viciouskitten]

I've played around with pure css ones and they've been really cool

[viciouskitten]

I guess it depends on what you need to achieve. I've never needed js for them but there may be use cases when you do

[JakeRuef]

awesome. The one thing that i'm worried about is that, i've had numerous conversations with people about how we really should avoid styling form elements. Reasons being:

1- Styling do not always load on mobile devices. 2- the idea that we want to create a more consistent expereicne across the internet by always using default form fields and form elements.

I've spent a lot of time explaing and trying to convince creative that this is a best practice, but with these solutions, it seems contridicting to all the debates, rules and stories i've read on the subject. Any thoughts on this? I'd love to be able to offer solutions like the ones from this site to creative but i also dont want to keep flip-flopping on this matter...

[viciouskitten]

This is an article by Brad Frost where he talks about the pros and cons of using them. I think in general his view seems to be mostly positive.

Having not spent a huge amount of time on them and only using them in personal projects I unfortunately don't know whether they are the best solution or not. However I think that for when the designer wants to have hidden labels and we want to encourage having labels this could be the perfect compromise. They could work in the right project. It's definitely better than omitting labels completely and also means that once you click/tab to an input you can still see what it was for. They should be fairly lightweight if you don't use js too.

http://bradfrost.com/blog/post/float-label-pattern/

[viciouskitten]

I think consistency in design is important and across devices however if styling doesn't work this will default to a normal looking label/input in my experience - there are certainly ways to ensure this either way. I also believe there are instances where styling should change depending on the viewport/device and that this isn't a bad thing. We shouldn't compromise UX for something that might work on a desktop but clearly doesn't on a smaller device.

So if the styling didn't work for the smaller device maybe it would be the point to bring back traditional labels in the design

[JakeRuef]

Agreed. (the following is me chanelling my inner spell philosphical-ness and by all means isn't meant to be an angry rant lol)

This is exactly why Spell and i have been having these conversations and brought it to github. Being the UX guy at TMP puts me in a difficult position. I'm trying to help find that happy balance between development/best practices/creative freedom. And with having the different departments spread out across the US (and globaly) as well as our history of working in a more siloed "assembly line" way (which we are trying to change) it's difficult for my fellow left-brained coworkers and right-brained coworkers to see eachother's efforts as one team workingn together to provide the best solutions without feeling like the other is limiting their options or making their work extremely difficult.

I've totally accepted and am completey ok with never being able to say officially that this is the one and only way to do things, but I really want to try and come up with a range of options to help allow for customization within reason. This way the art directors can keep being creative witout sacrificing perfromance and in turn keep from making devolopers and UX team memebers lives difficult.

I've notice a shift in the creative team's frustrations since providing them with more reasoning/statistics/testing/information around some of these best practices, but also know that there is a limit to how much we can restrict the ability to push the boundries.

[michaelspellacy]

Styling do not always load on mobile devices.

There are exceptions, @JakeRuef. <input>, <textarea> (not the scroll bars, though), <label> are usually pretty safe with styling, but if they don't look 100% consistent cross-browser then it is okay. When you embrace progressive enhancement, you accept this. As a matter of fact, you can't work in web design if you are not willing to accept this principle (clients need to embrace it, too) . Brand consistency is certainly important, and for the most part we don't usually have trouble now that browsers do support (most) standards, but when they don't, we should not lose sleep over it anymore (those days will die with IE8). :-)

<select> dropdowns are a pain in the ass, so we generally try to stay away from styling them (iframe and div overflow scroll bars are also troublesome here), but only because tactics involved usually involve scripting and complexity we don't need to impose on the experience (or ourselves in form of additional maintenance). When you are trying to balance good performance into the mix, it is easy to say, "We don't need to style these".

We also need to be sensitive to common defaults at times. For example, if most websites don't typically style up their forms, could we potentially be introducing complexity to the end user when we do decide to style them up? Probably an edge case, but it does give one pause.

[michaelspellacy]

I've notice a shift in the creative team's frustrations since providing them with more reasoning/statistics/testing/information around some of these best practices, but also know that there is a limit to how much we can restrict the ability to push the boundries.

@JakeRuef , Why is it easier coming from you when we have been attempting to explain many of the same things to them for years? Do I have to be a designer to get through? I always considered myself a designer at heart.I just design with code. :-)

[michaelspellacy]

So if the styling didn't work for the smaller device maybe it would be the point to bring back traditional labels in the design

@viciouskitten We should not be be bending over backwards to achieve brand/design parity cross-device. If we can get things looking fine in the majority of browsers, then we done good. Again, most of the time it won't be an issue, but embracing progressive enhancement and allowing the experience to degrade on those non-supporting devices is totally fine! :-)

http://dowebsitesneedtolookexactlythesameineverybrowser.com/

[viciouskitten]

I agree. I don't think they should look the same because people aren't necessarily looking for the same information either. As long as nothing is being hidden!

[michaelspellacy]

Yeaup!

[Brockenstein]

There was an old email conversation about this an one of the solutions posed was this http://codepen.io/cb4430/pen/ONJdjd