Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Label "for" and Input "id"

I'm currently working on a forms module for a CMS so that our users can create their own forms to display on their website and I'm trying to make sure it's all accessible with labels etc.

My question is, if you have a <label> for an <input> with a [for] attribute to link to the [id] of the input, does the [id] have to actually mean something? Is it read? Or is it just to link them?

Eg.

<label for="input1">Name</label>
<input id="input1" />

or

<label for="name">Name</label>
<input id="name" />

Will these have the same or different results on a screen reader?

like image 822
Oli B Avatar asked Mar 31 '16 13:03

Oli B


2 Answers

If you have a <label> for an <input> with a [for] attribute to link to the [id] of the input, does the [id] have to actually mean something?

Browser semantics* refer to how a browser will identify a DOM node and what the browser will read to users who use assistive navigation.

The [id] and [class] attributes do not add to semantics. It's important to still use descriptive IDs and classes where possible, but only insofar as to make development easier.

Is it read?

No. As far as I'm aware, the [id] attribute is never read directly to a user through normal operation of a website. See my note below about the document fragment identifier.

Or is it just to link them?

It tells the label which <input> (or <select> or <textarea>…) the label is labeling, and also provides some UI features such as moving focus to the relevant input when the label is clicked, tapped, or otherwise triggered.

When a labelled element is focused, browsers will know to tell the screen reader to read the label associated with the element.


What about the [name] attribute?

In a <form> screen readers won't read a [name] attribute because it doesn't indicate anything semantic, however for GET requests the [name] attribute will be used as a key in the query string. Query strings may be read to users, so it's worth considering using a human-readable [name] rather than something auto-generated.


What about document fragment identifiers?

If you're planning on using an [id] to <a>nchor down the page, then the value of the [id] attribute may be read when it becomes the hash of the URL. Just like with the [name] attribute it may be worth considering using a human-readable [id] for these cases.


*a word whose definition is meaning, which makes discussing its own meaning…difficult and quite meta

like image 111
zzzzBov Avatar answered Oct 10 '22 03:10

zzzzBov


No, not what so ever.

If you put yourself in a situation where either the id or class is visible to the user then you have probably done something horribly wrong, or you are trying to have an unnatural level of code transparency (which could, for example, be suitable in a class-room situation).

The class and id attributes are just there for programming purposes. They should follow the naming conventions you have set for yourself and make as much sense as possible from the programmer's point of view.

like image 20
NachoDawg Avatar answered Oct 10 '22 05:10

NachoDawg