[Accessibility] One label, two input boxes

Hello all,

I need to find a way for screen readers to still correctly identify an input box without a label.

At some point on my form, I present the users with the following:

<label class="labels" for="contphone">Phone</label>
<input class="elems" name="contprefix">
<input class="elems" name="contphone" id="contphone">

Code (markup):

This produces the visual effect I want. But it fails under the 508 Standards, Section 1194.22, rule 1.1.2 - All INPUT elements are required to contain the alt attribute or use a LABEL.

Producing a label for the contprefix form element is really not an option I would like to contemplate. It damages the current layout.

What CSS do you suggest to solve this problem?

 

Try this:
HTML:

<label class="labels" for="contphone">Phone</label>
<label class="labels-hidden" for="contprefix">Prefix</label>
<input class="elems" name="contprefix" id="contprefix" >
<input class="elems" name="contphone" id="contphone">

HTML:

CSS:

label.labels-hidden {
        position:absolute;
        left:-9999px;
         }

Code (markup):

 

Thanks for the tip Maujor.

Well thought. I was thinking the display: hidden attribute, but knew it would also hide it from screen readers, That will do the trick, definitely.

 

You mean display:none; ? well it will still readable if you use the correct way to include the stylesheet.

 

display:none yes. I'm have only 3 months of CSS. Some names still didn't stick into my head.

What would be the correct way to include it? I have to say display:none seems a more elegant approach. How could I make screen readers ignore it?

 

There is no way for hide style sheet from screen readers.
display:none; isn't a good choice because this CSS declaration hide the content for some screens readers.

 

Exactly what I was thinking intially. Thanks once again Maujor.

 

As others have said, some screen readers will literally interpret display: none; and prevent the element from being "seen" by the screen reader. I think JAWS is one of them (or was that Windows-Eyes?).

Anyway, I do this all the time for basic search forms, which literally removes the legend and label elements from view while also keeping them available for screen readers.

 

import. Works at least for JAWS.

But anyhow off-left is still the best way.

 

I wouldn't import the stylesheet. Doing so removes the greatest benefit that CSS has to offer - an external file that can be cached in the browser. With importing, you have to re-download the same file with each page view or refresh.

 

For something that has to be hidden, moving it off to the left is probably best. However, when you have one label for a group of inputs (such as Date Of Birth and then three drop-downs), I use this because I feel too stupid having a label for each part of the birthdate (if you cannot fill in your birthdate correctly then you should have your guardian filling the form out for you):

form beginning blah blah

<label for="birthdate">Date of Birth</label>
  <div id="birthdate" class="matchingdiv">
    <select name="birthdateDay" id="birthdateDay">
      <options.... galore....  in numbers...</option>
    </select>
    <select name="birthdateMonth" id="birthdateMonth">
      <options... galore... in month names... </option>
    </select>
    <select name="birthdayYear" id="birthdayYear">
      <options... galore... in 4-digit-numbers... </option>
    </select>
  </div>

Code (markup):

The wrapping div only contains inputs and has the matching id to go with the label's FOR. Each input inside has it's own name and ID for scripting etc, and is very similar to the id. The class of "matchingdiv" is for styling, esp since IE shows a div as an extra space cause it's a block... I have to set them to display: inline I think.

I use this for dates, telephone numbers, license plate numbers, anything in a group (though I've been putting the telephone numbers in one input lately as people have different ways of filling them in). To make sure some goofy Americans don't fill in the dates wrong, the days are in numbers and the months are in words, so nobody can screw it up-- something one has to be careful of if they're going to be using only one label for multiple inputs. It has to be clear as day to an 8-year old.

 

Thanks for all the comments.

Stomme poes, seems an interesting option. However I'm not sure if all screen readers will agree on how to read that snippet. If you take a close look at the HTML 4.01 specification, you'll notice the for attribute is meant to match the id of another form control, not just any element (17.9.1). Meanwhile form controls are defined in 17.2.1.

A standards compliant reader will almost certainly ignore the label-div association you constructed there.

One could argue there is an attractive logic to your code. Indeed.
However, I'm afraid, the resulting page semantics are broken since div has no semantic meaning and you are trying to give it one. Screen readers rely on good semantics, more than anything else, to produce better results.

I enjoyed the off-left option better. However I find it to be slightly inelegant. I'm unsure as to whether it would make sense in future technical reports the introduction of ''filters" that allowed me to hide/reveal content from screen readers and other reading aids.

 

I have always wondered if the above code would work... now in JAWS there is no problem, however I've always had my labels directly next to my inputs so that was never a problem. I also don't have anything else like WIndowEyes and JAWS is merely one of many screen readers.

I only like the left: -gazillion px when I plan on having the labels anyway, like when I had a bunch of 20px by 20px icons with checkboxes... no room for labels and the sighted can clearly see what the icon looks like (and [title=" "] tells that what it means if it's not clear), however otherwise I normally have image replacement or colour-hidden text (I've used this for skip links, which still show up on :hover so google doesn't have a fit).

But for grouping... if you hear of a better method of grouping multiple inputs under one label, I'd love to hear it. No way am I going to double the size of my (sometimes already quite long) forms adding extra labels.

 

Well, visually I find fieldset and legend combinations quiet appealing. They even have the advantage of adding an extra level of indirection that I can style with and completely change their rendering if I wish too.

Semantically this is probably also the best option with the advantage screen readers have specific instruction on how to read them; they are meant to read the legend tag on every field followed by the control's label. So something like the following...

<fieldset>
<legend>Telephone</legend>
   <label for="phoneprefix">Prefix</label>
      <input name="prefix" id="phoneprefix">
   <label for="phonenum">Number</label>
      <input name="phone" id="phonenum">
</fieldset>

Code (markup):

... should be read as "Telephone, prefix" and "Telephone, Number" as the user cycles through the two controls.

This was more or less my original code in fact. I wanted to hide those two labels since visually they were redundant. Now I know how.

 

For me that's just as bad. I'd end up with a fieldset and legend for every date question and every license plate. I've often got 3 or 4 dates in a row: driver birthdate, policy-holder birthdate, date policy begins, youngest driver, meldcode, license plate...

Sometimes I leave my legends blank. I've tried to avoid this by using "filler" text such as "Fill In" (something which is both obvious and redundant, but doesn't hurt) while other times I've needed part of my forms to have completely different styles because of the length of the labels (sometimes it's a long legal question), so I've wrapped them in another fieldset with a class for styling, and all the labels under that have the new styles... but in cases where the legend is merely repeating exactly what the label says, if I can't manage something like "Fill In" then I leave it blank. Not the most semantic thing, but I'm willing to take that to make my forms conform a bit more the the norm than look like a retard designed it (even if one actually did : )

It's especially confusing for when I actually do use fieldset and legend for actual question grouping (human info, then vehicle info, then legal info). I've tried hard to remove the legalese fieldsets because if someone can see the fieldsets they may wonder what the last one is for, when there is no semantic reason for them. So far, no success.