Re: svg and events

At 05:46 AM 2002-03-12 , DPawson@rnib.org.uk wrote:
>I'm puzzling over a methodology to approach
>designing SVG in an accessible manner.

This is a good topic.  Thank you for kicking this discussion off.

>
>My principles to date are:
>
>1. document order to match 'described' order,
>i.e. logical progression from overview down to detail.

In general this cannot be done.  You have to use the define/use cycle in SVG to first provide text in some plausible narrative order and then reference the text in the encoded drawing structure which is not a linear order but a hierarchical scene graph.  It is not practical to try to force the 'g' drawing group hierarchy into a narrative order.  The prior declaration of the text in narrative order can be in an embedded foreign object in XHTML Basic, for example.

>2. Each document entity to be wrapped in a g element,
>   with min of desc and otionally both title and desc children.

That is to say each distinct scene object of enough conceptual significance to be mentioned in the description.

Catch:  The 'g' drawing groups are part of the strict XML hierarchy.  The conceptual objects one wishes to describe form a general Venn diagram -- not a strict hierarchy.  There are intersecting groups in the display that have both common and distinguished sub-elements in them.  So some of the notional elements may have to be documented as collections of drawing groups, presumably via RDF in the 'meta' section.

>3. Navigation order.
>   this is where I'm stuck. 
>   I am looking for a way of assisting document navigation using
>   (probably) keyboard events.
>   Principle of using say tab key to tab between elements of the diagram

>   (g groups) and then using ecmascript to present a tooltip using the
>   title or desc contents.

The first navigation assistance to think about is hierarchical, not linear.  

It is presumed that you can create a contents tree for the display without too much mental sweat.  A possible orientation technique is a one-level contents summary list in the 'desc' element or in SVG attached to the 'g' structure containing articulable substructure.  In any case, the way you present the navigation hierarchy is by some emulation or approximation of the DAISY book Table of Navigation and associated navigation techniques.

A linear tour through the scene takes more mental effort, but one has to think through the tour order before one can consider tabbing through [the tour of] the scene.  This depends on the author's understanding of the story that the scene has to tell.  It is not recognizable in the XML hierarchy without additional help from some human.  [discussions of AI and machine understanding of scenes suppressed]

>Issues:
>	How to present the navigation method to the listner?

There are two cases, here:

a) Navigation commands are unique to this particular figure, and a narrative explanation of them is included in an optional (i.e. skippable) section in the figure introduction.

b) Navigation commands are standardizes across many figures in some corpus and they are documented offline in a help page linked from the default tour of the scene.

The important thing in this situation is that relative commands are possible, which are not possible with just TABINDEX and ACCESSKEY in HTML.  However, ACCESSKEY emulation is not a bad idea if there are standard roles that parts play across many scenes.


>	I'm insufficiently familiar with ecmascript to make it easy.
>	Charles suggested that onfocus and onactivate are likely candidates.
>	   Question: Are these available in the SVG ecmascript combination
>         provided by ie6 and svgdom+ecmascript combination in Adobe plug-in?
>
>Any advice / examples appreciated.
>

For an example of scene description, consider

 affective messaging and effective mode-crossing (desc example)
 http://lists.w3.org/Archives/Public/wai-tech-comments/2001Aug/0001.html

Examples of scenes for which you need a navigation infrastructure would also help.

For a practical technique, use an audio note taker (microcassette recorder or digital equivalent) [no hands!] to capture the description of the scene, and then analyze that into noun titles and adjective properties of the notional components and plot threads in the scene.  If this doesn't work without a human 'interviewer' recruit someone who genuinely does not know the contents and contextual communication purpose of the scene to be the interviewer running the recorder.  The interviewer can beneficially be at the far end of a phone call.  But record the phone call.  This way you will get layers of description, not just a flat structure.

Then map the connections in terms of lifting text out of the narrative description to use in the local desc and possibly title for the drawing groups ('g' elements) that happen to be the roots of how notional components are drawn.

Al

>Regards DaveP
>
>************snip here************** 
>
>- 
>
>NOTICE: The information contained in this email and any attachments is 
>confidential and may be legally privileged. If you are not the 
>intended recipient you are hereby notified that you must not use, 
>disclose, distribute, copy, print or rely on this email's content. If 
>you are not the intended recipient, please notify the sender 
>immediately and then delete the email and any attachments from your 
>system.
>
>RNIB has made strenuous efforts to ensure that emails and any 
>attachments generated by its staff are free from viruses. However, it 
>cannot accept any responsibility for any viruses which are 
>transmitted. We therefore recommend you scan all attachments.
>
>Please note that the statements and views expressed in this email 
>and any attachments are those of the author and do not necessarily 
>represent those of RNIB.
>
>RNIB Registered Charity Number: 226227
>
>Website: http://www.rnib.org.uk 
>
>14th June 2002 is RNIB Look Loud Day - visit http://www.lookloud.org.uk to
>find out all about it.
>

Received on Tuesday, 12 March 2002 10:04:28 UTC