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 Friday, 14 August 2015 17:42:34 UTC