W3C

- DRAFT -

Protocols and Formats Working Group Teleconference

14 Aug 2015

See also: IRC log

Attendees

Present
Jason, Fred, Leonie, Rich, shepazu, AmeliaBR
Regrets
Chair
Rich
Scribe
jasonjgw

Contents


<trackbot> Date: 14 August 2015

<richardschwerdtfeger> meeting: SVG Accessibility Task Force Meeting

<fesch> rawgit.com/w3c/aria/master/aria/graphics.html

Graphics Module

Fred notes the architectural issues raised last week about which roles are needed.

iconbutton

Rich notes agreement within the ARIA task force that an icon button role wasn't necessary; it doesn't matter whether it's an icon or not - it's just a button with a label. The preference is to keep it simple and if there's an image associated with the button,provide a label.

Leonie supports Rich's point. If it happens to have an icon in it then it's still a button with a label.

Amelia notes that it's still in the ARIA graphics module.

Fred offers to remove it from the draft.

RESOLUTION: drop iconbutton role per ARIA task force discussion.

Responding to Amelia, Rich notes there hasn't yet been a discussion within the ARIA task force of the proposal for a figure role.

Rich notes that applicability of the role to the HTML figure element will arise as an issue.

Léonie notes that the HTML figure element defaults to a role of group.

Rich notes that a graphic figure could be a landmark role, but this would be problematic for more gneral use in HTML.

Amelia clarifies that it is a special kind of section that should appear in a table of contents. The point is that someone should be able to find it in a long document.

Rich notes that one wants to create a list of figures, so it should be treated as a special type of landmark.

That is, it belongs in a different bucket from the typical landmarks.

Leonie notes that screen reader move to next landmark operations will traverse every figure - not a desirable consequence.

Responding to Rich, Leonie indicates that a figure in HTML should always be included in a list of figures.

Rich proposes to take the issue to the HTML task force.

<richardschwerdtfeger> ACTION: Rich Ask the ARIA task force about the need for a special Figure role that would be brought up in a list of figures. Also, discuss whether this would be a suitable default role for HTML figure. [recorded in http://www.w3.org/2015/08/14-svg-a11y-minutes.html#action01]

<trackbot> Created ACTION-1703 - Ask the aria task force about the need for a special figure role that would be brought up in a list of figures. also, discuss whether this would be a suitable default role for html figure. [on Richard Schwerdtfeger - due 2015-08-21].

<richardschwerdtfeger> Jason: One proposal from last weeks discussion was to keep the graphics object and graphics grouping type roles. We would want to define special navigation features that would not be defined by ARIA roles.

<shepazu> +1

Leonie reiterates an earlier point that there are concerns about the focus on navigation without knowing what information is needed for someone to understand specific types of SVG content.

Fred notes that what information needs to be conveyed depends on the nature of the graphic and also the purpose of the author.

Leonie thinks there are common features of different types of data visualizations - axes, data points, etc., and we need to think about what this comprises.

Fred maintains we should have roles for axes, legends, data points, etc.

<shepazu> +1

Amelia agrees with Leonie that we need a clear structure for conveying information and that we should focus on the information to be conveyed rather than on the myriad visual representations taht may be used by graphics authors.

Amelia maintains we need to be able to convey relationships (containment, next/previous etc.), and we need to be able to connect values on a scale to a given object - a set of categories, quantitative ranges, etc.

Thus we need to be able to define a scale (axis, legend or any of several other visual representations).

Individual objects need to be assigned a value on the scale.

Amelia thinks this is the generalizable solution. Once we have this, we can create shorthand ways of representing this for common data visualization types.

Amelia: however, we still need the generic representation for visualization types that aren't covered by more specific roles.

Doug agrees with Amelia and Leonie.

Doug: position in the hierarchy is important, but also the relationships of data to one antoher - what kind of data are these and how are they related?

He maintains that the intrinsice relationships among the data (being non-hierarchical) need to be captured.

Doug isn't sure how this leads to concrete requirements, but these generalities are important.

Amelia clarifies that her reference to relationships is not restricted to those in a DOM tree.

Amelia: data type (categorical, ordinal, numeric) is an important attribute.

She suggests the scale, value and type of value should be captured.

Fred raises the question of how this should be done - whether as a title, description, or summary.

Fred would not like to see reverse engineering done - taking coordinates or color and attempting to derive data values.

<shepazu> NOIR: nominal, ordinal, interval, and ratio

Fred notes that in his implementation, the dta values themselves are presented to the user even if they are denoted visually by, e.g., color.

Leonie suggests we need to identify the general categores - axes, colors, bars and other constructs.

Fred: the only useful properties of an axis are its labels.

Leonie notes that whether an axis is, e.g., the x-axis, this needs to be captured so that it can be conveyed non-visually.

Fred notes his implementation experience in which this information is communicated to the user.

Responding to Leonie, Fred suggests that what users would want from an axis is the data range.

Leonie makes the more general point that more such analysis is needed to determine the required roles.

Doug: what is more relevant is that an axis is dependent or independent (i.e., represents an independent/dependent variable).
... we need to achieve a balance between a "folk" taxonomy that captures the concepts typically used, and aa technically accurate taxonomy.

For example, there can be any number of axes, so we need a balance between the full range of possibilities and how people typically characterize charts.

Thus, for example "x" and "y" can be independent and dependent, respectively, but this can be reversed in some cases.

Doug suggests that an axis determines a scale (nminal, ordinal, interval, ratio etc.), and this is waht should be captured.

The category and type (including data typing/units) should be captured. These are core concepts that should be represented in ARIA, and we need to decide how to achieve it.

Rich suggests we need to build and start working with it in order to define it more adequately.

Rich notes that we can try some of this early without an API mapping using object attributes.

Amelia: we need to ascertain what information is required and how it is expressed before we enter into too many specifics.

<shepazu> +1

Amelia: considering a verbal description, one would wish to know that it's a chart, what kind of chart it is (if it's one of the common types), how many data points there are and how those points are arranged, e.g., by date and dollar value.
... you also need the option of drilling down. Here there is a choice: do you want the scales and axes, or to move straight to the individual data points.
... if there are only 5 data points, one might want to go directly to the individual data points and read them.

