W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2003

Re: Forms

From: David Woolley <david@djwhome.demon.co.uk>
Date: Tue, 17 Jun 2003 21:35:41 +0100 (BST)
Message-Id: <200306172035.h5HKZfr01697@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

> as <name>: I have always set "name" and "id" as the same thing.  But what I'm 
> not clear on is which property a screen reader would read.  

None of them.  It should read the contents of the label element, i.e.
"_L_ast Name" in your example.  As others have said, the label element
is correlated by matching its "for" attribute with the control's "id" 
attribute.

Also, in an ideal world the L should be highlighted by using 

label[accesskey]:first-letter

as a CSS selector, with the accesskey on the label rather than the
control, not by presentational markup.  However, I'm not sure how well
:first-letter is supported and [attribute] is supported on Gecko, but
not IE.

As discussed elsewhere, an alt attribute is pointless in this context,
although might be justified on the form element itself.

A fully compliant browser would ignore the <br>, but graphical ones
tend to treat it as a hard newline rather than the correct line break.
I think that support for styling is adequate to do this with styles.
Lynx, although not supporting styles, defaults to treating <br> as a
line break, so will probably not leave a gap - depends on how it
handles legend.  <br> might be valid if your intention is to produce
sensible formatting on a browser that doesn't understand <legend>.

> I am also having trouble getting the alt tag to work.

Not suprising as there is no alt tag in HTML!
Received on Tuesday, 17 June 2003 16:38:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:10 GMT