Re: ARIA Graphics Module -- proposed roles hierarchy & data properties

Fred,

Thank you for your thoughtful comments on this thread [1] and in the mail
where you compared my proposal with your taxonomy [2].  Everyone should
read both e-mails carefully; you bring up many complications we need to
consider.

I whole-heartedly agree that we should avoid any suggestion that user
agents should perform inappropriate statistical analyses of chart data.  We
do not want a browser declaring trendlines or the significance thereof when
that measure may be quite inappropriate for the dataset.  We need to
recognize that data used to generate a chart is often a summary of a much
larger raw data set, and is often cleaned up in ways that reduce precision.

However, I do not believe the alternative is to rely solely on
author-provided descriptions of the data and its patterns.  There are
multiple problems with this approach:

   - It expects the author to identify all features worth describing.  It
   does not allow the user to *choose* which details they are interested in.
   - If the chart is generated by an automated tool, the text descriptions
   will not necessarily be any better than text descriptions created by an
   automated tool on the user agent/AT.
   - Unlike a user-agent tool, an authoring tool will not be customizable
   to the language requirements and other needs of the user.

For these reasons, I would like author-supplied descriptions to be an
*enhancement* or complement to user-controlled automated summaries.  The
automated summaries would be based on metadata that can easily be inserted
by the authoring tools that generate the chart.  (Because, let's face it,
most SVG charts are created with authoring tools or scripting libraries.)

The automated summaries I am proposing are not analysis, although they
would technically be called summary statistics. They are intended to
describe the features that a sighted user would gather from looking at the
presentation of the data in a chart.  For example:

   - The number of axes and other data scales, and the range of values they
   can encode (regardless of whether the data uses this full range).
   - The number of data groups, and the number of data items within each
   group.
   - Which data measurements, on which scales, are available for each group
   or each data item
   - The maximum and minimum data values on each scale, either overall or
   for each group, and maybe other non-parametric statistics such as median or
   quartiles.
   - The entire data points as a sorted list, according to values on any of
   the scales.

More advanced non-visual AT could perhaps offer a query format, allowing
users to slice the data into subsets based on categorical variables or
ranges of quantitative variables.  For example, the user may want to know
the max, min, and median y-values when the x-value is within a certain
range.  Or the user may want to know at which x-values the y-value falls
within a given range.  Other software, as Doug has demonstrated, could use
auditory encodings to directly represent the data values in sound.

The details of data relationships, as expressed by the properties I
proposed, would also be used for alternative visual presentations (or other
2D presentations, such as embossed books).

   - Software that replaces color encodings with different colors,
   patterns, or shading would need access to the data used in the existing
   encoding.  This could be useful for monochrome printing, embossing,
   high-contrast mode, or color-blindness-friendly mode.

   - AT that changes the layout of some features needs to know which parts
   of the layout encode information, and how different parts are connected.
   This could be useful for large print or magnification mode,
   braille/embossed documents, automated translations, and maybe even
   automated adaption to small screens.

It is for these alternative 2D presentations that it is really important to
distinguish between maps, data charts, network graphs, and generic graphics
or diagrams.  When we declare a section of content as a graphical document,
we are saying that layout is no longer a matter of style and formatting, it
is part of the informational content.  The document types for maps, charts,
and network graphs distinguish *which* aspects of the layout are important
for information.  In combination with the other roles and properties, it
provides the AT with the information to make judicious alterations to the
layout as required.  For example:

   - A legend may be moved around so long as it doesn't obscure data items
   and the user can still easily consult it.
   - An axis may be repeated if the chart needs to be split across pages,
   or the axis may remain fixed while the data (and other axis) scrolls by
   perpendicular to it.
   - A network graph could be extensively re-arranged so long as the
   connections between components are preserved.

In contrast, if the group consensus is that authors should provide all data
in the form of text labels and descriptions, then there is no potential for
software to re-encode data or offer a query feature.  The only purpose for
a complex role taxonomy of parts of a chart would be to support
layout-reorganizing changes, so a much simpler set of roles should be
used.  The label and description ARIA properties, including the new
aria-roledescription property, would be sufficient to distinguish other
features or sub-types of features.  Navigation options (both 2D and
hierarchical) would be the same as for more generic diagrams and structured
drawings, but with the option for non-visual users to jump to axes or to
data.

I hope to hear more opinions and ideas from others,

Best,
Amelia


[1]: https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug/0034.html
[2]: https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug/0027.html