- From: Charles McCathieNevile <charles@w3.org>
- Date: Thu, 21 Sep 2000 11:34:50 -0400 (EDT)
- To: "Leonard R. Kasday" <kasday@acm.org>
- cc: Chris Ridpath <chris.ridpath@utoronto.ca>, WAI ER IG List <w3c-wai-er-ig@w3.org>
Actually, I would make this a focus element on the boxes, which may or may not be triggered as a mouseover. For keyboard efficiency you should use a keyboard-relevant solution, for example a "jump 10 steps/onepage/some other amount/some structure piece". Since I can't think of another keyboard interface that makes the thing accessible, and generalises. To make this editable, being able to remap the focus from mouseover / moving the cursor to rightclick/active focus key/ etc, is much better than simply having to drop the function from any would-be WYSIWYG editor (witness the problems dealing with Javascript in Mozilla's editor...) I believe that this provides a device-independent way of working, by moving away from mouseover as a mistaken confusion of the action (mouseover) with the behaviour (focus). In a better language we would simply replace the mouseover, but we don't have a better language yet. Charles On Thu, 21 Sep 2000, Leonard R. Kasday wrote: Here's another example of why we need to make mouseover independent of focus. Imagine a stock trading page. Lots of stock boxes. Each box contains 3-letter abbreviation of stock, and two text fields follow each: one for buy, one for sell. When field gets focus, full name of comany appears, as safety factor in case you remembered abbreviation wrong. Another feature: when you mouseover anywhere in any stock box, either on the abbreviation or the text fields, a graph of past weeks prices, and/or other information pops up.. So trader can wipe mouse over page, quickly looking at graphs that pop up, looking for good deal. If we try to make mouseover same as focus we run into problems. First of all, as described here, different things happen depending on whether text box gets mouseover or focus. So you simply can't make mouseover and text focus the same without modifying the interface. Now, you could modify the interface, so that you only get the popup graph when you mouseover the abbreviation, not when you mouseover the text box. Then you just have to make mouseover equal focus for the abbreviations. However, besides making it a bit less convenient for person with no disabilities, it makes it worse for a person with a motor disability that makes mouse pointing less precise. Also, this forces you to make abbreviations accept focus, which means that as you tab though the field these graphs keep popping up, annoying people without disabilities, distracting people with some cognitive disabilities, doubling the number of keystrokes for people with motor disabilities, and creating speech clutter for people who are blind. Plus putting a extra load on the server. So it would be better to give use independent control of the so-called mouseover. As I indicated, I don't know of any page that works like this... I just made it up. But I think it shows a plausible case where independent focus and mouseover is needed, and there will likely be others, given the zillions of people creating new pages every day. What what do you'all think? Shall we ship this as an open issue to WCAG? Len Hmmm. I wonder if anyone will actually want to build this interface... well, just in case... I hearby declare this stock trading interface Copyright (c) 2000... if you want to use it commercially give me a call to discuss royalties .. this does not apply to accessibility accommodations of course. At 08:00 AM 9/21/00 -0400, Charles McCathieNevile wrote: >If we don't require it then we are deviating from WCAG, which is a bad step >on the loss of interoperability of W3C specs path. (In particular, it would >mean that the AU group, which relies on WCAG by reference, would have to work >outside the AERT). If indeed this is unnecessary then the first requirement >should be to suggest so to WCAG. > >So much for process. > >Where there is a stylistic change caused by a mouseover, it is done as a way >of providing an effect when the user is focussed on the event. There is no >good reason why this should be restricted to mouse users. In particular, this >is often used to draw attention to something - that has value for a number of >different types of users. As content becomes better written, we can expect >more such effects, and more of them to use generally accessible features like >CSS changes (this is how it is done using SMIL/SVG animation). > >If there are examples where a mouseover and a focus event do different >things, then I have yet to discover it. They may have different meanings in >specification, but the first is a subset of the latter in most user interface >design for the web. (For Operating systems, by contrast, single-click takes >the place of mouseover for certain types of objects, but not others). > >Charles McCN > >On Wed, 20 Sep 2000, Leonard R. Kasday wrote: > > I think, and I'd guess this agrees with what Chris had in mind, that > no, we > don't need a mouseover replacement there. > > This brings up another problem though. > > What if an object already has both a mouseover and an onfocus event? They > are logically different after all. > > Simply replacing the onmouseover with onfocus doesn't work in that case. > > Len > > At 03:31 PM 9/20/00 -0400, Chris Ridpath wrote: > >Do ALL device specific event handlers (e.g. OnMouseOver) require > replacement > >with device independent handlers (e.g. OnFocus)? > > > >Many pages use OnMouseOver to change the appearance of buttons on the > page. > >This is a small change in appearance and does not affect the functionality > >of the page if it's missing. Should we require that these pages add an > >OnFocus handler as well as the OnMouseOver? > > > >Chris > > -- > Leonard R. Kasday, Ph.D. > Institute on Disabilities/UAP and Dept. of Electrical Engineering at > Temple > University > (215) 204-2247 (voice) (800) 750-7428 (TTY) > http://astro.temple.edu/~kasday mailto:kasday@acm.org > > Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group > http://www.w3.org/WAI/ER/IG/ > > 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, Australia >September - November 2000: >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, >France -- Leonard R. Kasday, Ph.D. Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple University (215) 204-2247 (voice) (800) 750-7428 (TTY) http://astro.temple.edu/~kasday mailto:kasday@acm.org Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group http://www.w3.org/WAI/ER/IG/ 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, Australia September - November 2000: W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Thursday, 21 September 2000 11:37:01 UTC