- From: Will Pearson <will-pearson@tiscali.co.uk>
- Date: Mon, 22 Nov 2004 17:36:23 -0000
- To: "Chris Lilley" <chris@w3.org>
- Cc: "Jonathan Chetwynd" <j.chetwynd@btinternet.com>, "SVG \(www\) list" <www-svg@w3.org>, "dean Jackson" <dean@w3.org>
> 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