Forms: "for" attribute when wrapping inputs in labels
I'm going to be creating a form which has multiple instances of the same inputs, due to many of those inputs being relegated to a separate 'modal' html at mobile.
Because of this, I won't be applying IDs to the inputs, but instead using class.
I've been told, for ARIA reasons, it would still be best to wrap my inputs in labels.. However, because my inputs won't have IDs, I'm confused what the use of these labels will be, since the label "for" attribute only points to IDs, which I won't have.
With regard to ARIA, will wrapping an input in a label be enough to signal to the ARIA user the purpose of a particular input, even if they're not connected by "for" /ID ?
35 Replies
is similar to
By putting the input inside the label, an association is created between them much like you can do with
for= and the input ID.
If you're putting inputs inside labels, don't use the for attribute on the label.
My personal preference is the nesting because it creates a clear visual hierarchy in the markup, but use whichever you prefer when you don't have any constraintsgotcha thank you !
np!
so then is the label just left blank?
sorry
if it's not getting an id and I'm wrapping it I mean
In that setup you would put your label text in the span;
Something like that ^
ohh I see okay
that works then
what if I'm making a search bar that has placeholder text in them identifying what the input is for.. would I still need the <span>? Since visually there would not be any extra html outside of the search bar input I mean
I would end up needing to hide that span.
So like
<label> <input type="search" placeholder = "Filter by title" /> </label>
In that case I would do something like
Just to ensure that the input remains labelled clearly. I'm not 100% on if placeholder text is read by screenreaders or if it's a visual UI thing, but best practice says using a label makes sure you're covered
a big rule of a11y is to not rely on placeholders for displaying information
if you want to be strict (and I sure will) having only the placeholder, even with the sr-only solution, is wrong
btw for code blocks on discord type it like this;
```html
<!-- you can change that "html" to "css", "js", "ts", or any other language name for more accurate syntax highlighting -->
```
also see #👋welcome as it's got a lot more about formatting which is pretty useful
how did you escape the code
thanks yea, I was gonna ask about that
backslash yeh?
# **yeah** *backslash* ~~escapes~~ __any__ `discord` formatting, same as markdown
So was @willsterjohnson 's solution wrong?
not wrong...incomplete perhaps
in this situation in particular I'd say is mostly fine
I'd have an issue if your placeholder was for example...a format, say you have an input for a birthday and your placeholder is
mm/dd/yyyy
when the placeholder tells the user HOW to fill up the info, then 100% f that
for this tho...it's alrightfor a text input it's fine to have the same label text as placeholder text, so long as you know you're allowed to have them be different.
You might wanna label something "username" with the placeholder "your_name_here" or something, as long as there's a label that correctly describes the input, the placeholder is more of a UX problem than an a11y problem.
Also if you're talking about a text input with
placeholder="mm/dd/yyyy"... ew once for that and ew again for putting the month before the day and the year at the endfor the record, i won't have any date inputs, but good to know
no the placeholder is an a11y issue, primarily for cognitive disabilities, hence why it's a bigger issue when your placeholder gives info on how to fill up that input
for something as simple as "search" is fine tho
the sr-only label is a must tho for sure
i just want my wrapped label to somehow serve its ARIA purpose, which I'm assuming if is has a span couple with the input inside of it, that would be enough for ARIA to recognize it
a visible label can be removed
coupled*
yes, this solution works as it should
idk what sr-only stands for either
screen reader only
just a class name, you can call it whatever
but it's to hide it visually but screen readers can still detect it
sr-only is kinda standard amongst devs, the name can be read to mean "this class is being used to hide things visually without hiding them from the document flow that assistive technology uses"...
so instead of typing all that we use sr-only and most of us have just accepted this unofficial standard namegotcha ok
good information, thank you guys very much
wait I'm still confused as to what to do about the <span> inside the <label>.. I don't want to see span text smushed up next to my inputs
or I guess that's what that absolute positioning was for ok
yeah the
sr-only thing is for when you dont want to see the span.
If you do wanna see it, but you don't like how it's positioned, you can use display: flex or display: grid on the <label> and adjust the styles to your preferenceso the class alone is enough to keep it hidden? Without applying any settings to the class? I'm seeing it work, I've never heard of an element working that way before. I would've figured I'd have needed to set something to it to not be visible.
From what I've seen online, it looks like it's a Bootstrap class, but I'm not even running Bootstrap and it's still working?
let's break down the CSS quickly
the absolute position takes the element outside of the normal flow of the document; by using properties like
left, right, top, bottom, and inset, we can say something like left: 20px; top: 50px, which tells the browser to always keep this element 20 pixels from the left edge, and 50 pixels from the top edge of the screen.
I would recommend opening up codepen and playing around with absolute positioning if you're not already familiar with it.
So we know that left: X units means "always make this X units away from the left edge", so when we put a negative value in there, we're placing the element on the opposite side of the left edge; ie, off of the screen. We use a ridiculously large number here because it doesn't cost anything to do so, and it makes absolutely certain that no matter what the user does, it's not gonna show up on screen.
the sr-only class is entirely unrelated to bootstrap, though it's possible that they will have implemented it or something similar. No bootstrap is needed though, just the few lines of CSS at the top of this message.the sr-only class is entirely unrelated to bootstrap, though it's possible that they will have implemented it or something similar.
it's also called .visually-hidden iirc
One's the Bootstrap name, the other is based off the HTML5 Boilerplate project. Can't recall which one 🙂Curious why you used a span with .sr-only instead of aria-label on the label? New to accessibility so they could be completely different usecases
ARIA attributes do nothing and that could've been any element, like
b or ruby. It's moved "off-screen" so it doesn't matter, but a non-semantic element like span is a good choice for such trickery.
In this particular case using ARIA would even be counter productive.
aria-hidden would hide the element from screen readers which is exactly the opposite of what the CSS solution does, which only hides it visually on the page but keeps it accessible for "screen readers only".
ARIA attributes are hints you as a developer provide to the browser so it can tell AT about what's going on inside the markup and teach stupid elements like div and span to be smart about what they might do and contain.
With ARIA you can also redefine the inherent semantic meaning various HTML elements have built in.
Accessible websites are not based on ARIA alone. HTML5 can do a lot. It's when you use JS and complex interactions, where ARIA attributes created and modified from that very JS code can help to explain what's happening.
ARIA used the wrong way can make a site even less accessible for some users of assistive technology than no ARIA at all.
It's an additional vocabulary to spice up vanilla HTML5 where it lacks built in accessibility features and semantics, or where custom code and custom elements dynamically changes the page contents an implement new interactions. That's why there's a need for this addition to create "Accessible Rich Internet Applications".Cool, really great insight! But I'm still a bit confused. What if we removed the
span entirely, and instead added an aria-label. So instead of
We use:
Maybe you already answered this in your answer, but I wasn't able to grasp it.
Would that not parse similarly in a screen reader? I have NVDA, this should be a good exercisesorry, there's often weeks where I don't come here.
You probably checked how this "sounds" with NVDA.
To me, the point of having a label element in the first place is to also increase the hittable area, sth. that's built into the label/input relationship, and other elements don't do.
In your second example, there's no benefit in using a label at all if it's tightly wrapped arpund the input (no padding), might as well be a span.
In both cases there's only the placeholder visible which often is problematic, too, 'cos it's typically rendered in a dimmed, low-contrast font color, some find hard to read;.If it's not dimmed ppl might think the field already contains text and skip over, only to get presented with bizzare error message for not entering all data when they submit the form.
I don't believe there is any viable reason to not have a visible and clickable
label around an input element. Moving it off-sight is just some imagined "aesthetics" by designers that serves no real use whatsoever.
There is no screen where you also enter data that can't also hold a couple extra pixels above the input to put a well visible label to and help target the field it belongs to.
Form design is hard and can quickly become an A11Y and UX minefield if done wrong. Many forms might look pretty, but that's their whole achievement; they often still lack usability.
This is my rough outline of form controls
Typically no placeholder, "hint" and "notice" appear as required.
I don't need to explain "firstname", so no "hint" needed etc.
"notice" is toggled by validation with aria attributes that serve as CSS selectors.
With flexbox or grid, all five different element types elements can be positioned at will and come with reasonable default styles.Hey no problem! Thank you so much for the detailed response as always 🙂