Dear Gravity Forms, ((I’m writing this as an open letter in the spirit of open source. I hope that sharing this publicly effectively communicates with the Gravity Forms developers and also informs other website builders.))
As one of the best and most important paid plugins in my WordPress development toolbox, Gravity Forms has helped me for years because it makes building powerful websites for my clients immensely easier. Without doubt, the reputation of Gravity Forms as one of—if not the—best WordPress plugins is well deserved.
I write with concerns regarding a feature in the upcoming version of Gravity Forms that will make many websites less accessible and usable. By allowing—even encouraging—users to hide form field labels from screen readers and replace them with placeholder text, visually impaired users will find more forms on the web impossible to use, and the usability of many forms will decrease for all. Hiding form labels is not an option that should be left to website owners uniformed of the accessibility and usability ramifications of making such a choice.
I hope that this letter will lead you to rethink version 1.9’s approach toward form label and placeholder settings.
Placeholders are not an Alternative to Labels
For those less familiar with HTML, understanding the label
element and placeholder
attribute will make this easier to understand.
The Label Element
Labels are an HTML element meant to accompany every form field. Here’s the HTML code for a text box and accompanying label.
<label for="email_field">Email:</label> <!-- the label for the text box -->
<input type="text" id="email_field"> <!-- the text box -->
Notice how they are explicitly associated by the for
and id
attributes so that computers can connect the label to the field.
The Placeholder Attribute
Placeholders are newer ((Placeholders are a feature new in HTML5 that an increasing number of browsers support. Previously, developers had to use often-buggy JavaScript implementations of this feature. Gravity Forms plans to use an HTML-only implementation.)) HTML attribute used to supplement the information from a label on a form field. Placeholders are specifically intended to provide an example value or formatting suggestion. ((The official definition from the HTML5 specification of the placeholder
attribute:
The
placeholder
attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. [emphasis added]
)) Here’s the same field with an appropriate placeholder value (shown above):
<label for="email_field">Email:</label> <!-- the label for the text box -->
<input type="text" id="email_field" placeholder="you@example.com"> <!-- the text box with a "placeholder" value -->
An Unfortunately Popular Practice: Placeholders as Labels
Despite the distinct and complementary purposes for labels and placeholders, it has become popular to replace labels with placeholders in spite of the significant usability drawbacks and severe accessibility drawbacks. Here’s what that looks like:

