- From: Fred Esch <fesch@us.ibm.com>
- Date: Tue, 18 Aug 2015 16:15:30 -0400
- To: "White, Jason J" <jjwhite@ets.org>
- Cc: "public-svg-a11y@w3.org" <public-svg-a11y@w3.org>
- Message-Id: <201508182016.t7IKG1B8012425@d01av01.pok.ibm.com>
Jason,
I like the idea of enabling authors to present information to their users.
Graphics present information very well to users with perfect vision and
without cognitive impairments. Providing additional channels of information
will only work well when authors can customize information for the intended
audience.
1. Define each “dimension” of the data so that its type is clear to the
UA/AT.
fe: I think the proper place to define a dimension is on a visible scale -
either an visible axis or a legend. If there is no axis/legend for a
dimension, then we should not try to define that dimension for the audience
as the visual user doesn't get that information and the author may not
intend the scale to be metric.
For example, an application may use a proprietary algorithm to rank order a
list. Instead of presenting a list, they choose to present the results as a
bar chart with the largest bar on the left and the bars in descending order
as you go right. In this case, the author does not want you to compare
categories using value ratios - so they do not have a Y axis on the chart.
The visual user looks at the left most category on the X axis and knows
this category has the highest value, they don't know what that value is.
The user can't compare a ratio value for two categories as they are not
given a Y axis as a scale - which is what the author intends.
2. Use an ARIA property to declare its visual representation. Thus, for a
numerical value, the visual presentation could be declared as, e.g., “bar
height”, “bar width”, “point” (in a coordinate plane), “sector” (as in a
pie chart), etc.
I think this is valuable and interesting. However, it think it can be
difficult for an author to articulate and thus won't be used much. How does
an author articulate a color in a continuous color scale? ( ColorBrewer 2,
has great categorical color scales. ) How does an author provide names for
custom shapes?
There will also be domain considerations, such as symbol names on
blueprints. Would an aria property add confusion if the author provided a
description?
Regards, Fred
Fred Esch
Accessibility Focal, Watson Solutions
AARB Complex Visualization Working Group
Chair
W3C SVG Accessibility Task Force
IBM Watson
From: "White, Jason J" <jjwhite@ets.org>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: "public-svg-a11y@w3.org" <public-svg-a11y@w3.org>
Date: 08/14/2015 01:42 PM
Subject: Re: chart info from NCAM and other issues from SVG A11Y meeting
August 14
Thank you, Fred, for the reference.
As I understand it, the NCAM research only affects the order in which the
information is presented to the user, not its content.
Another way of handling data visualization in ARIA that we haven’t
considered would be
1. Define each “dimension” of the data so that its type is clear to the
UA/AT.
2. Use an ARIA property to declare its visual representation. Thus, for a
numerical value, the visual presentation could be declared as, e.g., “bar
height”, “bar width”, “point” (in a coordinate plane), “sector” (as in a
pie chart), etc.
This would separate information about the data from information about its
graphical presentation, while making both available to the user agent and,
ultimately, to the user in a consistent way.
Note that I’m not advocating this design here but rather adding it to the
options under discussion.
> On Aug 14, 2015, at 13:19, Fred Esch <fesch@us.ibm.com> wrote:
>
> All,
>
> NCAM
> This is a link to NCAM Effective Practices for Description of Science
Content within Digital Talking Books. It provides examples of what they
think are good solutions for several types of common charts (bar, line.
Venn diagram, scatterplot, pie, flow). Four or five years ago, they
explicitly mentioned that the features in a chart should be presented in
this order: title, axes, data, reference elements. You can still see
vestiges of this in the chart scatter plot example, but I could not find
this as a list of feature order.
>
> NCAM's examples are a good starting point, but usually rely on presenting
the data as a table. I often recommend having an optional sortable table in
addition to charts when the number of data items in the chart gets large
and it would take a while for a user to find the min and max values.
>
> RAVE's shadow DOM
> In RAVE when AT support is turned on, we built a shadow DOM of the charts
and used a tree representation for the chart. Summary information was
generated and added to group nodes. Unimportant items/noise were not
included in the shadow DOM. For instance, the visual Y axis consists of a
vertical line, a bunch of short horizontal lines for the axis tick marks,
axis tick labels (value labels) and sometimes an axis title. The shadow DOM
would only include a group axis object, which sucked in the title to make
the name, may have included summary information about the range or number
of categories/list of categories and its children were DOM nodes for the
axis tick labels (value labels). The vertical line and horizontal tick
marks were omitted as they would just be noise and add no information.
>
> The shadow DOM had a group node for each data feature and the individual
data items would be children of the group (data feature) node. The group
data node would have summary information. Each data item has a value tuple
with the values visible in the chart. For example a scatterplot expressing
x, y, color and symbol would have a 4 value tuple.
>
> When a chart has groups within a data feature - like a stack in a stacked
bar chart, the stacks added an intermediate level to the data part of the
tree and the stack groups are given summary information like the stack sum.
Each stack has the bars making up the stack as children.
>
> A usability issue with the shadow DOM is DOM nodes are not sortable, so a
user could go to the first child, last child or walk through the list. They
couldn't sort the nodes based one of the values in the tuple. Without being
able to sort child nodes, it is difficult for users to find min and max
nodes or give users a feel for the distribution. Enabling AT to traverse
the list of children in a user selected sorted order would be useful
feature.
>
> Line charts
> Lines in a line chart can be difficult to present to AT. The problem is
there is no limit to the number of data points/vertices in a line. In RAVE
we tried to provide a summary and a list of vertices; this turned out to be
unworkable once there were more that a few vertices. So we switched to
providing a summary (min, max), initial slope direction and then provided a
list of vertices where the slope changed and whether the new slope was
positive or negative. I believe we may have had a heuristic to avoid
reporting lots of minor local minima and maxima.
>
> Lines/curves may also be derived from statistics. These lines may be
smooth curves and not have a natural set of vertices to present to users.
>
>
>
> Regards,
>
> Fred Esch
> Accessibility Focal, Watson Solutions
> AARB Complex Visualization Working Group Chair
> W3C SVG Accessibility Task Force
> <07297450.gif>
> <07397786.jpg>
>
>
________________________________
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.
________________________________
Received on Tuesday, 18 August 2015 20:16:36 UTC