RE: [techs] Re: collapsible hierarchical menu navigation javascript (accessible)

> -----Original Message-----

> From: James Craig [mailto:wai-wg@cookiecrook.com]

> Fentress, Robert wrote:

 

>>Even so, I'm not sure

>>about your choice to use input elements as list expanders. I would 

>>probably recommend anchors.

> 

> Let me expand on that a bit more. Using inputs indicates to screen

> readers that the user is in a form and that form input is expected. 

 

Maybe, but it was presented in a quite natural sounding way when
accessed using JAWS.  I didn't notice any usability issues.  I don't
think it is uncommon, or even necessarily improper, to use form elements
as interface elements in this way.  I could be wrong though.

 

> You also have no alt, title, or label on those

> inputs. How does a screen reader user know what their clicks are 

> supposed to do?

 

There is an alt attribute on the input image containing, initially, the
empty string.  This is appropriate in this instance, since, initially,
the input image is a spacer graphic and should be ignored.  It is
entirely non-functional and remains so in Netscape 4.x and similar
legacy browsers, simply displaying a bulleted list.  In browsers that
support DOM sufficiently, those input images are changed dynamically and
appropriate alt attribute values are assigned (and are read by JAWS).
Still, it would be better to assign the behavior after the page is
loaded, and I intend to make this change as per Richard Ishida's
suggestion.

 

> As for the onclick event on links, you can get consistent behavior,

> though it takes some extra work doubling up the onclick/onkeypress 

> events, checking for event.keyCode, and making sure the function does 

> not fire twice. Even with the extra work, I think it's a better
solution 

> than using a form element.

 

It strikes me as a judgment call.  Perhaps, if I have time, I will make
the adjustment you suggest, but I can't help feeling that it makes the
code more lengthy and convoluted to little effect.  As you noted, it was
well-formed according to the HTML validator and it seems to function
well.  I'd be interested in hearing if others find this a very
non-standard practice or can expand on what the problems might be with
using form elements this way.  Also, event.keyCode is (rather strangely)
listed as not being a part of the DOM in the O'Reilly JavaScript
Reference, and I was trying to keep it all DOM-based.  Anybody know
what's up with that?

 

Rob

 

P.S.  Sorry for sending this to you twice James.  I'm used to the reply
sending to the list.