Re: SVG 1.2 Comment: Accessibility: event handling

> WP>  This depends on how the AT got it's information, but that's
> WP> something for the AT vendors to sort out.
>
cl: > Apparently there is a move from 'screen scraping'ATs to 'DOM watching'
> ATs, which sounds like a good thing.

wp: Yes, for some applications.  Good, maybe, depends on the information 
available from the DOM and whether sufficient keyboard navigation is 
available to make the DOM information meaningful.  A good example would be 
document exploration, where spatial relationships, and thus spatial 
navigation not based on 'focusable', can convey meaning not readily 
available through the DOM.
>
> WP> I do agree, that some keyboard event examples would be good.  There's 
> a lot
> WP> of people who don't use mice for whatever reason, and keyboard 
> navigation,
> WP> especially for documant exploration, is a pre-requisite for 
> accessibility.
>
cl: > For 'mouse' (ie pointing device, we didn't choose the name) events, 
any
> pointing device which can give a position will work. That can mean a
> mouse, a trackball, stylus, pen, jog dials, foot pedals, cursor keys,
> eye trackers on anything you want basically that has a moveable
> position.

Chris, are you referring to cursor keys as an alternative to mouse pointer 
movement, or in the context of cursor keys moving direct from graphic 
element to graphic element?  For blind users, moving the mouse pointer would 
result in a "hunt and peck" type interaction, where the user can't move 
efficiently between graphic elements as they can't  identify which way to 
move the mouse pointer.  If it's moving between graphic elements, then I'm a 
happy bunny *smile*.

Will

Received on Monday, 22 November 2004 17:56:41 UTC