RE: Technique 9.3.1 Check scripts for logical event handlers

I think it's fine for onmouseover and onfocus to have different things
happen with them. Mainly I think we want to call out pages that use
onmouseover, but do not use onfocus, and suggest that they duplicate the
event handler, since it doesn't hurt the page to do so. For Len's more
complicated example, I would not want to require that the two event handlers
already there have the same functionality, though if they do in fact do
different things we might trigger a manual question to regarding whether the
functionality of both is available in device-independent ways. I think this
will be a pretty rare situation though. Michael

-----Original Message-----
From: w3c-wai-er-ig-request@w3.org
[mailto:w3c-wai-er-ig-request@w3.org]On Behalf Of Leonard R. Kasday
Sent: Thursday, September 21, 2000 11:13 AM
To: Charles McCathieNevile
Cc: Chris Ridpath; WAI ER IG List
Subject: Re: Technique 9.3.1 Check scripts for logical event handlers


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/

Received on Thursday, 21 September 2000 13:49:25 UTC