Re: WebCGM and accessible graphics -- two ideas

All --

I read Stuart's comments [1] and basically agree:  almost anything is 
theoretically possible with the companion file, but the ideas are well 
outside of the present real-world application scope of WebCGM.  For reasons 
that are mentioned by Stuart and also in the Gardner/Bulatov paper, 
real-world WebCGM's tend toward "ink on paper", rather than realizing the 
XCF potential to carry rich application semantics.

[1] http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0018.html

More in-line...

At 10:55 AM 11/7/2008 -0500, Al Gilman wrote:

>Reference WebCGM 2.1
>http://www.w3.org/TR/webcgm21/
>
>Reference Hypertext CG ACTION-24
>http://www.w3.org/MarkUp/CoordGroup/track/actions/24
>
>Back in September I blurted out two thoughts about WebCGM
>and accessible graphics, in a cloud of purple smoke.
>
>Lofton asked me to spell them out in an email and HCG gave
>me an action to do that.  Better late than never, here
>they are.  Still just brainstorming notions.
>
>1.  A question:  Would the XML Companion file either
>accept SVG within it

In theory, one could put SVG statements into the XCF, in a new private 
namespace.  Correct?

In practice, I think it might prove tedious.  But I'm also wondering, why 
would one put SVG within WebCGM XCF?  If we are talking about actual SVG 
graphical statements, then we might be crossing the line for what the XCF 
was intended.  (XCF has some limited style editing aimed at the WebCGM 
instance, but it does NOT contain new graphics, and I think it should not.)

Okay, so maybe we're talking about the annotation stuff per the 
Gardner/Bulatov paper?  As I read that paper, one chapter seems most relevant:

[2] 
http://www.svgopen.org/2004/papers/SVGOpen2004MakingGraphicsAccessible/#S2.

What I'm seeing here is that the graphic, if well structured, should then 
be annotated to make it accessible.  Most of the rest of this paper, AFAIK, 
is about the very clever braille-like embossing output technology.

So ... why use SVG annotation?  As we pointed out in appendix E [3], WebCGM 
has the sorts of titling and descriptive elements that one can use for 
accessibility annotation:

[3] 
http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Appendix.html#webcgm_accessibility-content

Summary:  don't put graphics in XCF, SVG or otherwise; and WebCGM/XCF 
already contain sufficient annotative functionality to do the sorts of 
accessibility support things that I'm seeing in Gardner/Bulatov.

Question:  am I missing something?

Out of time, more later...

>or contain enough information so that with
>the XML Companion file included, WebCGM files could
>deliver the same access functionality of the image+SVG
>diagrams that John Gardner and Vlad Bulatov have worked
>with?
>
>See, for example,
>http://www.svgopen.org/2004/papers/SVGOpen2004MakingGraphicsAccessible/

Out of time, I'll get back to this later (but as Stuart points out, WebCGM 
from CAD systems suffers from the same deficiencies (vis-a-vis 
accessibility support) as "most SVG in the wild".)

>2.  A remark:  One of the problems with leveraging SVG
>to get accessible diagrams is that the SVG that actually
>gets written to most SVG files in the wild is not
>'semantic' or 'ontological' but rather just a collection
>of directives to lay ink on the canvas.  A heap of
>scribbles.  No better than
>a bitmap in terms of still requiring a lot of human effort
>to build a graph catalog of articulable objects and relationships
>in the scene.
>
>Given that CGM is a native output of
>CAD systems that maintain something of an ontological
>view of the subject matter, perhaps the corpus of CGM
>diagrams in the wild would prove more fertile ore for conversion to
>accessible form than the corpus of SVG in the wild.
>
>Those were the two thoughts.
>
>Al

Received on Thursday, 15 January 2009 15:56:31 UTC