Re: SVG 1.2 Comment: Accessibility: event handling

Chris,

I'm more than a little concerned regarding the accessibility of current 
SVG user agents, and question why this lack of progress is not 
informing the development of the current 1.2 specification.

You state: "any pointing device which can give a position will work."
this assertion is easy to make, but perhaps harder to obtain.

In a recent exchange on irc:mozilla/svg it was suggested that "svg1.1 
does not specify key events", which in it's way is true.
(the implication being that therefore it is not a requirement.)
UAAG states:  " Ensure that the user can operate, through keyboard 
input alone, any user agent functionality available through the user 
interface" .
This may partly be explained by the rather ineffective: "an SVG user 
agent should conform to UAAG." - should - may have been intended as 
sufficient, but in this instance the flesh is weak, as we are now some 
years late.
asv is no better, as the transition from browser to viewer is broken, 
and the number of keyboard navigable pages ~=0.
  - It maybe that there are other UA that have keyboard access, please 
advise me. -

The significant change in event handling is not reflected in the 
current UAAG or indeed the overdue SVG Accessibility AT and UA 
guidelines. Does the 1.2 specification indicate the significance of 
accessibility in an appropriate manner, given the response to the 1.1 
guidelines, bearing in mind the lack of progress on updating these 
accessibility guidelines. It isn't possible to refer to them, because 
they don't exist, and furthermore there haven't been usability studies 
to inform their development.

perhaps 'must' would be more appropriate than 'should', or perhaps more 
realistically significant efforts could be put into exploring and 
demonstrating the potential benefits of (input event) accessibility, 
which currently remain theoretical.

regards

Jonathan Chetwynd
http://www.peepo.co.uk     "It's easy to use"
irc://freenode/accessibility
On 19 Nov 2004, at 18:30, Chris Lilley wrote:

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 20:15:40 UTC