I suspect this stems from a combination of ignorance of the problems caused by the practice and the increased design flexibility that comes from a more compact form field. This popularity builds on itself and probably leads many Gravity Forms users to wish the feature was available as an option. But just because something is popular does not make it a good idea.
Gravity Forms 1.9 Will Make More Forms Inaccessible
In October 2014, Gravity Forms announced the addition of placeholders in version 1.9 and the accompanying ability to hide a field’s label. That announcement specifically mentioned the popular but problematic practice of replacing a label with a placeholder:
It’s not uncommon for people to present a simple form by only using placeholders and without any additional UI such as the Field Labels or Sub-Labels. That is most definitely possible with the new placeholder functionality in Gravity Forms.
It is the decision to add these features in tandem that I hope Gravity Forms will reconsider as the current implementation encourages users to make bad decisions and inaccessible forms.
I put together some screenshots highlighting the new settings:
Labels Are Required for Accessibility & Usability
Labels are essential to make a website accessible to screen reader users. Screen readers are software that help people hear a website rather than look at it. They’re how users with visual impairments can access a website. Here’s a short video example of a screen reader announcing a web form and its fields.
Without a label, screen reader users have no way to know what to enter in a form field. When using a form, a screen reader might say (paraphrased), “A text input with the label ‘Email.'” Without it, a screen reader can only say “A text input.” That means an input without a label is useless to a screen reader user.
Labels are important not only for accessibility to screen readers but usability for all website visitors. Many such problems caused by missing labels or misused placeholders are described in Nielsen Norman Group’s article “Placeholders in Form Fields Are Harmful:”
Placeholder text within a form field makes it difficult for people to remember what information belongs in a field, and to check for and fix errors. It also poses additional burdens for users with visual and cognitive impairments.
Because placeholders disappear when a form field is filled in, a user must remember the field’s intended purpose once they start filling out the form, adding to the user’s “cognitive load.” ((Think of cognitive load as the scientific reason behind the “Don’t Make Me Think” principle. Interacting with a web page has an inherent load (i.e. “requires at least a little thinking”), but each new feature and design element can impact that load.))
What’s more, some users confuse placeholders with default values that don’t require their action or try to select the placeholder text (which is impossible), presumably to replace it with their own value. Over time, more and more users will figure out how placeholders work, but I suspect that many users are still confused by them.
Finally, when using a placeholder without a label, over 10% of users cannot see anything because their browsers do not support placeholders! ((I’m particularly surprised by this last fact, since Gravity Forms explicitly acknowledged waiting for sufficient native browser support before adding this placeholder setting:
We originally wanted to use a pure HTML5 approach with no additional javascript but that meant waiting until placeholder browser support was available across the board. Once browser support was there we had to fit it into our internal development roadmap.
I don’t consider 13% to be low enough to provide this feature with no fallback if it can be used to completely replace labels.))
Gravity Forms Should Follow the WordPress Philosophy of “Decisions Not Options”
These two new features allow any form editor—particularly one less familiar with accessibility and usability standards and best practices—to hide a field’s label, making that form inaccessible to all screen reader users and harder to use for all users. (The new settings even make it possible to create a field with no label or placeholder, as pictured in the 4th screenshot above!)
This very much violates the popular WordPress mantra of “decisions, not options:”
Every time you give a user an option, you are asking them to make a decision…Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users. [emphasis added]
I believe the distinction between labels and placeholders—and the appropriate usage of each—are clearly technical decisions requiring significant-enough background knowledge that they should not be left up to the average Gravity Forms user. What’s worse, I fear that Gravity Forms’ endorsement of this practice may actually make people believe that the practice isn’t merely possible but acceptable.
There may be limited edge-case scenarios ((One such case is showing a site’s search field with only a magnifying glass icon or “search” button. Notably, this and similar forms are almost never built using Gravity Forms.)) where an accessibly hidden label is appropriate; however, these cases can be easily handled by any developer that competently understands the ramifications of that decision.
Please Reconsider
The addition of a placeholder text setting is positive overall, and I applaud its careful inclusion in Gravity Forms; however, placeholders and labels are only accessible and usable ((Placeholder text “gracefully degrades” since it’s inessential so long as it is only used to provide auxiliary information about a form field.)) when implemented as intended.
I am not alone in this belief; I share it ((To be clear, these people and organizations have not endorsed this letter but have created resources explaining and advocating for the points made in it.)) with The Accessibility Project, WebAccessibility.com, The Baymard Institute, Sarah Horton, David A. Kennedy, Jeremy Keith, WebAxe, Wired Impact, Nielsen Norman Group, Coolfields Consulting, Paciello Group, Pardot, and countless other accessibility, usability, and HTML experts who believe form inputs should almost always have a visible label and should never rely solely on a placeholder to describe a form input.
In the feature’s announcement post, you wrote:
We tackled Placeholders the way we tackle everything we do here at Rocketgenius [ed note: The company that makes Gravity Forms]. Our goal is to produce the best product.
I strongly believe that “the best product,” does not include the placeholder and label features as currently implemented together. As one of the premier plugins for the content management system that powers more than 1 in 5 websites on the entire internet, Gravity Forms is important both as a technical tool and a role model to website visitors, WordPress users, and developers.
Because these new features have yet to be released and given the major drawbacks described above, I hope you will strongly consider revising Gravity Forms 1.9 to remove the ability to hide labels and ensure that your plugin users correctly use both the label
element and the placeholder
attribute.
Sincerely,
Mark Root-Wiley
MRW Web Design
Web Designer and Front end WordPress Developer
Followup (5 Jan 15, 11:45am PST): Gravity Forms Responds
Late this morning, Gravity Forms founder Carl Hancock responded to the bug report I filed regarding this issue:
Thanks for the feedback! We’ll take a look and see what we can do to make the feature more accessible friendly for situations where a user would be using a screen reader. If we’re not able to refine it enough so that it is still friendly for screen readers between now and the release later this month, we’ll put it from the final release.
I’m glad to hear they’re taking the accessibility issue seriously and hope that the broader usability issues will also be addressed.
Update (6 Jan 2015, 12:32pm PST): Placeholder as Label Explicitly Prohibited by HTML Specification
Somehow this slipped past me until today, but it should be noted that using a placeholder as a label is actually mentioned by and explicitly against the HTML5 specification:
The placeholder attribute should not be used as a replacement for a label.
Update (24 July 2015, 1:11pm PST): Two Improvements
Following this post, Gravity Forms eventually decided to hide this option by default in v1.9 and only allow it to be used on sites where a developer explicitly turned it on using code. I still believe the option shouldn’t exist, but as compromises go, I felt good about this one.
However, I did not test the final version of this feature and was very disappointed to learn that apparently Gravity Forms did not fix way the field was hidden until v1.9.12 on July 15! All progress is good progress, but the way this issue was handled very disappointing. I hope that over time, Gravity Forms will learn to:
- take accessibility-related reports more seriously and urgently, treating them as severe bugs rather than feature requests,
- incorporate better accessibility testing into their pre-release workflow,
- improve accessibility training and awareness among their design and development team to prevent issues like this in the first place.
Happy New Year Mark,
Great post as always. Clear explanation. I think as another long-time Developer license holder I will post a ticket with a link to your post. Any other thoughts on what can we do to help convince GF?
Happy New Year to you too, Sheila.
Thanks for taking the time to read this (it’s nearly 1700 words!) and comment. I submitted this as a bug to their Beta forum this morning, but I think others submitting it can’t hurt to show that people care. I’m hoping that posting this publicly will lead others to take notice and help urge GF to revise their plans.
I really appreciate your support!
Completely agree with your open letter, and thanks for referencing my blog post on this subject.
Making aesthetic decisions is what all web designers and developers do. Ditching labels because of an aesthetic decision will effectively shut out a fair proportion of people and make life difficult for others. Is that a good move if you’re building a site for a client selling their services or products?
Well put, Graham. My answer is a definitive “no!”
I DO NOT want the Gravity Forms dev team to remove those options again! Believe me, the WordPress mantra “decisions not options” is NOT ALWAYS helpful! A responsible user will decide for accessable forms, that’s my opinion. But please don’t remove options, a host of users fighted for years. The options itself are not good or bad. Only users can do good or bad things with them.
I don’t want WordPress end up with every possible option to be removed and end up in a filter – only to “hide” an option from the “average user”.
Don’t get me wrong: I totally get where you’re coming from and for sure I support websites and WP and plugins and all of that to be accessable! However, the solution in this case is NOT to remove options from the users. There must be alternative solutions for this!
David, thanks for your response! One of the reasons I wanted to publish this on my blog rather than just a private conversation with Gravity Forms was to get others involved, so I appreciate you weighing in.
The technical issue is that the “Hide Label” setting is implemented in a way that screen readers have no access to. That is a MAJOR accessibility issue, one that would be irresponsible to release. Based on the response I got yesterday, I believe that it will be fixed before release. That doesn’t get rid of the option but just changes its implementation.
The second issue is the wider usability issue. Research shows that hiding labels make forms harder to use for everyone, particularly for people with certain cognitive impairments (meaning that the “usability” issue here isn’t just one of convenience). This is certainly worse for longer or more complex forms. I don’t think I’ve ever seen a usability expert argue that this belief is wrong. What’s more, as I just noted at the bottom of the post, replacing labels with placeholders actually goes explicitly against the HTML5 specification. That’s why, if it were up to me, hiding labels would not be an option at all. I think that the placement of labels has usability impacts but can be fudged by designers who understand the drawbacks. I’m less convinced that hiding labels completely is a decision that should be left open to opinions and, therefore, settings.
I don’t think there’s anything wrong with the new placeholder setting in it self (I look forward to it, in fact), I just think that it’s ripe for abuse by people who don’t know better, and that’s why I brought in the “decisions, not options” mantra. I completely agree with you that “d not o” is not an absolute maxim (in fact, for a while I felt it was being overused). However, in this case, I think that despite the seemingly simple settings we’re talking about, the *appropriate* use of them requires more accessibility and usability knowledge than most Gravity Forms users possess.
Finally, I want to note that I’m writing this now so that if any features are “removed,” they are done so during the beta phase of 1.9 before most people would actually “lose” anything. 1.9 will be a net gain either way.
I hope that at least clarifies where I’m coming from and the various options I see for moving forward.
Please forgive a relative newbie question (I’m a tweaker, not a programmer) but if the field label is HIDDEN, should it not still EXIST in the page source? Why is it not possible to make the text invisible but still machine-readable?
And as an alternative option, do you know how to place the label itself inside the form field?
Good questions.
You are correct that a label can be accessibly hidden so it does not visibly appear but is announced to screen readers. Gravity Forms eventually changed their feature to do this (thought it was done incorrectly when this was first published). However, it is generally considered bad practice to hide labels at all, hence the placement of the feature behind a developer-enabled option.
To answer your second question: This is possible with CSS but would need to be done custom for your site. One common pattern is the “float label”. Here’s an example that at least claims to be accessible (I haven’t tested it and that doesn’t mean it’s a good idea!) http://codepen.io/AllThingsSmitty/pen/VjykOz
The whole idea of making it easier for the least experienced users to hide labels seems like a major problem to me. Experienced developers can always hide labels from a stylesheet with nominal effort, and they will; this can’t be stopped or prevented by a plug-in. But inexperienced developers and non-developer users should be limited from being able to make the same mistake because it’s built into the plug-in.
What’s the point of building in a mechanism that explicitly allows people who don’t know any better to break the accessibility of a form?
Thanks for framing it that way, Joe. I found the roll-out of the feature just as concerning (maybe even more so) that the new settings themselves. Even though it’s technically possible to use placeholders well, I suspect the negative use will greatly outweigh the positive when these features are released.
Seems like it could still be a good option, if a tooltip or something is included to not only point out that it’s not recommended, but WHY it isn’t recommended. Then any user, experience or not, would be able to make a well-educated decision.
Great post. I’m using the latest version of Gravity Form (1.9.3) and the option to hide the labels has been removed.
Thanks, @dabesa. Right now the settings are hidden behind a new filter in Gravity Forms that’s set to
false
by default. I’m hopefully it’ll stay that way. Given the circumstances, that seems like a good compromise.Here is a solution: use css so form labels are absolutely positioned 10000 pixels to the left (or any huge number). screen readers will still read them out as though nothing had ever happened, yet visual users will never see the labels. Placeholders can then be used within the fields so the form still looks nice to the visual users. I am all ears if anyone wishes to tell me why this method cannot be used – especially the person who originally wrote the letter of concern to the gravity forms team. I am not saying that to be self righteous – I actually want to know from knowledgeable people why I cannot do this, as it is what I plan to do if noone can put up a good reason to state otherwise.
ps. the “post comment” form on the bottom of this website has placeholder text with no labels. haha..
The position:absolute; left:-9999px (or similar) solution does work but only for LTR languages, and can also cause focus issues within some mobile browsers when used with Voiceover (on iOS) or Talkback (on Android).
A more modern solution employs clip and width and height and is used by WordPress core and default themes now. The full definition is:
clip: rect(1px, 1px, 1px, 1px);
height: 1px;
width: 1px;
overflow: hidden;
position: absolute !important;
This solution solves the issue for screen readers, but doesn’t address the other issue around placeholders for sighted users. Accessibility is not just about blind people.
good discussion – could I ask for some clarifications? Excuse my ignorance and not trying to argue – I want to know so I can flesh this solution out.
a) what kind of focus issues are you saying? As the absolute position is to the left (or the right is possible) then it is horizontally level with its intended original position, so from a vertical scrolling point of view there is no difference, but in terms of focus what are you saying would happen?
b) When you say LTR languages could you explain what would happen in a language that was otherwise? If it is out of view it is out of view and no language type is ever going to bring it into view, or change the vertical scrolling equivalent position so I am missing something here no doubt – pls clarify?
c) Your clip solution sounds good, but then you say “it doesnt address the other issue around placeholders” – sorry what other issue?
d) When you say accessibility is not just about blind people – I guess you could expand that to say some people might be colorblind, but not actually blind as such, or others may even be blind and deaf as well, resulting in a braille reader, but other than that, who else? It is difficult to ask such questions without sounding politically incorrect or insensitive so apologies for that, but I seek to know what you are saying on these various matters and appreciate your time if you do reply.
Tail between my legs on the comment form, everyone. Thanks for letting me know. I’ll file a bug report upstream!
Graham shared my preferred .screen-reader-text class. It doesn’t mess with the focus outline or some the mobile issues he alludes to.
As for the other issues, you should really read the full Nielsen-Norman Group linked above: http://www.nngroup.com/articles/form-design-placeholders/ It lists many of the usability and accessibility problems associated with placeholders without labels. (Remember that placeholders were not intended to be labels, but rather hints about the expected value of the form field.)
Here’s another great [new!] article about all the issues around placeholders including issues around visual, cognitive, and motor impairments.
Regarding all the types of accessibility, the articles on WebAIM.org are a great place to start.
But yes there is an irony that the comments box has a placeholder and no label.