Re: Keyboard Navigation For Document Exploration In SVG 1.2

I spoke to Gregory briefly last night. I think the main point for our chat
(other then just being good to chat to him)  was what is needed is an
ability to switch granularity. In other words, to zoom in in the details and
then take a step back,(whilst staying were you are) and look around, and
then see detail.

Take for example an SVG subway map. You want to go to station X, so look at
station x for details, is it accessible? Does it have an accessible
bathroom. If the answer is no, then I would want to switch granularities,
and be able to navigate around the different stations. When i get to a
station I know is close, then i would want to zoom in and get information.

So the proposal would be like ctr arrow up would switch granulates up.

But there is little point to that because there is not the supporting the
language to support the concepts behind it.

Basically it comes down to the lack of semantic information , and the need
for identification and integrity of blocks of content and to know what they
intend to be, and what state they have, and relationships with other
content.

It was very similar for the need of content and concept zoom that i
suggested for Math ml, SVG and XHTML. Where you can identify on concept as
being part or a conceptual zooming in of another section of content.

At the moment we can do this with RDF, but it would be much easer to promote
if the languages themselves supported it.

Lisa



----- Original Message ----- 
From: "david poehlman" <david.poehlman@handsontechnologeyes.com>
To: "Lisa Seeman" <lisa@ubaccess.com>; <wai-xtech@w3.org>; "Will Pearson"
<will-pearson@tiscali.co.uk>
Cc: <oedipus@hicom.net>
Sent: Tuesday, November 23, 2004 3:16 PM
Subject: Re: Keyboard Navigation For Document Exploration In SVG 1.2


> Lisa,
>
> It is possible with anything to get lost, but it is also quite possible
for
> people who have a good memory of spatial things such as myself and
possibly
> will and many others that this would be a usefull tool.  AS to where it
fits
> in the scheeme of things with respect to ua, at or svg spec is something
to
> be hashed out but keyboard exploration of diagrams needs to be enabled for
> without it, we are lost.
>
> It would be interesting to hear Gregory's thoughts, I do think though that
> there is a good deal of research behind the possibilities of this working
> though.
>
> Johnnie Apple Seed
>
> ----- Original Message ----- 
> From: "Lisa Seeman" <lisa@ubaccess.com>
> To: <wai-xtech@w3.org>; "Will Pearson" <will-pearson@tiscali.co.uk>
> Cc: <oedipus@hicom.net>
> Sent: Tuesday, November 23, 2004 1:51 AM
> Subject: Re: Keyboard Navigation For Document Exploration In SVG 1.2
>
>
> My concern is that you would get terribly lost.
>
> But is anyone thinks this might be useful, and could do it ,  it would be
> Gregory Rosmaiter. So I am cc'ing him.
> I will also try and ask him.
>
> Keep well
> L
>
>
>
>
>   ----- Original Message ----- 
>   From: Will Pearson
>   To: wai-xtech@w3.org
>   Sent: Monday, November 22, 2004 10:38 PM
>   Subject: Keyboard Navigation For Document Exploration In SVG 1.2
>
>
>   Hi;
>
>   At the moment there's no clear indication within the spec that document
> exploration should be made available through a ua's keyboard interface.
> Whilst most people will be able to visually explore the image, this won't
be
> possible for some users, and may not be possible for others.  Therefore, I
> would like to suggest that some form of navigation between container
> elements and graphic elements be recommended as a guideline for ua
> developers.  This should facilitate exploration of the document away from
> any elements with 'focusable' set to true, or active elements with
> 'focusable' set to auto.
>
>   Ideally, this would be based on spatial direction, thus allowing the
user
> to build up a mental model of the spatial relationships between elements.
>
>   The spec already makes provision for a range of alternative pointing
> devices, through DOM 3 I think, but I think we need something a bit more
> granular than a pixel by pixel movement typically offered by pointing
> devices.  The main reason for this, is that the HCI task analysis for
moving
> two points require the user to know where the pointer is in relation to
the
> target.  This can be done with speech, and there's an event in JAWS to
> handle this, but having experimented with this on a small number of users,
> doing the math necessary to work out the relationship between pointer and
> target raised the cognitive workload, as measured by the NASA-TLX test,
> quite significantly.
>
>   So, I propose the following eight keys to facilitate document
exploration
> within a ua:
>                              I.       Up (337.5º - 22.5º)
>
>                            II.      Diagonally up and right (22.5º -
67.5º)
>
>                           III.       Right (67.5º - 112.5º)
>
>                        IV.       Diagonally down and right (112.5º -
157.5º)
>
>                          V.       Down (157.5º - 202.5º)
>
>                        VI.       Diagonally down and left (202.5º -
247.5º)
>
>                       VII.       Left (247.5º - 292.5º)
>
>                     VIII.      Diagonally left and up (292.5º - 337.5º)
>
>
>
>   Each of these keys will be responsible for moving to the nearest element
> within a 45º arc, as listed above.
>
>   Will

Received on Wednesday, 24 November 2004 09:10:04 UTC