RE: Seeking guidance...

I don't think we have a problem - AT&T have done exactly what is asked for in
checkpoint 6.2 (and a couple of others). The problem that it can't be used in
all browsers is addressed by checkpoint 6.4 - ensure that pages work when
scripts and applets are not supported...

Charles McCN

On Mon, 10 Apr 2000, Leonard R. Kasday wrote:

   > 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)
  

--
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
Postal: GPO Box 2476V, Melbourne 3001,  Australia

Received on Friday, 14 April 2000 09:36:04 UTC