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

A few extra notes & follow-ups to consider when you're reading through the
summary I sent yesterday [1].

Notes from today's teleconference:

   - I got the feeling that no one wanted to get into the complication of
   defining special roles and behavior for common chart types, so the sections
   about bar charts, pie charts, etc., can be ignored.  The generalizable
   `graphics-datachart` role would be used instead.

   - Doug pointed out that I did not include any way to define the units
   for a measurement.  Based on the model I've created, this would be a
   property of the `graphics-datascale` object (i.e., the axis or legend).  We
   could call it `aria-unittype` and the value would be a localized string
   provided by the author, such as "millions of U.S. $" or "kHz".

   - Chaals recommended we use XML Schema data types instead of coming up
   with our own enumeration.  You might want to check out the spec [2], or
   maybe just this short summary table from MSDN [3].


Other complications to the data model:

   - The metadata for each variable in the dataset is attached to the axis,
   legend, or other scale that displays it for sighted users.  What happens
   when multiple variables for a given data point are displayed on the same
   axis, such as an extent with max and min?  Options:
      - The author could duplicate the metadata for the axis, even though
      it only needs to be drawn once.
      - Alternatively, the max-min extent could be represented as a
      two-point data line, where additional dimensions of the data encode which
      type of measure (max versus min) each point represents.  But then you'd
      need metadata for the max versus min scale.
      - Any other suggestions?  We want it to still be generalizable; for
      example, there might be max-min extents in multiple directions.

      - I suggested that the order of variables (as id-refs to the
   corresponding scales) could be set once on a group and inherited by the
   child data points.  But that doesn't address the common situation where the
   group has certain data values that are either shared by child data points
   or a summation of child data points.  For example, a stacked bar chart.
   Each stack has a data value on a categorical axis as well as a total value
   on the quantitative axis.  The child bars then have a data value on a
   separate category (usually associated with a legend of colors or fill
   patterns), and their individual values on the quantitative axis.  Options:
      - Give up on the idea of declaring the list of data scales once and
      inheriting it.
      - Create a separate ARIA attribute for declaring the child
      data-scales versus the group's own data scales.
      - Make it inheritance of the unused scales.  So the stack would have
      aria-datascales="category, value, sub-category, value"
      but only two data values, and the remaining data values would be
      assigned for each of the child bars.

      - We had previously talked about using ARIA properties to explain
   *how* a given data scale is visually conveyed: color, pattern, size,
   etc.  Except for the orientation of an axis, I don't yet have an attribute
   to do this.  It would also be attached to the data scale, and should
   probably be a localized string provided by the author.  I don't think it's
   possible to create an exhaustive enumeration of all the ways data might be
   represented.

As I mentioned on the call, I'll work on creating some practical examples
of marked-up charts for early next week.

Best,
Amelia

[1]:
https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug/att-0022/graphics-roles.html
[2]: http://www.w3.org/TR/xmlschema-2/
[3]: https://msdn.microsoft.com/en-us/library/ms256220(v=vs.110).aspx