W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2000

RE: Seeking guidance...

From: Leonard R. Kasday <kasday@acm.org>
Date: Mon, 10 Apr 2000 16:33:39 -0400
Message-Id: <4.2.2.20000410155550.00a32ac0@pop3.concentric.net>
To: "Bruce Bailey" <bbailey@clark.net>, <david@davidsaccess.com>
Cc: <w3c-wai-ig@w3.org>
 > The issue raised on http://www.att.com would be addressed by
 > guideline 6.2,
 > make the users aware of dynamic content. It should not be on the AT vendor
 > to account for it.

Well, if we look at 6.2 literally it says

  "Ensure that equivalents for dynamic content are updated when the dynamic 
content changes."

The AT&T site changes the alt text when the content changes.  So it's 
fulfilled 6.2.  The problem is that existing browsers and screenreaders 
don't communicate that to the user at least with lynx.

Now actually 6.2 probably meant something else since it says to ensure that 
pages are accessible when newer technologies are not accessible or turned off.

So we've got a problem here.   AT&T tried to do the right thing here it 
seems to me, but our AT doesn't take advantage of it.  Ideally, we need 
both content and AT to contribute.  But we're not there yet.  So in the 
meantime, content providers need to figure out some other way of showing 
the extra content.  Perhaps in the long description or d link?

In other words, we need a feature like when screenreaders automatically 
read popups in non-web programs.



> > I also think that mouseover and onfocus are synonymous.


I don't think so... see the thread "General Input Model".    Logically, "on 
focus" is really "on keyboard focus", i.e. when an object has keyboard 
focus something happens to it when the you press buttons on the 
keyboard.  "On mouseover" is really "on mouse focus"; i.e. when an object 
has mouse focus something happens when you press buttons on the mouse.  In 
both cases, events like popups can happen when an object gets focus, even 
if nothing is clicked.

Sometimes you can tie these two types of focus together.  But it can at 
other times be convenient to keep them separate. For example, you could 
have screen with your text cursor in a text field... i.e. you give that 
text field text focus... while you move the mouse focus over some help 
objects to get help.

If the mouse focus was tied to the keyboard focus so you just had one 
"focus", you'd have to move that focus over to the help objects and then 
move it back again, but that's extra time, especially when you're moving 
the mouse focus without an actual mouse.   In some jobs, every second counts.

It's similar to why with screenreaders there's a screenreader cursor that's 
separate from the application cursor. You could imagine operating things 
with just one cursor, but it would be really tedious.

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)
Received on Monday, 10 April 2000 16:33:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:48 GMT