See also: IRC log
<trackbot> Date: 24 July 2015
<scribe> Meeting: SVG Accessibility Task Force
<fesch> https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Navigation_Supported
<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
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.
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
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/density for a point/density for each square in a grid/ Succeeded: s/does not show up/does not label any other object/ No ScribeNick specified. Guessing ScribeNick: richardschwerdtfeger Found Scribe: Rich Found Scribe: Rich Present: Rich Amelia Jason Fred Found Date: 24 Jul 2015 Guessing minutes URL: http://www.w3.org/2015/07/24-svg-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]