[thesite] [html] accesskey and form id attributes

[aardvark]

> From: martin burns <martin at lists.evolt.org>

i'm only replying to the list, since cc'ing everyone along with this is just 
silly... i also haven't seen the original message yet...

> >Are we assigning accesskeys to *all* form elements?
> 
> We should be

no.  not all form elements can take the accesskey attribute.

http://www.w3.org/TR/html4/interact/forms.html#h-17.11.2
"The following elements support the accesskey attribute: A, AREA, 
BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA."

also, if we can't demonstrate what the accesskey is, then we shouldn't use 
it... for instance, the select menu at the top of every page (which cannot 
accept 'accesskey' anyway since it is a select menu) would not have one 
since there is no label to indicate what it would be... also, the textareas 
that encapsulate <pre> blocks should not, given their use...

c'mon guys, there's usually a reason why i do things... even if it's lame...

> >Do we have a standard
> >for picking the key?
> 
> We should be

yes... in order to to truly satisfy usability and accessibility requirements, 
*every* form element should be addressed, and should be addressed in 
every possible configuration... that being said, we do not have the 
resources to do that... if an element appears on one page with another 
element, but without it on yet another page, that can be problematic when 
assigning accesskeys since you may need to address it on a view-by-view 
(not page-by-page) basis to avoid doubling up or assigning inappropriate 
ones...

as a perfect example, somebody completely failed to notice that the 
comment textarea already had an 'a' assigned as its accesskey, which 
competes with the 'a' assigned to the article search... that's bad... and an 
example of why this can be difficult to maintain... read end of message for 
my recommendation on how to fix this...  assigning accesskeys is not an 
easy process, and user testing should really be done on a case-by-case 
basis... something we aren't prepared to do...

in addition to all this, you can truly only have about 26 accesskeys on a 
page, and then that's assuming that every form element has a label with a 
letter of the alphabet not being used elsewhere, or one of the remaining 
letters... after all, what form element might have 'q' in its label?

oh yeah... some are reserved, too... for instance, on a logged-in page, 'a' 
and 'u' are already taken (where did that double search pop up?  didn't see 
that until just now)... on a non-logged in page, 'l' is taken, in addition to 'a'... 
frankly, i had not foreseen a breakdown of the search into two fields, so ya 
got me there...

aw jeez... and then how do you assign an accesskey when you can't style 
an underline? like on buttons?

are y'all getting my drift here?

> >Some forms have both the "name" and "id" attribute and some don't. Should we
> >be adding the missing piece to the forms that don't have both?
> 
> Yes.

all form elements should have an 'id' attribute... if form elements contain 
none, then that's an error on implementation... the 'id' should match the 
'name', which will also make it much easier when <label>s are assigned...

> I really think that unless there's a good reason, we should be implementing
> WAI recommendations. Push back on a case-by-case basis if you don't
> agree.

read all above.

from above... the comment field was not built with a subject field in mind... 
as such, assigning an accesskey of 'a' is no longer appropriate... since 's' 
is no longer reserved for search (which was one field in design, not two), 
remove the underline from "_A_dd your comment:" (as well as the label) 
and re-assign them as such:

"Subject for your _c_omment?"
- 'c' should be the accesskey, and there should be a <label> as well giving 
focus to the input box... you can use 's' and apply it to 'Subject', but we 
may need the 's' elsewhere...

"Share your _o_pinion:"
- 'o' should be the accesskey, and the <label> from 'Add...' should be 
moved to here...