Guidance on Designing & Implementing Form Labels

In an effort to improve the way in which Radancy includes form labels within its sites and products, this document seeks to introduce more clearly defined guidance that can be shared with all team members. Especially designers, developers, and QA engineers. Inclusion of a proper label is critical and allows more people to understand and use the form. Omission or poor implementation of a label is also considered a direct failure of Success Criterion 3.3.2 Labels or Instructions. This guideline was intentionally omitted from our initial baseline release to give us enough time to educate and acclimate ourselves to the advice presented here. We will begin to test against this guideline more vigorously, beginning in the summer of 2022.

The Rules

  1. All form fields must include a visible label. See exceptions.
  2. Placeholder values are not an appropriate alternative for labels.
  3. Placeholder values may not duplicate what is already found in a label.
  4. Placeholders may not be used with hidden labels.
  5. Placeholder values may only be used to provide supplemental or suggestive information.
  6. Critical information about a form field must always be placed outside of the field.
  7. Placeholder values must always be contrast friendly.


  1. Certain types of forms are so ubiquitous that they have become a common and well understood convention across the web. For example, a global site search that utilizes a single input field and button may not require a visible label.
  2. Certain types of information may have labels omitted if they are grouped together properly. See grouping inputs example.

Floating Labels: A Word of Warning

Including a visible label, often outside of the field, is always the best solution. However, there may be times when this is not always possible. In such cases, the floating label technique could be used, but there are risks with this method that one should be familiar with before deciding to implement. Development considers this an anti-pattern, so use with the utmost of caution.


The following examples are meant to illustrate best (and poor) practices of labeling form fields.

Note: The placeholder attribute used in some examples may not be included in some assistive technology/browser combinations. This is but one reason why we can't fully rely on it to stand in as a label.

Placeholder Values Are Not An Appropriate Alternative For Labels (Avoid)

While using placeholders as labels may seem like a great way to reduce visual clutter, placeholders and labels are very different things. Please familiarize with the numerous pitfalls of using placeholder text to stand-in for proper labels.

Assistive Technology

"Keyword edit blank"

Placeholder Values May Not Duplicate What is Already Found In a Label (Avoid)

Do not duplicate the label as placeholder text. Not only is this visually redundant, but assistive technology users may have to listen to it twice, too. Alternatives measures to fill in the empty space with similar text, because empty space may not be aesthetically pleasing, will be equally frowned upon (Enter your first name, Ex. John, etc.).

Assistive Technology

"First Name edit First Name blank"

Placeholders May Not Be Used With Hidden Labels (Avoid)

Using a placeholder value and hiding the label does not solve the problems we seek to avoid. While hiding labels may seem like a terrific way to address accessibility, it is often prone to issue. For example, we may be hiding a label that includes redundant placeholder text. All we have done is mask the issue, visually. Include labels or use the floating label pattern instead.


<label class="sr-only" for="example-3-keyword">Keyword</label>
<input id="example-3-keyword" placeholder="Keyword">

Assistive Technology

"Keyword edit Keyword blank"

Placeholder Values May Only Be Used To Provide Supplemental or Suggestive Information

Placeholder text should be used to provide supplemental information. For example, formatting or suggestive hints are an ideal use of placeholder text.

Assistive Technology

"Phone Number edit Example: 123-456-7890 blank"

Critical Information About a Form Field Must Always Be Placed Outside of the Field

Placeholder text does have its limitations. If a field is pre-populated with data or a user begins typing, the placeholder text will vanish. A problem for people who have cognitive disabilities, to name but one group it may affect. If formatted or supplemental information is critical, then instructions should be placed outside of a field, where it will always be present.

Required format: 123-456-7890


To convey this information to assistive technology users, use aria-describedby, which will append the message to the input field.

<label for="example-4-phone-number">Phone Number</label>
<input aria-describedby="phone-formatting" id="example-4-phone-number">
<p id="phone-formatting"><em>Required format: 123-456-7890</em></p>

Assistive Technology

"Phone Number edit Required format: 123-456-7890 blank"

Placeholder Values Must Always Be Contrast Friendly

Default placeholder text, often a lighter shade of gray, can be hard to read in some browsers, so always aim for a color of #767676 on white backgrounds.

Screenshot of default placeholder text in Safari

Grouping Inputs Without Visible Form Labels (Exception)

In certain circumstance, traditional labels can be omitted, but should be grouped together via a fieldset. For example, three separate fields for a single date entry. In addition to the fieldset, we would include a legend as our primary label, along with aria-label to distinguish each field.

Note: This is not a technique we would use on a single search form, but to better organize groups of fields, within a complex form.

Select Date (Month, Day, Year)


  <legend>Select Date (Month, Day, Year)</legend>
  <input aria-label="Month" placeholder="MM">
  <input aria-label="Day" placeholder="DD">
  <input aria-label="Year" placeholder="YY">

Assistive Technology

"Select Date (Month, Day, Year) grouping, Month edit MM blank"

Last Updated: April 6, 2022

About the Author

Michael Spellacy

Michael "Spell" Spellacy is the Director of Accessibility at Radancy. If you have any questions, feel free to contact him on Github or see what he is up to on his blog.