- From: Chris Lilley <chris@w3.org>
- Date: Fri, 19 Nov 2004 19:30:36 +0100
- To: "Will Pearson" <will-pearson@tiscali.co.uk>
- Cc: "Jonathan Chetwynd" <j.chetwynd@btinternet.com>, "SVG (www) list" <www-svg@w3.org>, "dean Jackson" <dean@w3.org>
On Wednesday, November 17, 2004, 4:21:16 AM, Will wrote: WP> Hi Jonathan; WP> The problems with scripted menus results from access technology being WP> unaware that the screen has been updated by some Java script. Yes. This is why we ave mutation events, and why we don't have immediate mode graphics like <canvas>. WP> I think, that if all changes were to be placed in the document model, and WP> the SVG ua handle exploration of the SVG document, then there wouldn't be WP> any problems. Right. WP> This depends on how the AT got it's information, but that's WP> something for the AT vendors to sort out. Apparently there is a move from 'screen scraping' ATs to 'DOM watching' ATs, which sounds like a good thing. 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. 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. Similarly for text input, anything that gives a text string can be used - a keyboard, an IME, an on screen virtual keyboard, speech recognition, whatever. Anything that generates a unicode string. Compared to DOM2, where the exact keys and shift states and etc were tracked, DOM3 just tells you that the text has been entered. You can then look at particular key states if they happen to be relevant. WP> Will WP> ----- Original Message ----- WP> From: "Jonathan Chetwynd" <j.chetwynd@btinternet.com> WP> To: "SVG (www) list" <www-svg@w3.org> WP> Cc: "dean Jackson" <dean@w3.org> WP> Sent: Tuesday, November 16, 2004 1:25 PM WP> Subject: SVG 1.2 Comment: Accessibility: event handling >> >> Dean, >> >> The continued use of mouse events in examples as for instance: >> http://www.w3.org/TR/SVG12/painting.html#overlay-example >> is a concern. This example particularly relevant as there has been >> lengthy and unresolved discussions around accessible drop down lists in >> the html/css/script communities. The example appears to assume mouse >> skills, together with drag skills, which many find difficult to >> impossible*. >> >> Would it be helpful if there was a more detailed explanation of event >> handling in the SVG1.2 document with an example, maybe using a keyboard >> to navigate a drop-down list? >> >> if so, could we please up date this and other examples to demonstrate >> the improved XML event handling being offered? >> http://www.w3.org/TR/SVG12/events.html#handler-element >> >> regards >> >> Jonathan Chetwynd >> http://www.peepo.co.uk "It's easy to use" >> irc://freenode/accessibility >> >> *It is also not coherent, as one cannot make a selection, the mouse >> must be down to see the list. >> perhaps onmouseover, with option to click for list, with an X to >> dismiss, and click again to select. >> plus keyboard access. >> drop down lists aren't a simple concept, so one cannot expect to have a >> simple demonstration, that is accessible. >> >> >> -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Received on Friday, 19 November 2004 18:30:38 UTC