talking points for tomorrow [was: Re: Response to WebCGM 2.0 comments sent by Kentarou]

** summary:

Yes, PFWG want to work with WebCGM, thank you for the invitation.

The appendix you drafted is a good start.

We should still step back and look a little wider:

- hierarchical navigation and not just sequential (maybe graph 
navigation?  TV-like
navigation of the presentation geometry?)

- Interaction modes that are effective under different user ability profiles:

- blind (screen reader, tactile graphics)
- low vision (scrieen magnifier)
- severe motor impairment (single switch, scanning software)
http://tinyurl.com/efjsf
- cognitive issues leading to graphical enhancement of content (think 
exploded view,
picture-annotated content)

- Interaction modes appropriate to diagram genres

- bar charts
- organization charts
- subway system maps
- physical+highway maps
- schematic diagrams
- cartoons
- assembly instructions for consumer-assembled products
  .. includes parts separately, exploded view, assembled view

that can be
applied across the breadth of:

- WebCGM documents
- SVG documents
- XHTML documents laid out with CSS positioning

Below there are more comments; some detailed, some fuzzy.  But this 
will give us
grist for what I hope is a good discussion.

Thanks,

Al

At 6:33 PM -0600 8/31/06, Lofton Henderson wrote:
>Hello Al,
>
>The WebCGM WG thanks you for the comments on WebCGM 2.0 sent by 
>Kentarou Fukuda <KENTAROU@jp.ibm.com> on Fri, 25 Aug 2006 20:38:59.
>
>The WG wants to make a proposal for resolution, but to set context 
>for the proposal, first a review of the LC history.
>
>A.) About our LC history:
>----------

Rapid recap of the history:

WebCGM process OK:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2006Sep/0002.html

And, at today's PF telecon, we

<quote
cite="http://www.w3.org/2006/09/06-pf-irc#T13-22-23">
(Member restricted link)
RESOLVED: PF accepts WebCGM resolution of Kentarou comment, will work
with them on appendix during CR to WebCGM timetable
</quote>

And Lofton said the time to start working together was on the
Thursday, 7 September WebCGM call, so here are a few comments on the
appendix draft to seed the discussion.

>B.) Proposal
>----------
>
>The WebCGM WG believes that these comments are valuable and has 
>discussed these during its telecon today.  The Group has drafted an 
>Appendix document [6], which we hope will be a mutually satisfactory 
>accommodation of your issues for WebCGM 2.0.  This informative 
>Appendix will be incorporated into the WebCGM 2.0 PR version.
>[6] http://www.w3.org/Graphics/WebCGM/WG/2006/wai-appendix.html

1. Thank you

It looks as though WebCGM has a lot of support to create an
annotated scene-graph suitable for alternate modes of access.

The draft appendix provides a good guide to these.

2. Sequential navigation may not be what we really want for a graphic
scene.

The underlying idea here is that we use diagrams for information that
doesn't serialize well.  Where there is a graph of relationships so that
a narrative shortchanges some of the relationships in the process of
flattening the content to a serial stream of narrative.

Partly because of this, I don't expect good things from sequential
navigation in document order of a CGM graphic. CGM overwriting
suggests that the first thing you would see and hence the first thing
you would want spoken is likely to be the last in serialization order
in the file.

The Standard or DAISY digital talking book has a concept of a
Table of Navigation which is a hyperlink-enabled table of contents.
And DAISY players let you move across the document-parts
tree a different depths.  To the next chapter, to the next section
at this level, as well as drilling down or backing up to survey more
globally at the next higher level.  You may recall Janina Sajka
demonstrating this browse mode at the 2003 Technical Plenary[mm].

We should be looking at hierarchical navigation in terms of an
extractable DAISY-like hierarchical Table of Navigation and not just
sequential navigation, in all likelihood. Maybe with an exception
when there are only five-to-nine APS on the sequential navigation
cycle.

The existing WebCGM facilities to have text labels for navigation
destinations would apply in either case.  It's just a matter of extracting
a sensible hierarchy (if possible) along with the bag of navigation
destinations.

There's already a lot of support through the grouping constructs in
CGM for a hierarchical view of the contents of the scene.

