display:none on legend and screenreaders
Hi, my first post here. I was wondering if someone here knows something about this.
It was recommended to me that since I had multiple forms on a page (in the form of search boxes, etc.) that I put fieldsets and legends around my forms, even though the forms themselves are usually just one text field and a button. However, having a label for that one field and a legend is a bit redundant, not to mention clutters the layout a bit. I removed the border for the fieldset and made the legend display:none in CSS. My quesion is: does this render the legend useless with screen readers? I know regular block elements with display:none don't get read by the screen reader, but will Jaws in form mode do the same?
Share: 
Eh up Chuck 
(Northerners' in-joke, sorry)
As many types of assistive technologies utilise a web-browser (often IE), hiding content with display:none will hide it from screen readers too.
Why not move 'untidy' elements off screen with...
form legend {
position : absolute;
left : -999em;
width : 900em;
}
Hope this helps.
Stuff I do
******************************
Design: http://www.stuffandnonsense.co.uk
My book: http://www.transcendingcss.com/
Share:
| Malarkey wrote: |
|
As many types of assistive technologies utilise a web-browser (often IE), hiding content with display:none will hide it from screen readers too. |
not sure if that's true in all situations, though (i'm thinking labels for form elements, which i seem to remember do still work despite removing them from the normal content flow). may have to investigate further, chuck...
Patrick H. Lauke / splintered
Share:
The reason I ask is I'm not entirely sure how the form mode in JAWS and/or other screen readers work. I could always hide the text out of viewpoint as a fail-safe, I suppose, but I was just wondering if it would still understand the association of a legend to a fieldset, even if it is hidden.
Hmmmm. Guess I'll just have to find someone with a screen reader.
Share:
I just tried both of the following on JAWS 4.51 and the Legend was read out in both cases when forms mode was on... I'll do some more testing to be sure...
| Code: |
| <form action="foo" name="test" id="test">
<fieldset style="border: none;"> <legend style="display: none;">Search</legend> <input type="text" id="searchtxt"><input type="submit" value="Search" name="Search"> </fieldset> </form> |
| Code: |
| <form action="foo" name="test" id="test">
<fieldset style="border: none;"> <legend style="position: absolute; top: -100px;">Search</legend> <input type="text" id="searchtxt"><input type="submit" value="Search" name="Search"> </fieldset> </form> |
Share:
Download the JAWS demo and give it a go... 
Kajun
Share:
It seems that you've been busily adding fieldsets when they are not needed. The correct course here is to use HTML markup correctly which the screen readers can then interpret.
The fieldset tag is used to "divide a form into smaller, more manageable parts". If you have only one control in each form then the fieldset is not really needed. The power of this tag comes into its own when completing a LARGE form, breaking it up into smaller and more meaningful chunks.
I suggest that what is important to you, will be providing the link between the field labels and the order in which they appear.
Make sure you correctly use the <LABEL> tag. I regularly test with JAWS, WindowEyes and IBM Home Page Reader and all of these utilise the label tag.
If you use this format:
| Code: |
|
<label for="myinput">Password</label> <input type="password" name="password" id="myinput"> |
Then most browsers will provide focus into the control when the label is clicked. It is perfectly correct of course to do this:
| Code: |
| <label>Password<input type="password" NAME="password" ID="myinput"></label> |
As far as order goes then you can either ensure that the code, when linearized, displays the items in the correct order or you can utilise the "tabindex" attribute.
Hope this is of some help.
Share:
| GermanFred wrote: |
| If you have only one control in each form then the fieldset is not really needed. |
Quite, but if you're using a strict doctype you'll have to have some block-level element enclosing the labels and input elements, so why not use <fieldset>? In this case the <legend> is redundant, though.
Yes, you can use <div>, but is that 'better' than <fieldset>?
Some even like to use <p>, but I don't think that a label and an input element could be considered as a paragraph of text.
Tommy has left the building
Share:
Is form not a block level element? So you can't have a <form> <label><input (etc)> inside the <body> tag when you have a strict doctype?
How odd!
J
Share:
Yes, <form> is a block-level element. However, a <form> only allows other block-level elements as its immediate children.
Bad Example
| Code: |
| <form action="foo.php" method="post">
<label for="email">E-mail</label> <input id="email" name="email" type="text"> </form> |
Better Example
| Code: |
| <form action="foo.php" method="post">
<fieldset> <label for="email">E-mail</label> <input id="email" name="email" type="text"> </fieldset> </form> |
| orchid wrote: |
| So you can't have a <form> <label><input (etc)> inside the <body> tag when you have a strict doctype? |
The <body> element only accepts block-level elements in the strict DTD, which means you can have a <form> as an immediate child of <body>, but not an <input>.
Unless I'm reading the DTD wrong, you can have an <input> outside of a form, as long as it's within a block-level element (e.g. <p>). You cannot, however, have inline elements (such as <label> and <input>) as immediate children of <form>.
Tommy has left the building
Last edited by TOOLman on 15 Jul 2004 10:22 am; edited 1 time in total
Share:
See this thread for a bit of a tiff on forms Kajun
Share:
| TOOLman wrote: |
| Quite, but if you're using a strict doctype you'll have to have some block-level element enclosing the labels and input elements, so why not use <fieldset>? In this case the <legend> is redundant, though. |
I agree with TOOLman about FORM - it must contain a block level element but I'm not sure that FIELDSET is the right choice here. I suggest this for two reasons:
1. I quote the W3C,
| Quote: |
| The FIELDSET element allows authors to group thematically related controls and labels |
The fieldset is therefore to be used to group multiple fields, in this case their is only one.
2. The FIELDSET element must contain first a LEGEND tag, then may contain any inline or block-level element. In this case the designer is saying he doesn't need the LEGEND.
I agree that using <p> as the container would be wrong - it's not a paragraph, which leaves <DIV> or if tables are used for layout <TD> or <TH> perhaps?
Share:
| GermanFred wrote: |
| The fieldset is therefore to be used to group multiple fields, in this case their is only one. |
A list (<ul>, <ol>, <dl>) can contain a single list item and still be a valid list. There's nothing wrong with a fieldset containing a single input element.
| GermanFred wrote: |
| The FIELDSET element must contain first a LEGEND tag, then may contain any inline or block-level element. In this case the designer is saying he doesn't need the LEGEND. |
You're right. I forgot about that. No problem:
| Code: |
| legend {display:none} |
| GermanFred wrote: |
| I agree that using <p> as the container would be wrong - it's not a paragraph, which leaves <DIV> or if tables are used for layout <TD> or <TH> perhaps? |
I'll accept that a <div> could be equally good as a <fieldset> in this case. Equally good. Not better.
A <td> or <th> won't work. The <form> itself might be in a <td> or a <th>, but if you're going to use a table to lay out the form's contents (all of two elements in this case, so it's something of a stretch), the immediate child of the <form> would have to be a <table>. Then you could put the <label> in a <th> and the <input> in a <td>. For a single-control form I think that's much more contrived than a <fieldset>, but that's just me.
Tommy has left the building
Share: