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

As promised, I've worked through a couple examples using the proposed data
properties.  Both graphics are adapted from Fred's SVG samples (the zip
file is on the wiki [1]), so you can compare.

Overall notes on the taxonomy and roles, based on trying to put them to use:

   - I've been using Fred's "graphics-dataitem" role name instead of
   "graphics-datapoint".  I decided that "point" might be confusing for
   non-statistical users when talking about bar charts and pie graphs.
   However, I have still been using the more limited definition, only applying
   the role to individual data entries and not to data summary features.

   - For the issue of multiple variables expressed on the same scale or
   axis (as described in a previous email [2]), I have introduced a new
   property, which I'm currently calling aria-datavariablenames (data variable
   names; suggestions for shorter alternatives welcome).  The
   `aria-datascales` property for a data group or data item would reference
   the scales by id, with repeats.  The data variable names property would
   provide human-readable names for each variable.  If not provided, the name
   of the variable would be the name of the scale.  This allows you to have
   "min temp" and "max temp" variable both measured on your "temperature" axis.

   - As discussed in that email, I also added an `aria-dataunits` property
   to complement `aria-datatype` on each axis/scale.

   - These two examples don't deal with the nested groups issue (also
   described in [2]), but I'm leaning towards using an array-queue approach,
   where the group can define all variables, but only set data for some of
   them, and then any data assigned on the individual items is associated with
   the remaining variables in order.

   - I found that I very often didn't have to use the `aria-valuenow` and
   `aria-valuetext` properties on axis ticks and categories: the default of
   using the plain text content was often enough.


Notes on histogram.svg:

   - The graphic is a histogram (bar chart representing counts for
   different values in a continuous range).  Fred's descriptive text
   interprets this as a distribution of the ages of users of some unknown
   product (a product that must be oriented to children, since the age peaks
   in the 5-10 range).  There is a smoothed-curve trend line superimposed on
   the bars.  I don't have information on how the trend was calculated, but it
   looks like a running average of some sort.

   - I made some minor changes to the chart appearance, and cleaned up the
   markup a bit to remove redundant attributes.  However, the major changes
   are in the metadata and alternative text.

   - Fred had assigned detailed descriptions of each data entry in title
   elements.  I've replaced that with short tooltips that would be appropriate
   for visual users to complement the graph.  Normally, this would mean adding
   aria-label to create a good accessible text, but I'm assuming that an AT in
   this case would use the ARIA chart properties to create the accessible
   descriptions.

   - I still have detailed alternative text for more complex features, such
   as the trend line.  The line is also marked up with
   `role="graphics-datasummary"`.

   - I've encode the x-axis (the age ranges) as a continuous numerical
   axis.  Each individual bars has max and min age variables.  Alternatively,
   of course, I could have used named ordered categories for each age range.

   - The y-axis (the number of users in each age range) is a "count"
   datatype.

   - I've followed Fred's pattern and used an `aria-datagroup` role to
   collect all the bars together. Although there is only the one group in the
   entire chart, this allows me to assign the `aria-datascales` and
   `aria-datavariablenames` attributes once for the entire group.  The scales
   are id-refs, with a duplicate reference to the x-axis.  The variable names
   are what would be read to the user: min age, max age, count.

   - The individual bars have `role="aria-dataitem"` and an
   `aria-datavalues` attribute with three comma-separated numbers.

   - Both axes use the `aria-orientation` property to define vertical vs
   horizontal.  The use `aria-valuemin` and `aria-valuemax` to define the
   range displayed on the axis (not the range of the data).  The age axis uses
   `aria-dataunit="years"`.  The count axis does not need a unit.  The axis
   titles are associated with the axis using `aria-labelledby`; they do not
   have a special role.

   - I've assigned the `graphics-tick` role to the axis labels, but treat
   the tick mark lines and grid lines as presentation only (role="none").  See
   below for how I approached this differently in the second chart.

   - The tick mark text content, for both axes, consist of simple numbers
   that can be successfully parsed for the data type of the axis.  Therefore,
   I did not need extra properties to assign a machine-readable value or a
   text label.

Notes on twoGraphs.svg:

   - The chart represents multiple measurements of the stock market
   activity of an unnamed stock for five days in 1980.  The information is
   presented in two vertically-aligned panels, with different y-axes but the
   same x-axis.  The top panel has price-related information using composite
   lines and bars to show ranges.  The bottom panel measures the volume of
   trades as a bar chart.

   - I've made a few visible changes to Fred's version of the chart.  The
   main difference is that I added a visible legend to describe the color
   coding of the bars.  I also inserted a missing value and fixed the
   alignment between the two panels.

   - I've also changed the interpretation of the data to something I could
   safely explain.  I've never heard of m1 ranges in stock prices, so I've
   re-interpreted the price ranges as the standard open/close/min/max stock
   price chart. The bar shows the difference between the daily opening and
   closing prices, and the line shows the maximum and minimum price for the
   entire day's trading.  The color of the bar indicates whether the
   opening-closing difference represents a rise in price or a decline.

   - I've kept Fred's use of the `figure` role for the individual panels.
   However, I've also assigned the `graphics-datachart` role to the SVG as a
   whole.  This reflects the fact that the layout of the two panels cannot be
   changed without compromising the information expressed by the shared x-axis.

   - Again, I've simplified the titles on the data items to only contain
   information needed to complement the visual display as a tooltip.  The axes
   and the data groups have longer descriptions in <desc> elements, which
   explain how the data is presented.

   - I have, however, kept the markup structure used in Fred's version.
   The max-min ranges are in a separate data group from the open-close ranges,
   and the volume bar chart is another data group.  It's not how I would
   normally organize the chart, but it's a valid organization.

   - The max-min ranges represent three data variables: the date on the
   x-axis and the max and min prices on the price y-axis.  Again, the data
   scales and data variable names are assigned at the group level and then
   values assigned for each bar.

   - The open-close bars are similar, but they have an extra variable,
   representing the rising/falling color encoding.  The corresponding data
   scale is the new legend <g> element.

   - The volume bars are simpler, with an x (date) and y (count) value
   each.  The data group therefore doesn't need explicit variable names, it
   can just use the names of the corresponding axes.  The id-refs of the axes
   are still assigned with the `aria-datascales` property.

   - For both vertical axes, the `graphics-tick` role is again assigned to
   the visible tick labels.  However, I have also used an `aria-owns`
   relationship to group the grid lines and visible tick mark lines as
   children of the labelled tick.  I think we should encourage authors to
   include all visible representations of a labelled tick within the role,
   either by grouping them together or using `aria-owns`.  That way, AT can
   more effectively make use of these guides.  For example:
   - A touch-screen enhanced screen reader could read off the tick labels
      as a user traces their finger across the graph, crossing
gridlines but not
      necessarily labels.
      - A visual enhancement for users with cognitive difficulties could
      highlight gridlines and the associated labels together when the user
      selected one or the other.

      - For the price axis, orientation is vertical, the data type is
   numeric and the data unit is "$".  Because the visible tick labels include
   the dollar signs, and therefore won't parse as machine-readable numbers,
   I've used the `aria-valuenow` property to assign the machine-readable
   values.  I don't need an `aria-valuetext`, however, since a screenreader
   will be able to read the visible text just fine.

   - The volume axis is also vertical, with a count data type and no unit.
   I've maintained the use of exponential notation for the numbers, to prove
   you can (although it makes me wince).  I have corrected the conversion
   errors Fred made when trying to make sense of the awful exponential
   notation (the values are in tens of thousands, not hundreds of thousands).
   The exponential notation is safely parsed by a computer, however, so no
   need for a separate attribute.

   - I debated using `aria-valuetext` to provide a reader-friendly text for
   the volume axis (e.g., 80,000 instead of 8.000E5), but decided to let
   screen reader users have the same awful number formatting as visual users.
   That said, for the actual data bars, the tooltip provides a
   nicely-formatted number.  Any automated description based on the
   `aria-datavalues` would presumably use the AT's localized number formatting
   (and yes, I know this is one of the issues Fred has brought up).

   - The date axis is horizontal, and uses the datetime data type.  It
   doesn't have a visible title, so it uses an `aria-label` attribute to
   assign a name.  The unambiguous date format defined in HTML 5 is used for
   min and max values for the axis, the machine-readable values for the tick
   marks, and the corresponding values for all the data items.  The text value
   for the tick marks would be read out as is, but again I don't have any way
   to tell ATs how to format the dates in the data.

   - Finally, the legend is marked up with `aria-datatype="category"` and
   is labelled by its visible heading.  I've assigned the `graphics-category`
   role to the colored sample squares, and used `aria-labelledby` to connect
   each sample with its label.  Each category uses `aria-valuenow` to assign
   the name that will be used in the data entries ("up" or "down").  However,
   the value text that would be read out will default to the accessible name
   provided by the label ("Rising" or "Falling").



I'm not sure I'll have time this week, but I have some ideas for some new
visualizations that will demonstrate some of the other possible
combinations of roles and properties.  I would also like to adapt Fred's
script for visualizing the accessibility tree, and post the scripts and
demos on Github where they will be easier to compare.  Hopefully I can get
to that next week.

Best,
Amelia

[1]: https://www.w3.org/wiki/File:Svggm.zip
[2]: https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug/0026.html