3. Terminology tweak: link text is not ALT text.

Reference:
E.3 ALT-like attributes
http://tinyurl.com/egllj

I think I understand what you-all, as analytical thinkers, mean by
classing the text attributes that label hyperlinks as "ALT-like" features.
On the other hand in a document for public consumption, we probably
need to invoke multiple HTML precedents:

- ALT on images
- labels on INPUT fields in a form
- the text content of hyperlinks

as the kinds of content we need to have for a text-enabled browse.

Enough scraps here and there to answer "Where am I?  What is there?
What can I do?"

http://www.w3.org/2006/03/01-Gilman/tree2.xhtml

Access note: At that page, if you are using Firefox 1.5 or up you can
double-click on the tree branches to expand and collapse the topic
tree. If not, try a cut and paste of the text -- it should give you
the fully expanded tree list without the CSS hiding.

4. Integration of pan/zoom control with AT

Reference:
2.3.3 Usage of WebCGM objects for navigation
http://tinyurl.com/z7cj3

There are potential issues integrating the automatic pan-zoom
functions keyed by WebCGM properties with the functioning of
Screen Magnifiers use by Low Vision users, those who are Visually
Impaired but not blind.

C. Some related background.

5. Related ARIA work

PF has work in progress in the 'roadmap' or 'ARIA' area that relates
to "access to diagrams."

http://www.w3.org/WAI/PF/#Roadmap

But it's not maturing in time to feed into the PR draft of the WebCGM
spec. You are forcing our hand; that's good.

In our discussions so far, we have noticed some things:

There are different genres of diagrams that we need to attack
differently.

There are pie charts and bar charts which are graphical depictions
of data relations (in the sense of Codd and Date, Oracle and DB2).
These are probably best attacked through table-access methods
based on the underlying data relation.

There are some diagrams, like organization charts, that have a
dominant tree as a subgraph and which map naturally into a tree-list
alternate presentation geometry.

But there are other graphics with a lot of articulable ontology --
subway system maps being the posterkid or conspicuous example --
where the graph topology is essential and neither sequential nor
hierarchical browsing fits the function of the diagram well.  But we
only have a placeholder in there saying "we know we will want some
form of graph navigation."  There is not a spec or a community of
practice to my knowledge to base anything in your document on
in this area.

In addition, graphic presentation is not only capable of raising barriers
for the blind, it is also capable of removing barriers for people with
some other disabilities, for example dyslexia.

Also, for the severely motor disabled, single-switch users use a
mode of access called scanning where the focus is animated
across the focusable items and the user just stops the scan when
the focus gets to the item of interest.  This generally revolves around
a graphical presentation of (a hierarchical organization) of actionable
objects scraped from the scene.  Using accessible WebCGM as
the delivery medium for content transformed at a server site to
make it work for  these consumers is of interest over the long haul,
and not just getting past the obstacles for the visually impaired.

It sounds as though we only have questions.  This is not entirely
the case.  We are developing a module of new attributes in the
XHTML modularization vein which add not only unary properties
that apply to one DOM node but also IDREF-valued properties
that inform the processor of graph arcs beyond the parse tree.
This general idea, that there are semantic connections that cut
across the dominant tree-form subgraph, will likely be very present
in some genres of diagrams that get communicated in WebCGM.

In this regard we will particularly be interested in what exactly one
can do with the "private namespace extension" capability.  Is this
a good way to inject RDF/a?  Could we use this way to introduce
further accessibility metadata for interactive CGM diagrams?
Can we complete the semantic graph of a subway system map
in this way?  [Only worked examples will tell for sure, but this is
an area of dialog/coordination that we should touch on.]

5. CR is about building the experience base

We are looking for people in the document-conversion business;
people who generate alternate-format materials for use by people
with disabilities, who would be an early target for uptake of
accessible CGM usage by means of the WebCGM wrapper, binding
and profile.  We would want to be in touch with the people providing
the usage experience to the WebCGM Implementation Report
for possible collaboration on pilot-document exercises.  I won't  be
ready to move on this tomorrow, but I want y'all to know of our interest
in this direction.

Received on Wednesday, 6 September 2006 21:20:16 UTC