Semantics of form labelling

Question

I tend to try and steer clear of using ID's outside of functionality purposes. Which brings me to my question, when labelling items in forms there are multiple methods. I have always done this a specific way to avoid ID's; however, what are the pro's and con's of the alternate methods? Does one way have more semantic meaning to the browser than the other? How does accessibility play a role in it?

My usual method of implementation:

<form role="form" action="#" method="post" name="form" novalidate>
  <label>
    <span>Search</span>
    <input role="search" type="search" placeholder="Search" name="s">
  </label>
  <button role="button" type="submit" name="s-btn">Search</button>
</form>

However, you can also use for="" and label an ID for the corresponding field. Which is obviously better served for type="radio" and type="checkbox" but does it hold any better semantic value than the above?

<form role="form" action="#" method="post" name="form" novalidate>
  <label for="s">Search</label>
  <input role="search" type="search" id="s" placeholder="Search" name="s">
  <button role="button" type="submit" name="s-btn">Search</button>
</form>

And you can even use WAI-ARIA to label as well with ID's, should this be used in cohesion with for="" or is it a stand alone labelling method?

<form role="form" action="#" method="post" id="Form" novalidate>
  <label id="s" for="sf">Search</label>
  <input role="search" aria-labelledby="s form" id="sf" type="search" placeholder="Search" name="s">
  <button role="button" aria-labelledby="form" type="submit" name="s-btn">Search</button>
</form>

I guess this question is brought on due to the never ending pursuit of balancing maintainability, optimizations, semantics, and accessibility.

Answer 1

the two methods, nesting controls into labels (implicit) and using id and for attributes (explicit) have different positives and negatives, however the current trend i've seen from professionals is to move away from implicit and more into explicit.

explicit allows more flexibility within your document(s), and html5 allows form controls to be placed anywhere within the document, so they go hand in hand in this case.

implicit can't be used for checkboxes and radios, as the label element is required to come after the input form control, so there is one limitation. implicit also had poor browser support a few years ago, and seems to still have trouble with screen readers. implicit does add to accessibility and usability, because the label's size adds to the form control's clickable surface area.

wai-aria still isn't finished, and also has problems with browser/screen reader support, but that certainly shouldn't stop you from implementing it when possible. ideally, if not supported, it will simply fail silently (like html5 inputs do with non-html5 supporting browsers), but i would be wary here and test vigilantly. different supports can also have one screen reader/browser/user agent reading both, instead of seeking wai-aria, and defaulting to imp/exp labeling.

semantics: meh. ask 10 devs, you'll get 10 answers. but the correct answer is are you using that form control properly? is it labeled correctly? properly and correctly meaning will it validate and pass accessibility testing? properly and correctly also meaning, in your personal context, in this use-case, are you using the correct control/label for the interaction you are providing the user? only you can answer the latter...if you're using posh principals, you shouldn't have any problem with either.

side note: about avoiding ids, in this case, ids are optimal and they are being used for functionality...i'm assuming the form controls are being processed on submit? i could be wrong about functionality in regards to your intended use, but they are still optimal here, if you are avoiding them for wpo: you can use ids, just don't target them in your style sheets.