<shepazu> (and do you want to have the AT do operations on the data, like calculating statistics, or listing lowest to highest, or comparing one data point to each other data point or to the aggregated data points)

Amelia: thus, what one should drill down into depends on the user's purpose and the complexity/quantity of the data. This is wehre we leave it open for AT to decide how to navigate it, but we need to ensure that the information is available for both approaches.

This implies a role for scale (subclass roles of axes and legends), and another role for data (with subclass roles associated wth specific data types).

Associated with each data object we need the scales and the value on each scale, e.g., list of idrefs to the scale objects, and associated numbers or names.

This is where we need to define the types of data that need to be conveyed.

These types of data then need to be represented as ARIA roles and properites.

In summary, Amelia suggests starting with very generic roles that are independent of the visual representation of a chart, then we can develop subclass roles for, e.g., whether an axis is a horizontal/vertical axis.

Rich notes we have capabilities for orientation in ARIA.

Fred notes the proposed roles for graphics scale and data items.

<shepazu> (these orientation/visual aspects are more for talking about the dataviz with others, rather than understanding it)

Fred notes that NCAM recommend presenting this to the user as title, axes, data and features (in this order).

Fred: data can be problematic, e.g., describing a line in a line chart. If there are 100,000 points, one would not supply every member of the ordered pair. One might summarize it, include only major trends/changes of direction, etc.

Doug requests the NCAM reference, which Fred agrees to supply.

Doug will send more details of his forthcoming presentation on data visualization.

Doug will send the details to Rich.

Doug considers this a very productive discussion, but we need to become more concrete.

Amelia offers to write a proposal based on what was described earlier.

Amelia raises the question of how to deal with an excess of data that therefore need to be summarized, and how to address complex data objects, e.g., a line in a line graph.

Rich also notes that if one is using a small mobile device, it changes one's perspective as to what information is appropriate.

Summary of Action Items

[NEW] ACTION: Rich Ask the ARIA task force about the need for a special Figure role that would be brought up in a list of figures. Also, discuss whether this would be a suitable default role for HTML figure. [recorded in http://www.w3.org/2015/08/14-svg-a11y-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/08/14 15:55:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Amelia notes that the HTML figure element defaults to a role of group/Léonie notes that the HTML figure element defaults to a role of group/
Succeeded: s/eonie/Leonie/
No ScribeNick specified.  Guessing ScribeNick: jasonjgw
Inferring Scribes: jasonjgw
Present: Jason Fred Leonie Rich shepazu AmeliaBR
Found Date: 14 Aug 2015
Guessing minutes URL: http://www.w3.org/2015/08/14-svg-a11y-minutes.html
People with action items: rich

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]