WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: tables and forms

for

From: Paul Bohman
Date: Oct 19, 2001 12:28AM

[Paul]
1. Table Headers don't work properly in JAWS if there are
rowspans or colspans
[Leo]
does this apply to <th> cells that use colspan or rowspan (ie, <th
colspan="2">), or does it refer to the use of any colspan or
rowpsan attributes anywhere in the table.
My reply:
There is an example of a table on the WebAIM web site that would be read
incorrectly by jaws. You can find it at http://www.webaim.org/howto/tables3.
Even if you had perfect markup, JAWS would read the table incorrectly. In
this table, there is a rowspan on the first column, but there are no rowspan
or colspans on the header (<th>) row. If you have additional questions after
looking at the example, feel free to ask.
[Paul]
With the labels properly marked up, you could, in theory, place the
labels anywhere at all on the page, and the label would still be
associated with the correct form element.
[Leo]
Is it OK to place the label after any form element, not just after
radio buttons and check boxes. Also, is it acceptable to use the
submit button as a label, as long as the submit button has text
descriptive of the form field as its value, such as "search":
For example,
<input type="text' size=19 id="search">
<label for="seach"><input type="submit" name="submit"
value="Search"></label>
My reply:
In general, it is best to put the label first, but not absolutely necessary.
When you put the label first, the label will be read in sequence before the
input element. This makes sense. Older screen readers, which do not
recognize the <label> tag, will especially benefit from this. Modern screen
readers do recognize the <label> tag. However, if you just listen to a form
sequentially (without using the tab key to go from one input element to
another), there is no added benefit to using the <label> tag. The document
is read in sequential order. It is only when tabbing through a form that the
true benefit of <label> tags can be seen. When you tab through forms that
have <label> tags, the screen reader will automatically read the label,
along with the input element. Even if the label is on the opposite side of
the page, the screen reader will read the label correctly. Still, as I said,
if you are not tabbing through the form, then the screen reader reads things
in sequential order, which means that labels that are not adjacent to their
input elements may not be read in a way that allows the listener to
associate them.
But your questions asks if it is ok to put the label after the input
element. The answer is this: yes it is ok, but it is slightly less friendly
for someone who is listening in a linear fashion, rather than tabbing
through the form. They will hear "text input" and then, if they allow the
reader to keep reading, they will hear the label "First name" (or whatever
the label is). Sometimes this can be a little disorienting, because we like
to hear the label first usually. If you put the label tag there, and if the
person is tabbing through the form, they will hear this: "First name; text
input." It is a little friendlier, but not necessarily more "accessible" in
the strictest sense.
The general rule is to put the label first, but it is not a hard or fast
rule. No matter what, I would still recommend putting the label adjacent to
the input element, whether before or after. Also, make sure that you are
consistent. Try not to alternate between labels before and labels after form
elements. The one possible exception is when using checkboxes or radio
buttons. The preference is to put the labels AFTER these types of input
elements. The same potential drawbacks occur with the reading order being
reversed, but the convention is still to put the labels after these types.
And, as Kynn mentioned, you might consider using drop-down boxes instead of
radio buttons, to ensure comprehension of the form.
[Leo]
Similarly, can one do the same with an image used as a submit
button, if that image has alt text descriptive of the form field:
For example,
<input type="text' size=19 id="search">
<label for="search"><input type="image" border="0"
name="searchbutton" src="images/buttom_search.gif" width="60"
height="22" alt="search"></label>
My reply:
I have done this before, but even experienced JAWS users complained that
they were confused at this. When listening to a form, you don't know how
many input elements there are until you reach the end of the form. It's hard
to tell at first whether it is a long form or just a simple search function
with one text input and one submit button that says "search". The user may
hear the "text input" and no label and think "oh, great. What am I supposed
to do here?" Of course, if that person keeps listening, the next thing will
be the submit button, and then they would know what to do, presumably. All
things considered, I would recommend putting the text label there (with
correct <label> tags) whenever possible, to reduce this kind of confusion.
Is a form totally inaccessible if you just have a text input with a button
that says "search"? No, it's not totally inaccessible, but it can be
confusing.
Another issue: some previous versions of screen readers did not read the alt
tags of images used as form submit buttons. That's something to consider.
Modern screen readers handle them well enough.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu



---
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/