Insert a label node with Javascript when no label if found

[timohofmeijer]

I didn't want to add unnecessary label node thus made a small tweak which inserts them when needed. My case was a login screen with just placeholders and no labels. The height and margin settings are to ensure the layout stays unchanged when label-nodes have been inserted.

[ginader]

Hi Timo,
while I appreciate the work you invested i have to say I can't disagree more with your reason and the result.

The reason why my polyfill does require labels is not a technical limitation - it is by design and fully intentional.
No input or textarea element should ever be without a label. It is a massive accessibility issue to not have a good label on a textfield.

Instead of investing all this time to work around my polyfill I recommend simply adding labels to your form fields. If your design does not allow visible labels I recommend to hide them offscreen with this technique:

Add the class .visuallyhidden-with-placeholder to the label you want to hide

the CSS needed already comes with the polyfill:
https://github.com/ginader/HTML5-placeholder-polyfill/blob/master/src/placeholder_polyfill.css#L26

Please understand that I won't accept you pull request for the reasons mentioned above.

thank you

Dirk

[yellowled]

I'm with @ginader on this – there's no such thing as an “unnecessary label”.

You don't even need to think of screen readers (although you should), just imagine a checkbox or radio button without a label. Even a sighted user wouldn't know what is checked or selected by selecting that particular form element. There could be surrounding text which would explain it, but a label is always directly associated with one form element via an id.

It is perfectly fine to hide labels for design purposes, though. Just make sure you use a technique which does not hide it from screen readers (like the one recommended by Dirk).

[codepo8]

Same here - labels do not only make form fields more useful to assistive technology but makes it easier for everybody else, too. Consider a checkbox - when you add a label you can click/touch the text next to it to check/uncheck instead of having to hit the much smaller checkbox. Use your phone on a train and you'd start to love that feature.

[norm]

Also agree with @ginader – I'm a firm believer that JavaScript libraries should require rather than encourage correct source code (whilst a form element without a label is technically valid HTML, it is not correct HTML by real world needs).

[MoritzGiessmann]

+1. Labels are necessary for every input.

[yatil]

Labels are the default, they are meant to be associated to every form control (except buttons), to give them meaning. Creating them through JavaScript means that you don't have a good fallback if your Internet connection goes away and JavaScript isn't loaded. Plus: This polyfill poly fills the placeholder. If JS goes away, and there is no placeholder support, your users are left without any instructions at all. Leave the form elements visible, hide them when the JavaScript loads (with the class @ginader mentioned). Every user, no matter what combination will be happy this way.

[nefarioustim]

Jumping on the bandwagon. +1 for label win. Accessibility is not a bolt-on; it needs to be built in from the outset.

[timohofmeijer]

I fully agree with your arguments when it concerns traditional websites but I think they are outdated and invalid when concerning applications. 🎱

[codepo8]

Timohofmeijer so basic usability aids don't make any sense any longer as soon as you call something an app? How does that work? The larger touch target I mentioned very much helps on mobile devices, and iOS comes with a screen reader out of the box. Sounds like a catch-all excuse to me.

[yatil]

@timohofmeijer What are the reasons for that? And what is a web application anyways? A bunch of post requests. Like every comment on a wordpress blog. The basic rules of best practices web design apply everywhere. Instead of investing the time to rewrite scripts to accommodate your bad HTML, you could just invested the time to add those damn two label elements. And drink a coffee, and read a good book about progressive enhancement (for example: http://easy-readers.net/books/adaptive-web-design/).

Tim Berners-Lee (@timbl, and the inventor of the web) envisioned the web as open and accessible for everyone, no matter where they comes from, what speed their connection is, how capable their browsers are or how good their eyes or hands or both work. I feel pride every day to make that vision reality, and it is the job of web developers to make it a reality.

(BTW: It’s funny we have that discussion on Blue Beanie Day. And by funny, I mean sad.)

[ginader]

@timohofmeijer how on earth can usability ever be outdated? Do you really want to explicitly exclude users from your app? What is your reason to NOT add labels other than being too lazy which you are obviously not? You know what they're for and you now know how to use them the way so it matches your design so please do the right thing!

Happy blue beanie day. (If you don't know what that is then look it up — It will make you a better web dev.)

[timohofmeijer]

; )

[luksak]

I think the discussion whether including a label or not is a usability issue that shouldn't affect this plugin. A input field without a label is valid HTML. So if the intention of this plugin is to support valid HTML, this should be implemented. Personally, I always include labels for my input fields. But I was just debugging my Drupal website where one input field didn't have a label and I can't see anything in the requirements of this plugin that there has to be a label. So, either way it's a documentation issue or a lack of support for HTML.

[yatil]

Sorry, @luksak, as you can’t properly use a input field without a label (except [type=submit] and [type=reset]), it isn’t a working website. Only because something is technically valid, doesn’t mean it makes any sense. Stick to best practices.

[luksak]

You can properly use a input field without a label. Anyway... I switched to https://github.com/mathiasbynens/jquery-placeholder already. It makes things much easier as it is much closer to the default HTML placeholder behavior. And it does not assume any markup with labels or similar. It does just what it should do... provide placeholders and it does not review the accessibility of my markup ;) And best of all: it does not apply weird styles to the placeholders such as font-size: 75%; Why is this in this polyfill? There is not point in applying this style. But that's a different issue...