Re: Thoughts on taxonomy development

Jason,

Our goal is to cover a wide variety of graphics families. The straw man
taxonomy covers statistical graphs, maps and technical drawings as that is
what I am familiar with. It sounds like STEM/instructional diagrams,
mathematical functions and UML are some families that we can bring in. We
will need someone to identify a graphics family for inclusion and bring in
the concepts not already covered.  While each graphics family may have
their own lexicon, I believe there are a core group of concepts that will
cover 85% of our accessible graphics use cases.  I think our first cut at a
taxonomy should be geared toward identifying the core concepts.

Whether we try to describe the visual representation is debatable and I
believe we can look at that aspect of accessible graphics, after finding
the core taxonomy.  To me, what information to provide for each concept is
a first level of detail, that we should do after identifying core concepts
so we don't get bogged down. My interest in what properties to have relate
to being able to produce accessible graphics automatically and have them
read consistently by assitive technology. Others may want more expansive
descriptions that require human intervention. I believe we will have to be
flexible and allow a continuum of descriptions. But I would like to see us
address that later.

Arrrggg, while I want to focus on a basic taxonomy and not get bogged down,
I can't help but throw fuel on the fire of whether to include a visual
representation or not.  For the statisticians I have worked with, they do
not call a statistical chart's axes - the x, and y axes, but rather the
dependent and independent variable.   Some folks call a bar chart where the
bars are vertical a column chart. And a bar chart where the bars go
horizontally, they call a bar chart.  To me there is no difference between
their column chart and bar chart. In this case, their bar chart is simply
their column chart transposed and the dependent and independent variables
do not change. If you are interested in a book that can split any
statistical chart into common components -  The Grammar of Graphics by Lee
Wilkinson  does this nicely.
                                                              
                                                              
                    Regards,                     Fred         
                                                              
                   Fred Esch                                  
       Accessibility, Watson Innovations                      
    AARB Complex Visualization Working Group                  
                     Chair                                    
            W3C SVG A11y Task Force                           
                IBM Watson Group                              
                                                              
                                                              






From:	"White, Jason J" <jjwhite@ets.org>
To:	"public-svg-a11y@w3.org" <public-svg-a11y@w3.org>
Date:	12/19/2014 04:38 PM
Subject:	Thoughts on taxonomy development



The following comments may contribute to the discussion started during the
call today.

I think we should consider a taxonomy that can accommodate a broad class of
graphical representations. Data visualization appears to have gained the
focus of attention in the analysis so far, but it comprises only part of
the entire range of possibilities that a well designed taxonomy should
cover.

Graphs (as in vertices and edges) have been at least introduced by way of
the reference to the SVG Connector work. Maps are a subset of graphs, as
are many other types of diagrams. Then there are graphics based on
geometric figures, as would appear in geometry texts. There are also images
of objects and scenes, occupying a different category from the preceding
cases.

A further category is that of data visualization, graphs (as in subsets of
the complex plane etc.) of mathematical functions, and so on. I think we
should take a broad approach to begin with, establish which categories we
plan to work on for purposes of the first version of the taxonomy, and
proceed to the details.

There has also been interesting discussion as to what kind of information
the taxonomy should capture. In particular, a question has been raised
regarding whether we should concentrate on the data to be represented, or
on how they are represented visually in the SVG. I think a strong argument
can be made for providing detail at both of these levels, and indeed it
isn't clear that the levels are easily distinguished. An advantage of using
properly marked up SVG is that various types of information can be
preserved in the markup, without requiring the author to choose the terms
in which to describe the graphic. In a textual description, however, such
editorial choices generally have to be made, and this can be more or less
problematic depending on the context of ultimate delivery to the user.

For instance, an engineering or physics student who is accessing a circuit
diagram is likely to be interested in high-level information about the
components and their respective interconnections. However, the student may
also wish to know how the symbols for various components in the circuit are
represented, i.e., through what graphical conventions. A good approach to
accessibility would allow the user to choose to interrogate the graphical
representation at this level, which is much closer to that in which the SVG
itself is written. To summarize, the user may want to know about lines,
curves, polygons etc., in addition to resistors, diodes, transistors etc.
Accessible vector graphics formats offer the opportunity to add meaning at
various levels of description; and I think we would be missing a great part
of the benefit if we did not allow for different strata of detail to be
included.

I think of the issue of graphical representation in terms of inferences:
there are geometric facts about a graphic which, combined with the
conventions applicable to the kind of graphic in question, justify
conclusions about whatever is represented. I think we need to make explicit
(in the taxonomy, the states and properties) the premises of those
inferences as well as the conclusion, so that the user who needs to know
can query everything from relatively basic geometric properties through to
properties of the data or objects depicted.

Perhaps we should separate the problem of devising an extensible and
appropriate taxonomic hierarchy from that of what details we want to fill
in for the first release.


________________________________

This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________