The Truth Behind Explicit Form Labels

Lately I’ve been hearing to avoid “implicit” labels and favor explicit labels for accessibility reason. This was the story that was given to me, but it felt like something was missing in the story.

<!-- Implicit -->
<label>
  Text
  <input>
</label>

<!-- Explicit -->
<label for="example">Text</label>
<input id="example">
enter fullscreen mode

exit fullscreen mode

After doing some research I found that like all things, there are more nuances to the story.

  1. Both are 100% OK and fully valid as per all language and accessibility specifications.
  2. AlthoughOf course, specs and real-world implementation are two different things. some real screen readers Doing There is actually a problem with reading the label properly.
  3. Problem Not there The code in a label deals with being nested, but is there one instead? id/for Included feature.

Source:

  • Screen Reader Benchmark Testing:

TLDR:

<!--
  Bad: Though all screen readers *should* work with this,
  some just won't play nice with it.
-->
<label>
  Text
  <input>
</label>

<!--
  Works: This has the same support in screen readers as
  the next option, but semantically it's not great, as the
  label header contains non-text content
-->
<label for="example">
  Text
  <input id="example">
</label>

<!--
  Best: This separates the label tag and input so their
  duties are not conflated, it uses the for/id attributes
  that works in all screen readers
-->
<label for="example">Text</label>
<input id="example">
enter fullscreen mode

exit fullscreen mode

And of course, be sure to use unique IDs.

Leave a Comment