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:

1. take accessibility-related reports more seriously and urgently, treating them as severe bugs rather than feature requests,
2. incorporate better accessibility testing into their pre-release workflow,
3. improve accessibility training and awareness among their design and development team to prevent issues like this in the first place.