Summary

The Web Content Accessibility Guidelines Techniques group are considering the best method of hiding form controls from visual user-agents, whilst ensuring they're still usable for assistive technologies.

Author: Gez Lemon

Contents

Techniques for Invisible Form Prompts

As part of the techniques to support the Web Content Accessibility Guidelines (WCAG) 2, the WCAG Working Group are considering techniques for when a visible label isn't required on screen. Becky Gibson, a web accessibility architect for IBM, has started the ball rolling with four of the current techniques in popular use, along with the pros and cons for each.

[Back to the contents]

Hide the label with CSS using display: none

Example of CSS to hide a label. 

label.hide
{
    display: none;
}

Example of the markup to hide a label. 

<label for="day" class="hide">
    Day
</label>

Becky notes that both JAWS and Window Eyes read the label in normal reading mode, and also when you navigate from control to control. Home Page reader does not read the label in item reading mode, but does read the label in control reading mode. In an article about screen reader visibility, Bob Easton noted that with rare exceptions, content hidden with CSS doesn't work with JAWS and Window Eyes, unless the style sheet is imported. Becky's tests were conducted using inline styles, which is effectively the same as using linked style sheets, so hiding labels must be one of the rare exceptions; useful for content developers to know.

[Back to the contents]

Hide the label with CSS by moving it off the visual display

Example of CSS to move a label off-screen. 

label.offscreen
{
    position: absolute;
    left: -99em;
    width: 90em;
    overflow: hidden;
}

Example of the markup to move the label off-screen. 

<label for="day" class="offscreen">
    Day
</label>

Becky notes that JAWS reads the label in normal reading mode, and when navigating from control to control. Home Page Reader reads the label in normal reading mode, and control reading mode. Unfortunately, Window Eyes reads the label twice when reading the contents of the page, reading the label as it appears in the HTML stream, and again with the associated control. When navigating from control to control it reads the label with the control.

[Back to the contents]

Using a transparent single pixel image

This technique involves using the image's alternative text to act as the content for the label element. 

<label for="day">
    <img src="/images/tr.gif" width="1" height="1" alt="Day"/>
</label>

Becky notes that JAWS reads the label in normal reading mode, and when navigating from control to control. Home Page Reader reads the label in normal reading mode, and control reading mode. Window Eyes reads the alt text of the image in normal reading mode, but not when navigating directly to the control. Becky goes on to say,

If you navigate directly to the control with MSAA mode off, Window Eyes picks up the visual text before the control and reads it. This is only an issue in the image example since Window Eyes still reads the label and title information if it is available as you navigate from control to control with MSAA mode both off and on.

[Back to the contents]

Using the title attribute on the form control

This technique involves specifying a title attribute directly on the control, instead of using a label element. 

<select id="day" name="day" title="Day">

Becky notes that both JAWS and Window Eyes read the title attribute in normal reading mode, and also when you navigate from control to control. Home Page reader does not read the title attribute when navigating in item reading mode, but it does read it in control reading mode.

[Back to the contents]

Which is the better technique?

From the proposed techniques, it's difficult to decide which is the better technique. When I first saw the suggestions, I was inclined to support either of the CSS techniques, with a leaning towards moving the content off-screen, as display: none should be honoured by screen readers. However, moving the content off the screen isn't so good for Window Eyes users, as they have to hear the label twice in normal reading mode.

Using an image works, albeit poorly in Window Eyes, but seems an awkward approach to me. All of the techniques could be considered hacks, but this technique seems particularly botchy. Becky also mentioned in her conclusion that Internet Explorer users would see the broken image when images are switched off.

Of all the proposed techniques, the technique I was most uncomfortable with was using the title attribute directly on the form control. The reason I was leaning towards a CSS technique is because my initial thoughts were that it is a presentational issue, and also because I'm caught up in WCAG 1, which states in checkpoint 12.4: Associate labels explicitly with their controls. It's important when considering the techniques to consider the rationale behind them, rather than the hard-line advice. The WCAG 2 equivalent for this checkpoint is guideline 1.3: Ensure that information, functionality, and structure are separable from presentation.

