Skip to main content

Styling Complex Labels

By Danielle Romo

Published on September 2nd, 2020

Topics

Sometimes labels for form fields are short and to the point. But other times, it’s helpful to provide users with more detailed information.

Consider the common pattern of selecting a pricing plan for a hypothetical service. To make a selection, users need to know the name of the plan, the price, and its features. But if we include all of those details, it gets hard to read:

Each option’s plan information is included in a label. To improve its appearance, we need to add more elements that we can style. We can’t nest block-level tags (like div) within an inline label element. And we should also avoid interactive or semantic elements that will compete with the label’s meaning and behavior (such as headings, buttons or links).

So what elements should we use? If the goal is to break up the content, we could use br. However, span is a more flexible option.

<label>
  <input name="plan" type="radio">
  <span>Basic</span>
  <span>$0/month</span>
  <span>1 team member</span>
  <span>100 GB/month</span>
  <span>1 concurrent build</span>
</label>
Code language: HTML, XML (xml)

With each content chunk encased in a span, we can use CSS to change the layout and style of individual text elements to create visual hierarchy.

The labels are easier to read, but to make this interface more polished we can:

  • Take advantage of horizontal space on larger screens so it’s easier to compare options.
  • Visually identify where users can click or tap.
  • Clearly associate the inputs and labels.

I decided to take care of these issues by treating each label like a “card”.

And while this solution is largely focused on how to improve the visual experience, it’s important to keep accessibility in mind. Each card includes an extra span that is visually hidden, but still available to assistive technology, so all users are provided with the same detailed information.

There are plenty of situations where unstyled HTML elements work fine, but it’s good to remember we can push their styles pretty far when the user experience calls for it.

Comments

Stuart said:

Looks very nice, Danielle!

However, I have an accessibility question: why do you need to include the visually-hidden information that is (almost) exactly the same as the visual information? I understand that you are using aria-hidden for visual content, but wouldn’t it be possible to include the information just once, and visually hide some commas to make it clearer to non-visual users? Just wondering, as I am always looking to make a11y in my sites as easy as possible to include 🙂

Many thanks for the article.

Permalink to Stuart’s comment

Replies to Stuart

Danielle Romo (Article Author ) replied:

Thanks Stuart! That’s a good question. When testing the demo with VoiceOver, only the plan name was read aloud. I included the extra visually-hidden span to make sure everything gets read by assistive technologies. It made sense to use it in this demo, but it might not always be necessary. I also used it as an opportunity to make the text easier to understand when it’s read aloud. For example spelling out ”per month”, instead of “/mo”.

Shawn Beatty said:

Thanks for sharing the pattern. Great thinking. One thing A11Y advocates have shared with me is the consideration that not all screen reader users are completely blind and therefore might be using screen readers to supplement their visual experience. So, it might be worth considering if the visual and screen reader experiences differ too much as they tab through the page that could also be confusing if it reads something different than shown. This case is pretty similar but adding a redundant variation might not be ideal. That point made me think differently about A11Y as ideally creating parity rather than an alternative. ✌🏼