- From: Leonard R. Kasday <kasday@acm.org>
- Date: Thu, 21 Sep 2000 17:28:28 -0400
- To: Charles McCathieNevile <charles@w3.org>
- Cc: Chris Ridpath <chris.ridpath@utoronto.ca>, WAI ER IG List <w3c-wai-er-ig@w3.org>
- Message-Id: <4.3.2.7.2.20000921164930.02c11c20@pop3.concentric.net>
Charles,
I want to make sure I understand what you said. For example, somewhere on
the page there's box containing the abbreviation XYZ and two text fields,
inside a box, represented in ASCII art as
+----------------------------+
| XYZ [ ] [ ] |
+----------------------------+
There are say, 100 of these boxes on the page.
The sighted user sees the full name of the company (Xenotrop Young and
Zoe, Inc) popup when when the text cursor is
in either of the text fields
A graph of XYZ's stock price pops up when the mouse is over any part of the
box.
What do you mean by "make this a focus element on the boxes"? I'm
somewhere above this box, what happens as I press the tab key? Does say
"the box" get focus, then the first field gets focus, then the second field
gets focus?
If so, that gives similar problems to making just XYZ sensititive to
mouseover or focus, viz, as you tab though the page Also,
the graphs keep popping up, annoying people without disabilities,
distracting people with some cognitive disabilities, increasing 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.
I think we need to have a mouse cursor that steps through all mouse
sensitive elements under control of the user, via the user agent. E.g.,
something like the Jaws cursor in Jaws, which always moves the mouse
pointer to its location, and the similar things in the other screenreaders,
window eyes, etc.
Something close to this is already in the user agent guidelines:
In 5.4 it says to " provide access to information about the user agent's
current input configuration so
that assistive technologies can trigger functionalities
through keyboard events, mouse events, etc. " [1]
All I'm adding here is some sort of quick ways to get to the objects that
are mouse sensitive.
So the proposal would be to add this feature to the user agent guidelines,
and make the requirement for focus equivalents apply only "until user
agents" do this.
Shall I sent this off as a request from ER?
Len
[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000901/#gl-accessible-interface
Len
At 11:34 AM 9/21/00 -0400, Charles McCathieNevile wrote:
>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
--
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 17:26:22 UTC