Whilst preferring that on-screen prompts are explicitly associated with a form control, Jim Thatcher said he considered the title attribute to be an ideal choice for making the connection between a prompt and a form control where on-screen text isn't adequate for some reason. It is also less error prone with maintenance, requiring just one change, whereas a label would require two coordinated changes. Having considered Jim's thoughts further, and taking WCAG 1 out of the equation, I'm inclined to agree that the title attribute does seem ideal for situations where an invisible prompt is required.

[Back to the contents]

Category: Accessibility.

Comments

  1. [invisible-form-prompts.php#comment1]

    And you also have to consider that both CSS and image techniques will not be functional in text browsers (Lynx etc.). When you require invisible prompts in every "visual" browser (eg. graphical and text), the technique with TITLE attribute will be the only chance to achieve it.

    (sorry for my poor engish - I am not a native speaker)

    Posted by David Spinar on

  2. [invisible-form-prompts.php#comment2]

    How about hiding the label dynamically using javascript after the page has loaded?

    The label would still be there for screen readers as they ignore scripts.

    The markup would be identical to example 1 and the script would look something like: 

    
var els=document.getElementsByTagName("label");

for(var i=0; (el=els[i]); i++) {

  if (el.className=="hide") {
    el.style.display="none";
  }

}

    (scuse any typo's, its late)

    Posted by Richard@Home on

  3. [invisible-form-prompts.php#comment3]

    Did anyone test the clip property in all screen readers ?

    As far as I tested it, it seems to have no effect in Jaws and Opera 7.60 vocal in reading mode. 

    
label.offscreen
{
    position: absolute;
    clip: rect(1px 1px 1px 1px);
}

    See http://blog-and-blues.org/weblog/2004/08/15/274 (in french)

    And also http://blog-and-blues.org/weblog/2004/08/19/277 (in french too) about cliping as a possible alternative for FIR.

    And please apologize my poor engish *wink*

    Posted by Laurent Denis on

  4. [invisible-form-prompts.php#comment4]

    Hi David,

    And you also have to consider that both CSS and image techniques will not be functional in text browsers (Lynx etc.).

    That's a very good point. The only text browser I have access to is Lynx, and the title technique is the only one that works effectively in that browser.

    (sorry for my poor engish - I am not a native speaker)

    Your English is excellent.


    Hi Richard,

    How about hiding the label dynamically using javascript after the page has loaded?

    The label would still be there for screen readers as they ignore scripts.

    It's a technique that would be worth getting some feedback on, but I don't think it's the solution. Screen readers don't ignore scripts unless they're configured to do so. JavaScript can be made inaccessible to screen readers by being implemented incorrectly, but as far as I'm aware, it's pretty well supported with modern screen readers. If for some reason the script didn't hide the labels from screen readers, there's no guarantee it wouldn't do so in the future. Having said that, from Becky's results, screen readers still know of the associated label, despite it being hidden. There's also the problem of people turning off JavaScript in their browsers - they too would see the labels. I can't see any major benefit of this technique over pure CSS.

    Hi Laurent,

    Did anyone test the clip property in all screen readers ?

    Again, it would be great to get some feedback about how screen readers handle the clip property.

    And please apologize my poor engish *wink*

    Your English is excellent too.

    I think the main consideration with hiding the prompt for a form control, as highlighted in David Spiner's post, is graceful degradation. What happens when JavaScript, or Images, or CSS is switched off or not available? The title attribute seems to be the most robust of the proposed methods. I would still like to hear feedback on the other techniques, as they're useful for different situations.

    Posted by Gez on

  5. [invisible-form-prompts.php#comment5]

    Just a brief comment on the off-left technique. In the example shown above, text is offset -99em and is allowed to be 90em wide. That certainly puts the text left of the viewport, but allows only 10em of maring before it starts invading the viewport. If the label is farther than 10em from the left edge of the viewport (say a search form in the right column) unwanted text is going to start appearing.

    If you're going to push it off left, go wider than you ever expect a window to be, and then some. I started with -1000px, but them some rich dude with a 24 inch LCD at a huge resolution told me about the text creeping in from the left. *smile*

    In reference to Laurent's idea about the clip property, it's a good one to consider. Too bad we didn't think of it when running the original screen reader visibility tests.

    Posted by Bob Easton on

  6. [invisible-form-prompts.php#comment6]

    If the label is farther than 10em from the left edge of the viewport (say a search form in the right column) unwanted text is going to start appearing.

    That's a good point, Bob. It's easy to overlook that an element positioned absolutely is positioned according to its container block, which might not be the screen. Maybe a left value of -9999em, and a width of 1px would have been better choices.

    In reference to Laurent's idea about the clip property, it's a good one to consider. Too bad we didn't think of it when running the original screen reader visibility tests.

    Agreed. I think it's reasonably safe to assume that it would yield the same results as your off-left method, but it's always good to have definitive tests.

    Posted by Gez on

  7. [invisible-form-prompts.php#comment7]

    I'm with Jim on this one. The title attribute is the best fit when you don't want a visible label. I have a client that was contacted by one of those "your website is breaking the law and we will grass you up if you don't give us your business" websites who pointed out that that they had form controls without labels. That's being generous actually - they just provided the output from an online Bobby report. I then spent several hours explaining to the client why we had used the title attribute rather than a label, but that's another story *smile*

    Posted by Dave Ryan on

  8. [invisible-form-prompts.php#comment8]

    I have been burnt in the past by advocating the use of "display:none" as it relies on some screen readers' improper implementation of CSS.

    So I recommend the use of the title attribute on an input, mainly because it does the job in respect to (most) screen reader users. This appears to be the best solution when form inputs are contained within data tables, as table headers can also be accessed by users (in practice this does not appear too helpful; so don't rely upon headers alone for identification of inputs).

    But wherever practical I recommend that text labels be provided as the title attribute cannot be accessed by keyboard only users,which many people seem to forget, and don't forget the option of using fieldset/legend elements in combination with title attributes.

    Posted by steve faulkner on

  9. [invisible-form-prompts.php#comment9]

    Gez, thanks for explaining this one. I had seen references to it on the WAI-GL, but not spotted the context surrounding the discussion. I'm in a project that I feel needs extra labels, and I've been considering transparent 1px images as labels. Agreed it is a hack. I'm coming around to your preferred option of offscreen labels, but haven't given the title attribute idea much thought.

    Posted by Isofarro on

  10. [invisible-form-prompts.php#comment10]

    My only concern with *reliance* on the title attribute in most cases is that there is no guarantee that it will be read out by screen readers because it is dependent upon the verbosity settings of the screen reader.

    As an example, JAWS 4.51 preferences include the following for text links: Use Title, Use Screen Text, Use "on mouse over tool tip", Use Longest, Custom Search (where you can specify a preferred "order")

    Now, I know that a text link has nothing to do with form labels, however, what it does illustrate that depending on user settings, the title attribute may never be read at all (I've just checked the "factory settings" for JAWS 4.51 and it is set to ignore title attributes on both garphics and text links). If Becky's testing is correct (I'll assume it is), I'm wondering if the title attributes on form controls are being read because JAWS does it by default, or if it is because she has adjusted the default verbosity settings.

    Any idea Gez? Becky, perhaps you are following the comments here and can lend some insight into the JAWS tests you've performed? I'm all for using titles, but would want to be sure we can rely on it... My preference has always been if we are absolutely reliant on something, it should use the lowest tech solution available - which in this case would still be a real <label> ...</label>

    Posted by Derek Featherstone on

  11. [invisible-form-prompts.php#comment11]

    Hi Steve,

    I have been burnt in the past by advocating the use of "display:none" as it relies on some screen readers' improper implementation of CSS.

    I'm not really sure what you mean. JAWS, Window Eyes, and Home Page Reader all implement display:none correctly. It's a pity that the aural media type isn't supported by assistive devices, as that could be used to override display:none when you want content hidden on the screen, but read out by screen readers. In this particular case, the label element is bound to the control, so hiding the label with display: none doesn't destroy the association.

    Hi Isofarro,

    I'm coming around to your preferred option of offscreen labels, but haven't given the title attribute idea much thought.

    I do still like the off-screen technique, but if you don't want the label showing when CSS is switched off, or CSS is not available, the title attribute appears to be the best solution. I don't see CSS being switched off or not being available as a massive hindrance to the off-screen technique, as all that will happen is the label will appear and provide extra context, which couldn't be considered a bad thing, but may disrupt a carefully planned out design. I suppose it's a question of getting a balance on maintaining the look, and ensuring the form is usable by the widest possible audience.

    Hi Derek,

    My only concern with *reliance* on the title attribute in most cases is that there is no guarantee that it will be read out by screen readers because it is dependent upon the verbosity settings of the screen reader.

    I share your concerns over relying on the title attribute, and voiced it to the working group. The response I received was that JAWS, Window-Eyes, and Home Page Reader all speak the title attribute on form controls if there is no <label> element. I'm not sure about the configuration options of Window Eyes and Home Page Reader, but JAWS can be configured to speak both the <label> element and the title attribute if they are different.

    Posted by Gez on

  12. [invisible-form-prompts.php#comment12]

    I'm not sure about the configuration options of Window Eyes and Home Page Reader, but JAWS can be configured to speak both the <label> element and the title attribute if they are different.

    Where, exactly, does one configure that in JAWS, though? I've looked everywhere, and the only mention I see for configuring title attributes to be read or not read are for graphics and for text links. I don't see anything anywhere that provides that same level of control for form labels. (Which comes back to my first question -- "I'm wondering if the title attributes on form controls are being read because JAWS does it by default, or if it is because she has adjusted the default verbosity settings.")

    Perhaps I'm just missing the settings in the configuration manager somewhere?

    Posted by Derek Featherstone on

  13. [invisible-form-prompts.php#comment13]

    Which comes back to my first question -- "I'm wondering if the title attributes on form controls are being read because JAWS does it by default, or if it is because she has adjusted the default verbosity settings."

    Sorry, I should have mentioned that reading the title is the default behaviour when there is no label.

    John Slating said:

    JAWS, Window-Eyes, and IBM Home Page Reader all speak the title attribute on form controls. If there is no <label> element, the title is spoken by default.

    I don't have a copy of JAWS, so I've no idea how you configure it. Maybe someone else could help with that one?

    Posted by Gez on

  14. [invisible-form-prompts.php#comment14]

    Hi Gez,

    I'll keep poking around -- I didn't see anywhere to change settings for forms -- so if what John says is true regarding title attributes being read, then that is very good news. The default behaviour is what is important in this case... One last question... you mentioned:

    but JAWS can be configured to speak both the <label> element and the title attribute if they are different.

    Is that still the case? if so, it implies that JAWS does have a mechanism for controlling verbosity of form controls. If not, then I'm likely looking for something that doesn't exist. It might also be something that is configurable in the latest and greatest version of JAWS 5 as well. Admittedly, I haven't looked too closely at version 5 because I tend to stay one step back from the bleeding edge in terms of testing...

    In either case, I'm going to do some more testing because this is potentially really good news... (despite the fact that it means that two of the techniques I was going to work on and write up for WATS.ca will go out the door if the title attribute works!)

    Cheers,
    Derek.

    Posted by Derek Featherstone on

  15. [invisible-form-prompts.php#comment15]

    but JAWS can be configured to speak both the <label> element and the title attribute if they are different.

    Is that still the case?

    That statement was made in reference to JAWS 5, so it may only be available in that version. I'll do some digging around myself and see if I can get any more information on it.

    Posted by Gez on

  16. [invisible-form-prompts.php#comment16]

    How about using the z-index property to place the label content behind the element containing the input?
    For example:

    <div><label style="z-index:-1;position:absolute;" for="poot">poot</label> <input type="text" id="poot"></div>

    I tested this on a number of browsers (firefox, IE,Netscape,Opera) and it displays as desired (text is hidden), degrades gracefully and is read correctly by screen readers (HPR and Jaws 4.51).

    Posted by steve faulkner on

Comments are closed for this entry.