- From: Leonard R. Kasday <kasday@acm.org>
- Date: Mon, 05 Jun 2000 17:53:46 -0400
- To: Charles McCathieNevile <charles@w3.org>
- Cc: w3c-wai-ig@w3.org
As Charles indicates, this discussion keeps reappearing. I just want to try again to make a point which I guess I didn't get across in earlier discussions. The point is this: "focus" cannot logically be made the same as "mouseover" That's because "focus" is keyboard focus: the object with keyboard focus is the object that will get keyboard events. wherease "mouseover" is MOUSE BUTTON focus: the object with mouse button focus is the object that will get mouse click events. For example, if my text cursor is in a text field, that text field has keyboard focus, but I can move the mouse over a link. e.g. for purposes of clicking on that link. When I move the mouse over that link, I'm giving the link mouse focus without disturbing the keyboard focus. Thus, any solution which to make focus and mouseover the same will deny full functionality to people who are not using a mouse (or mouse equivalent). This is because if the user has just one focus, s/he will lose his/er keyboard focus when moving the single focus to where mouse focus is needed. And visa versa. Whats really needed is separate keyboard control of mouse focus, either in the user agent, or in the assistive technology attached to the user agent. Len At 05:36 PM 6/5/00 -0400, Charles McCathieNevile wrote: >The story (as far as I understand it, and I have been following it for a >couple of years now) goes like this: > >javascript effects do not reliably work in all browsers. So it is important >not to rely on Javascript for function. There are two parts to this. One is >to do as Len suggested, and provide a server-side equivalent (for example >form validation can be done on both sides). The other (especially where there >is no real functionality added to the page, for example in a mouseover >highlight, is to add a focus event - most good browsers will allow the user >to focus an element via the keyboard, and functionally a mouseover is >equivalent as a user behaviour, although for historical reasons the language >support for this is fairly poor (HTML provides fair to appalling support for >this aspect of accessibility and browser implementations tend to fall a >little short of that. Sigh. I am pleased to note that there are great >improvements in the model being used by the Scalable Vector Graphics >language, although I am waiting to see the implementations at work). > >Charles McCN > >On Mon, 5 Jun 2000, Leonard R. Kasday wrote: > > There was a thread back around the beginning of april about text menus > that > popped up when the mouse passed over them (the celebrated "mouseover" > action), and how to make them accessible. The discussion seemed to end at > http://lists.w3.org/Archives/Public/w3c-wai-ig/2000AprJun/0015.html > without an answer. > > There's a simple way to make a functional equivalent of mouseover on a > object if there isn't something already defined for clicking on that > object. Just make that object a link so when you click on it it brings up > a new page with content equivalent to what pops up with the mouseover. > > What if the button already does something, say it's a link and the > mouseover brings up summary info that helps you decide if you want to > click > that link? In that case you could have an additional link you'd click to > bring up the info. Similar to a D link. Perhaps an "M" link? You could > make the "M" links visible or not under control of a style sheet. Also, > the page brought up by the M link would have a link to what clicking on > the > original object would have produced. > > Instead of an M link you could have a transparent image to which you could > add appropriate alt text. Hmm... - except a transparent image wouldn't be > suitable for sighted people with motor disabilities. > > Of course, you also have to be sure the average user knows about this > stuff. > > There's also the long description but that may be used for other stuff and > isn't yet implemented on all browsers. > > Len > -- > Leonard R. Kasday, Ph.D. > Institute on Disabilities/UAP, and > Department of Electrical Engineering > Temple University 423 Ritter Annex, Philadelphia, PA 19122 > > kasday@acm.org > http://astro.temple.edu/~kasday > > (215) 204-2247 (voice) (800) 750-7428 (TTY) > > The WAVE web page accessibility evaluation assistant: > http://www.temple.edu/inst_disabilities/piat/wave/ > > >-- >Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 >W3C Web Accessibility Initiative http://www.w3.org/WAI >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053 >Postal: GPO Box 2476V, Melbourne 3001, Australia -- Leonard R. Kasday, Ph.D. Institute on Disabilities/UAP, and Department of Electrical Engineering Temple University 423 Ritter Annex, Philadelphia, PA 19122 kasday@acm.org http://astro.temple.edu/~kasday (215) 204-2247 (voice) (800) 750-7428 (TTY) The WAVE web page accessibility evaluation assistant: http://www.temple.edu/inst_disabilities/piat/wave/
Received on Monday, 5 June 2000 17:52:41 UTC