RE: Seeking guidance...

Dear Len,

I agree that www.att.com has TRIED to do the right thing (expect they didn't
take into account scripts being disabled).  With that example, I also agree
that the fault would seem to lie with limitations of screen readers rather
than deficits with the page.  (In defense of Henter Joyce et. al, how many
pages bother to change ALT content with onMouseOver though?)

Most average computer users are quite confused by the presence of TWO
cursors (one for mouse, one for keyboard).  I have frequently seen novices
position the mouse cursor over a text field and start typing (mind you, they
have not "clicked") -- and are quite confused as to where their keystrokes
are going.  A similar thing happens with long word processor documents:  the
person scrolls to the end of the document (still no click INSIDE the
document) and starts typing -- the GUI usually jumps back to the beginning
of the document!  I have no idea how to fix this kind of difficulty, except
to teach the user about what the interface is expecting of them.

From the point of web pages, despite that it might in some unusual
circumstances be helpful to have separate and distinct keyboard and mouse
focus, focus should be dynamic, fluid, and intuitive.  If a person starts
tabbing, onFocus should follow the keyboard.  If they start moving the
mouse, focus leaves the item selected by the keyboard and SHOULD move to the
first onMouseOver object.

If onFocus is REALLY suppose to be onKeyboardFocus -- fine, but then we need
a third (device neutral) term that encompasses both keyboard AND mouse.
(And, in that case, onFocus SHOULD be renamed onKeyFocus or something.)

-- Bruce


> -----Original Message-----
> From: Leonard R. Kasday [mailto:kasday@acm.org]
> Sent: Monday, April 10, 2000 4:34 PM
> To: Bruce Bailey; david@davidsaccess.com
> Cc: w3c-wai-ig@w3.org
> Subject: RE: Seeking guidance...
>
>
>  > 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

Received on Tuesday, 11 April 2000 09:49:03 UTC