This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by The Jared Wilcurt
Recently I've been hearing to avoid "implicit" labels and to favor explicit labels for accessibility reason. This was the story I was given, but it felt like there was something missing from the story.
<!-- Implicit -->
<label>
Text
<input>
</label>
<!-- Explicit -->
<label for="example">Text</label>
<input id="example">
After doing some research I found, like with all things, there is some more nuance to the story.
- Both are 100% fine and completely valid according to all language and accessibility specifications.
- HOWEVER, specs and real world implementations are two different things. Some actual screen readers do in fact have problems reading labels properly.
- The issue is not related to the code being nested in a label, but instead whether there is an
id/forattribute involved.
Sources:
- 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">
And of course, make sure to use unique ID's.
This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by The Jared Wilcurt
The Jared Wilcurt | Sciencx (2022-10-22T17:55:32+00:00) The Truth behind Implicit/Explicit form labels. Retrieved from https://www.scien.cx/2022/10/22/the-truth-behind-implicit-explicit-form-labels/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.