Protocols and Formats Working Group Teleconference -- 24 Jul 2015

<trackbot> Date: 24 July 2015

<scribe> Meeting: SVG Accessibility Task Force

<fesch> https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Navigation_Supported

Chart Taxonomy

<fesch> https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy

Amelia: Last week spoke about how much information should be given in the role
... and how much should be in role type
... I think this is based on what we have done for the fast few months.

List of roles:

https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#List_of_Roles

Fred: charts are composed of 3 types.

<fesch> Charts are composed of three types of objects- regions, data and guides. Chart regions are express via the graphics-figure role and chart regions are assumed to be explorable. Data related roles imply the element expresses a chart's data. Guide related roles imply the element is a guide object.

<fesch> Data used in charts, is similar to data found in spreadsheets and databases and consists of columns and rows and is often thought of as a table. Some charts with connectors use two or more tables - one table for the nodes and a second table for the connectors. When we interpret charts we interpret the data in the chart.

<fesch> Guides provide reference information and help us interpret the chart. Guides fall into two categories, scales (ie. axes, legends, dimension lines) and annotations (ie. titles, footnotes and arrows to call out info). The names of guides are often specific to a graphics domain. For instance, in statistical charts a positional guide an called an axis. A positional guide on a geographic map is...

<fesch> ...called graticule or grid. On isometric diagrams positional guides are called dimension lines.

fesch: regions are meant to be explorable
... data related roles where the element refers to the charts data

fresch: a guide is like an axis

rich: guide is not intuitive. Guide is like directions to me

jason: doug mentioned that some of these should be distinguished. … annotation from axis
... Whatever taxonomy we come up with we need to ensure that everything is programmatically determinable even if you have multiple axis or data sets. I am fairly flexible on how we get there

fred: you know you can define an axis where the chart represents the data.
... the axis can dynamically change based on the data set.
... in other case they axis may not change
... some legends may show some of the data set. Others may show the entire set.
... all things may appear in the legend even though they may not appear in the data

jason: the axis might determine the scale, let’s say in a rectangular coordinate plane.

fred: in some cases the axis may be determined from the data and perhaps rounded up
... you can look at multiple data sets … if you were looking at data across quarters you may want to have consistent scales across all coordinates.

jason: so you need to extract the data to determine which data is which

fred: you cannot take the data from the axis as there may be no correlation

amelia: I disagree. because of what you said it is important to have the information on the axis. …. this is the theoretical range of all possible values even though it is not expressed in this data set. … such as aria-valuemin and aria-valuemax

jason: should we require the values themselves to be self contained?

fresch: on an axis you could have aria-valuemin and aria-valuemax for continuous scale

fesch: for categorical scale would you want all the categories?

amelia: the idea situation would be a properly annotated graph

<scribe> scribe: Rich

amelia: you want the screen reader to have accurate statistics based on the possible values

fred: I don’t think you ever want them to have x and y values and have them interpolate
... we need something in the title that reflects the data

amelia: we need to express for a given datapoint this is the value on this axis and then on that axis based on this categorical scale

fred: you can have color and shape and categorical dimensions

amelia: the main thing is it needs to be expandable
... values list that gets matched up against a range ...
... we want this to be machine readable data

jason: that was my point last week

fred: so we want a tuple of values that is machine readable

rich: so, we want a tuple per data point. …

fred: but that is not large
... a scatter plot with a 1000 points is a bad scatter plot

amelia: then you have trends and density. you would want to represent the density of somethng
... then you would have density for each square in a grid without a bunch of points

jason: such as a scatter point with a lot of data points

fred: 3 types: regions, data, and guides

rich: we should call these abstract roles
... they don’t have to be abstract

fred: the first one is the graphics data group
... this just means a group of data objects
... but a group can have several types of children

graphics-datagroup

Members in the data group represent data. The graphics-datagroup role is a subclass of graphics-object. graphics-datagroup may have children with the following roles.

graphics-datagroup

graphics-dataitem

graphics-label

none

fred: graphics connector is something we may do
... it is like an SVG connector and it can have a label and symbol

jason: would I be right in saying that it would have a label?

fred: yes but we would need to have the tuple object
... you can have a visible label

rich: after this call we should start to populate this. we need to see it

amelia: we need to create a parallel one

graphics-dataitem

Fred: this would represent say a bar in a bar chart
... you could have a graphics-dataitem that represents three columns in that role and all three are important and all 3 have semantic meaning. You can have a nested data item.

graphics-event

Fred: Something defined or marked by an instant of time or time interval. A graphics-event role is a subclass of a graphics-dataitem role. A graphics-event may have children with any role.
... It could have children with any role

Rich: we need to say these are the allowable descendants

Amelia: we need to say that we can have a data scale but each point on the data scale and have a paragraph of information about it

Fred: it highlights a block of area. … it can be very big on what can be associated with an event

amelia: i like the idea of having a large bunch of content assigned with a data point but I like the idea of using an annotation or describedby relationship that binds them
... we need to accomodate a wide variety of DOM structures that support this.
... the DOM structure should always follow the logical structure but with graphics that can be challenging

jason: we may need to highlight a region of a graphic
... ARIA now has an error message relationship

fred: for testing you might also find a lot of uses for associating information.

amelia: i am worried about a graphics event vs. a point in time vs. a user interaction event

fred: we might want a time event.

amelia: we should avoid the word event and say something like time data item

jason: we need to be comfortable that something only refers to time data items

fred: that one defintitely needs refinement

graphics-guide

A guide object. The graphics-guide role is a subclass of graphics-object. Guide objects may need a aria-type (name TBD) property to help navigation distinguish between two features of the same role. For instance, it will be common to have two axis on charts and both axes will have a role of graphics-axis. To tell the axes apart, aria-type should be used. So the x axis could have a role of graphics-axis and an aria-type of x and the y axis cou[CUT]

a role of graphics-axis and a type of y. It is not valid to assume all guides with the same role should be treated as separate features, for instance a nested bar chart may have multiple x axes at the same nest level which are part of the same feature and a user should be able to directionally navigate between the nested axes at the same level.

fred: the subclasses of guide are:
... graphics guide is a subclass of graphics object
... the first subclass of graphics-guide is graphics-annotation

<fesch> amelia: annotation needs to be more open, needs more complex text content

<fesch> amelia: define more on what is excluded than allowed

<fesch> fred: described graphis-axis

<fesch> jason: add discussion on aria-minvalue, aria-maxvalue

<scribe> scribe: Rich

amelia: you would not have a special role for the label text. It would be a collection of labels inside a graphics axis object

jason: what about the axis label itself

fred: I would call it a graphics title

jason: so any label would be a label for a point
... that seems ok and we just need to clarify it

fred: do we actually have a title role here

amelia: we do at the end

fred: it needs to be a child of axis

amelia: if we are going to say that child graphics role has semantic meaning we need to indicate it

jason: if we are going to use aria-label and aria-labelledby.

amelia: we have a number of places where label is a an independent label that does not label any other object in the accessibility tree.

jason: we need to look for that reason

amelia: I am putting in my concern for the record

Fred: I am going to merge in the additional semantics we agreed to in the graphics module as a branch

jason: I may have issues with the move the next week but I will review the updates

<scribe> Chair: Fred

Amelia: we should make it as a fork as it is easier to merge back in

- DRAFT -

Protocols and Formats Working Group Teleconference

24 Jul 2015

Attendees

Contents

Chart Taxonomy

graphics-dataitem

graphics-event

graphics-guide

Summary of Action Items

Scribe.perl diagnostic output