A proposed system of roles and properties for using ARIA to annotate charts, graphs, and maps. Builds upon the basic ARIA roles for graphics. Compare with the original chart taxonomy proposal by Fred Esch.

Discussion of this and Fred's proposal is summarized on a separate page.

Roles

There are two main super-class roles that apply to all types of structured graphics, defining on the one hand, the type of graphical document, and on the other, the graphical components within it.

The structured graphic roles described here are separate from the img role and the proposed new figure role. The img role is used when a graphic is a single, indivisible element for accessibility purposes; any child DOM structure is ignored except for plain text used in accessible names or descriptions.

The figure role is used to contain an image or graphic and its caption, and describes the relationship of that content to the surrounding text. It can also be used for other content with a similar relationship to surrounding text, such as a labelled code sample. The distinguishing features of a figure are that it is referenced from the flow of text, and is essential for a full understanding of that text, but it can be shifted within that text for presentation purposes without interrupting the flow. For example, an AT creating a paginated version of the document might shift all figures to the end of a section. Figures therefore should have clear labels, preferably as (part of) visible captions.

Document Roles

A graphical document is identified by a role on a containing element. It may be the root element of a complete graphical file (such as an SVG), or it may be a section within a larger document (for example, inside a figure in an HTML page, with an accompanying caption). The current proposal is to have a generic graphical document role as well as more specific roles for graphics which would have semantically-relevant enhancements from accessibility technologies.

graphics-doc

A graphical document is distinct from other documents in that the visual layout of the content has semantic meaning. Navigation methods may take this into consideration. The graphics-doc role is appropriate for labelled diagrams and schematics. The default role for the svg element would be graphics-doc. Alternatively, the following sub-class roles which define graphics with special semantic meaning:

graphics-map

A map is a type of graphical document where the layout of objects represent geographical layout of features in space. It includes blueprints and elevation profiles in addition to latitude-longitude maps.
graphics-network

A network graph is a type of graphical document conveying the relationships between data objects. These relationships may be conveyed with connecting lines or by nesting objects visually within one another. Other names include organizational charts, node-edge graphs, and tree charts. Both nodes and edges may also visually represent data values describing the objects and the relationships.

There have been discussions on the Task Force about whether it is appropriate to have a separate role for network graphs, and if so, whether it should be a sub-class of the data chart role. The distinction originally used was that the particular layout of a network graph can be re-arranged as required, so long as the relationships are preserved. For example, see this discussion of methods to morph the layout of tree graphs in D3; the semantic structure of the tree is not affected by the quite drastic changes in layout. In contrast, if the two-dimensional position of nodes in the graph represents data values on horizontal and vertical scales (separate from the depth in the network tree), the document should be classified as a graphics-datachart instead.
graphics-datachart

A data chart is a type of graphical document in which graphical features (layout, color, shape, etc.) reflect values in a data set. Data charts are defined by the data scales (e.g., axes and legends) and data objects they contain. Users should be able to rapidly navigate to the scales or to the data, and to get either an overall view of the chart or more focused information.

For example, a screen reader might offer an automatically-generated summary of the data as an alternative to the author-supplied description, listing the axes, other scales, number of data points/groups, and their ranges. The user could then either read or skip detailed information about each feature, diving into the chart structure as desired. A screen magnifier might start with a zoomed-out view of the entire chart (possibly with contrast enhancement), and then allow the user to pan and zoom the data area while providing a way for axis and legend information to be visible at the same time.

The original proposal included sub-classes for specific common data chart types. This has been discarded as unwieldy.

Object Roles

Within a graphical document, graphical object roles are used to define the structured components. For datacharts and maps, metadata objects provide the context to interpret the properties of data objects. For basic diagrams, the graphics-object and graphics-symbol roles should be sufficient in combination with group, img, and heading from ARIA 1. The other roles allow semantic annotation of charts, maps, and network graphics.

graphics-object

A graphical object is a component within a larger graphical document. It has a single, cohesive meaning that is distinct from a group of related objects. The graphics-object role itself would be used in a diagram or schematic. It has three direct sub-classes, for icons and symbols in diagrams, for objects that represent data, and for objects that represent metadata or interpretive guides. The latter two have more-specific sub-class roles.

graphics-symbol

A graphic used to convey a simple meaning or category, where the meaning is more important than the particular visual appearance. The symbol itself is an atomic object; children are presentational.

The default role for SVG shapes (circle, rectangle, path, etc.) would be symbol. The aria-roledescription property could be used to provide a more meaningful name for the type of symbol, if appropriate.
graphics-data
A graphical object that represents specific data values. Elements with a role that inherits from graphics-data can be annotated with various data-related properties. This is an abstract role, one of the following subclasses should be used instead:
- graphics-dataunit
  
  A distinct data value in a chart or map. A data unit may contain text annotations or even nested chart objects. (A previous version of this proposal used the name "data point"; this has been changed to emphasize the wide variety of forms an individual data unit may take.)
- graphics-datagroup
  
  A collection of multiple distinct dataunits with a common feature. The individual data points do not need to be plotted individually, but if they are they should be children of the group in the accessibility tree (either DOM children or using aria-owns). If individual data points are not plotted, data summary objects would be used to describe the values that are plotted.
- graphics-dataline
  
  A single element that represents a series of data points in a chart or map.
- graphics-dataregion
  
  A complex two-dimensional feature or contour on a map or chart.
- graphics-connector
  
  A connector object represents the relationship between two other data objects. The connector may itself have data values describing that relationship on one or more scales.
- graphics-summarydata
  
  An element representing some type of statistical summary for a group of data. Examples include trend lines, mean lines, or the various components of a box-and-whiskers box. If an element with this role is not owned by a data group, the summary applies to the chart as a whole.
graphics-annotation

Graphical annotations provide metadata about a datachart, map, or other graphical document. Their visual representations establish scales, color codes, and so on. The added ARIA properties will allow the same context to be communicated to all accessibility technologies. [ISSUE: Should this be an abstract role, or should it be used for generic text annotations? If it is not abstract, then the graphics-note role is probably not required.]
The following particular types of annotations are defined for use in datacharts and maps:
- graphics-datascale
  
  A data scale object represents a dimension of the data and the range of possible values it can include. [ISSUE: Can this role be assigned to a non-rendered metadata object if there is no visible object or group representing the scale? For example, the angular scale in a pie chart is often implicit. How would that affect navigation?]
  
  There are three sub-classes of scales proposed. They would accept the same ARIA properties, but differ in how they can be manipulated in alternative visual presentations:
  
  graphics-axis
  
  An axis object represents a data scale by delimiting the spatial extent of the chart or map region. An axis is usually displayed as a visual line, with ticks or categories arranged along it. The position and layout of an axis are directly related to the position and layout of the corresponding data.
  
  graphics-legend
  
  A legend object represents a data scale as a list of graphical representation. The legend itself may be re-positioned without compromising the information it conveys. A legend may contain a set of graphics-category values, or it may represent a continuous scale, in which case the legend entries would be graphics-tick elements.
  
  graphics-mapscale
  
  A map scale object provides a visual conversion between a defined distance in real world units and the corresponding distance in the graphical display. [ISSUE: How can this be expressed in a machine-interpretable way?] [ISSUE: should a more generic term/description be used, so this role could also apply to dimension lines in technical drawings? ]
- graphics-category
  
  A value within a legend or a categorical or ordinal axis. Usually represented by a visible label plus graphical features such as a matching symbol or an axis tick mark.
- graphics-tick
  
  An axis tick object represents a labelled point on a numerical or time axis or legend. Unlike a category, the axis ticks do not represent an enumeration of all possible values the data should have; instead, the list of ticks are representative landmark points within a range. Visually, ticks are often displayed as small marks on the axis, but may also be represented by grid lines across the entire data chart region. Graticule lines on a map would be considered a type of tick. Unlabelled (minor) ticks or gridlines should be considered presentation, and should not be assigned this role.
- graphics-note
  
  A text annotation that adds additional context or information. May be a child to a particular data object, or data group, or may apply to the chart as a whole. [ISSUE: is a specific role required?]

Comparison with previous proposal

Fred Esch's Chart taxonomy proposal differs in the following ways:

Only one document role (graphics-doc) for all types of diagrams and charts

fe- It is cleaner to have a single type and provide a description of the important aspects of a graphic. Once you enter the rabbit hole of chart types, you can end up with too many as this table of visualization method shows. Note it is cutely laid out like a periodic table of elements. A periodic table of visualization methods

Having a separate role for maps could be useful since many maps cannot be zoomed or resized without violating their projection. The most commonly used projection online is 'web Mercator' which is a modification of the standard Mercator projection and 'web Mercator' behaves better near the poles than the standard Mercator. It is one of the few projections where zooming is easily allowed. But for maps used in cadastral systems, aviation, navigation and on (national, state and local) government maps including state plane systems. Arbitrary zooming and resizing may violate the map projection.

I don't like the distinction of a network chart, which appears to be differentiated on the basis of having edge (connector) elements. An airline chart showing routes is network chart. But if you put a map background on the airline chart, you cannot move nodes around. Adding a background doesn't magically change the chart from being a network chart. Being a network chart does not infer that you can move stuff around.

One role (graphics-dataitem) for most data items, lines, and regions, including summary data features

fe- I prefer two basic data related objects- datagroup (only for <g>) and dataitems which may be any type of element. A datagroup should have some descendants that are dataitems.

There are several problems with the way dataitem is split in Amelia's taxonomy. First they appear to need properties that match visual primitives to make them distinct. For example, could we have a graphics-dataline and give it a closed property instead of having a separate graphics-dataregion?

A second problem is the split is trying to coerce data into unnatural categories of data row, bunch of data and statistic. If we try to look at data that way, is a count a data row, bunch of data or statistic? It could be any of them depending on the way you prefer to look at it. Count is generated by a statistic counting the number of included rows, and provides a single value for each category. The data the charting engine gets will be derived data created to build the chart and whether it takes one row of data or lots of rows of data will be a function of the charting engine rather than the form of the original data. For charting engines I have worked on, doing edges (connectors) takes two data sets - One for the nodes and a second for the edges. Data sets for edges only need (at most) 3 columns - the id of the from node, the id of the to node and an optional weight. Node data sets need an id column and may include any number of additional columns.

Distinct role for graphics-timedata (versus using properties to distinguish)

fe- Time is a common data type. But we could drop this role.

Terminology: graphics-edge (Fred) vs graphics-connector (Amelia)

fe- The edge role came from the example in SVG Connector 1.0, Part 2: Language

Terminology: graphics-guide (Fred) instead of graphics-annotation (Amelia), and graphics-annotation (Fred) instead of graphics-note (Amelia)
Terminology: graphics-scale (Fred) instead of graphics-datascale (Amelia)

fe - Calling a scale a 'data scale' is a pet peeve of mine. Scales are not data and should not have the word data in the name. Scales can be defined independently of data. If you want to compare charts over time or between different charts having a fixed scale for all charts is the way to go.
Chart rendering engines will almost never use the range directly from the data (aka 'data scale'). Usually, you use a nice number algorithm on the data range to expand the scale to nice values for ticks. Often the lower end of the scale is dropped to zero. For example, if you have a data range of 17.3 to 84.4 a rendering engine will adjust the scale to 0 - 100. If you used this scale on sizing a symbol, in the legend you could see sizes for 0, 20, 40, 60 , 80 and 100 (nice numbers). In this case, it would be a horrible legend to have an entry with 84.4 on it. Likewise if you plotted the points on a field defined by the data range - some of your points would be hanging over the neatlines or be clipped.
An appropriate time to talk about a data range would be in the <g> element representing a cluster in a clustered bar chart. There you want to tell the user the valuemin and valuemax bars in the cluster.

Fred did not include a special role for scales on a map, but he did include dimension lines for technical drawings, which are similar.
The graphics-axistick role (Fred) is more specific than graphics-tick (Amelia) which can be part of legends as well as axes.

fe - graphics-tick is fine and can be used on axes and legends. However, there are problems associating ticks with some kinds of legends as noted here SVG_Accessibility/Palettes_for_low_vision_and_color_blind#Issues_marking_up_color_legends .

Fred has special roles for chart grids and map graticules; in this model, they would be associated with the corresponding tick or category label.

fe - I don't like the idea of dropping grids or graticule as they are important and have very different roles on maps.
Traditionally maps are created for humans to use. In many cases, using geographic coordinates (longitude, latitude) are impractical because the units relate to a sphere and the units are too large for a user's purpose. So for legal, engineering, navigation, military and leisure purposes alternate coordinates are used. The alternate coordinates will be appropriate for the map and scaled in usable units like meters. Usually a governing body like a country or state will define and publish the coordinate system based on a datum, map projection formula a local meridian and latitude. The local coordinate system is rectangular (not spherical) and usually have positive values. A grid is defined and placed on maps for easy unambiguous references. Graticule, the system of lines (or arcs) for latitudes and longitudes are also put on the map (people want to know which way is north). Usually graticule is sparse compared with the grid. Lines on the graticule are often considered quite significant.

Fred has a role for labels; in this model, labels are associated solely using the aria-labelledby property, and do not have their own role.

fe - Please see SVG_Accessibility/Palettes_for_low_vision_and_color_blind#Issues_marking_up_color_legends for a discussion on issues with legend ticks.
I have roles for title and label as they are well known components of charts and graphics. I always want focus to be on a label for axes ticks; I don't think there is any other practical way to do stagger legends or continuous legends. When an data object has a label, I always want both the symbol and label to show focus since the label will be the announced text. For legends I can live with the focus on the label alone or on both the label and swatch.
In my demo, titles are treated in a special way. I have the text from the title reported with the semantic parent <g> (or <svg>) element. When I have used titles, their parents have had a role of 'graphics-axis', 'graphics-doc' (figure). And when the title is reported with the parent object, I do not include the title object in navigation. I chose to do this as I find it odd to have a focusable object with a title and have the title not be part of it's description (that is what the title is for) and I find it annoying to have the title in the navigation - since I feel it is part of the description of the parent object. This is a personal preference.

In addition, a key difference between Fred and Amelia's proposals is in how the actual data is presented. Fred favored author-supplied plain text descriptions of values and their significance. The model described on this page emphasizes machine-readable data that can be summarized or manipulated by accessibility technologies. This data is attached using the ARIA properties described below.

fe - I think using aria-valuemin and aria-valuemax is quite useful. We also added an aria-categories but I did not have an example that used it.
I introduced aria-gtype which can split elements with the same semantic parent and same role into multiple distinct map features. The classic example being used with the role 'graphics-axis' and differentiating between the x axis and y axis. In my demo, I used aria-gtype in the accessible name calculation as well so if you gave an element a role of graphics-axis and an aria-gtype of x (and no additional descriptions) the accessible name was "axis x".
I agree that we need a method for attaching data value tuples to data items. However, I doubt charting engines will always populate this and I don't see how tuples for lines and regions will be accomplished.

Properties and States

ARIA attributes would be used to provide the data itself in machine-readable format, as well as to describe the relationships between data and axes or other scales. For most uses, these attributes would be static properties. However, more complex graphics might update data live or include widgets for changing the view (with appropriate widget roles, of course!).

Existing ARIA attributes have been adapted whenever practical, to minimize additions to the namespace. New attribute names are noted below.

Global attributes

All the ARIA 1.1 global attributes would be applicable. The following are most likely to be relevant:

aria-label or aria-labelledby: to set a short name or associate an object with its visible title/label
aria-describedby: to provide free-form alternative text description, or link to visible footnotes or annotations
aria-roledescription: provides a context-specific name for the type of object. For example, data item in a pie chart may have a role description of "slice"; a data group in a stacked bar chart could have a role description of "stack". This can help effectively describe charts with nested group structures. The chart itself (with role of graphics-datachart) may have a role description of "pie chart" or "stacked bar chart".
aria-live: to identify data that will be updated (and related properties aria-relevant and aria-atomic)
aria-haspopup: to indicate that author-generated tooltips are available to provide more information about a data item
aria-owns: to identify data items with the correct data group, or categories/ticks with the correct axis/legend

Attributes for data scales

The following attributes describe the metadata associated with each scale (axis, legend, or mapscale):

aria-orientation

used for elements with role graphics-axis or graphics-mapscale to indicate the direction by which values on the axis differ. This specification adds the values depth (for 3D projection views) and other (for angled axes or polar coordinates) to the enumerated values of horizontal and vertical defined in ARIA 1.

aria-dataunit (new)

used to assign a unit to numerical values on an axis or legend, and therefore to the associated data values. The property value would be a free-form localized string, such as "cm" or "thousands of US dollars".

fe - This is OK if it is not used to 'format' values. That is if a value is 23 and the dataunit is cm. I would object to assistive technology reporting 23cm for a value.

aria-valuemin

aria-valuemax

used for elements with role graphics-datascale and aria-datatype of ordinal, count, number, portion, datetime, or duration. The string value of the property should be converted to machine representations according to the rules for the data type. The values represent the plausible or normal range of data on the scale, and not necessarily the range of the actual data set.

The default for aria-valuemin on a graphics scale is negative infinity, except for aria-datatype of count or portion, in which case the default is 0.

The default for aria-valuemax on a graphics scale is positive infinity, except for aria-datatype of portion, in which case the default is 1.

ISSUE: is there a better equivalent to positive/negative infinity for datetime and duration?

ISSUE: Should the user agent calculate default min and max from the axis ticks if not otherwise provided?

aria-datatype (new)

used to indicate the type of data which is measured on that scale. It is used to guide any statistical summaries and for the parsing of data. [ISSUE: Is it appropriate to use a property to define these distinctions, or should we use sub-classed roles? Note that the defaults for other properties will depend on the data type.]

Data type would be an enumerated property. The initial proposal is to use the following values:

boolean (true or false)
category (enumerated strings)
label (enumerated strings automatically generated by the user agent from the labels of data objects)
ordinal (enumerated strings, each with an associated numerical index values)
count (positive integers)
number (any numerical value)
portion (a numerical value between 0 and 1, inclusive, optionally represented as a percentage)
datetime (any point in time, including floating times or dates where some parts of the datetime are not specified)
duration (a span of time)

The default is category. [ISSUE: is that the best default?]

This set of data types was proposed based on statistical theory and common chart types. However, similar divisions (albeit for other purposes) exist in other specifications. Charles McCathie-Nevile suggested we consider the XML Schema data types as a possible basis (See also this summary page from MSDN).

The metadata on the scales would then be used to complement attributes set on the actual data items. In particular, the data type would determine how data values are parsed, as well as how to parse aria-valuemin and aria-valuemax on the scale and aria-valuenow on ticks and categories.

The following parsing rules are proposed:

Data values assigned to boolean, count, or number datatypes should be coerced to the appropriate data type following rules defined in [ECMAScript]. Numerical values which cannot be coerced or are otherwise invalid (e.g., negative values for count data type) are equivalent to NaN (not-a-number).
Data values assigned to a portion data type that include a percentage sign should be converted to a floating point number by (a) removing the percentage sign from the string, (b) coercing the remaining string to a floating point number following rules defined in [ECMAScript], (c) dividing the result by 100. All other data values should be coerced to a floating-point number following rules defined in [ECMAScript]. The following percentage signs should be considered valid:
- % Ux25 Percent Sign
- ٪ Ux66A Arabic Percent Sign
- ﹪ UxFE6A Small Percent Sign
- ％ UxFF05 Fullwidth Percent Sign
Data values assigned to a datetime and duration should be coerced to a machine representation following the rules for datetime and duration microsyntaxes defined in [HTML 5].
For category and ordinal, user agents should construct a map of category codes (aria-valuenow values) and category labels (aria-valuetext values) from all graphics-category objects that are owned by this graphics-datascale object. Data values assigned to this data type should be matched against category codes first (using numerical coercion for ordinal scales), and category labels second. If the data value does not match any specified category codes or labels, then the data value should be used to generate a new category with the same value for code and label. For category, the data value should be treated as a literal string. For ordinal, the data value should be coerced to a number.
For label, the user agent should generate a set of category strings from the labels of associated datapoints, following the rules for the generation of an accessible name for each element.

Attributes for ticks/categories

Elements with role graphics-category or role graphics-tick to represent the value for that tick or category

aria-valuenow: A machine-interpretable value for the tick or category. For scales of data type category this can be a short code which will be used when assigning data. For scales of data type ordinal, it must be a numerical code which will be coerced as a number data type to create the ordered index for this category. For all other scale data types, the value should be interpreted according to the rules of that data type. If not specified, it defaults to the value of aria-valuetext.
aria-valuetext: A human-interpretable string equivalent for the tick value or category label. If not specified, it defaults to the accessible name of the object, which may simply be the text content of the element.

ISSUE: These attributes were chosen because they already exist in ARIA (for assigning scales on range sliders). The naming scheme does not quite complement the rest of the aria-data* attributes proposed here. In particular "value now" does not seem appropriate for multiple, unchanging points on a scale. Is it worth creating specific attributes? Or should we use the aria-datavalues attribute proposed for data points, despite the fact this would be a single value?

Attributes for data items

The following attributes would describe data values on individual data items or data groups:

aria-posinset
aria-setsize: These would be used if the current chart DOM only includes a portion of the complete data set, to keep track of the position within the data group or data set as a whole. NOTE: current practice in ARIA is to specify the set size on every individual item. It would be preferable to be able to set it once on the group, but that would cause ambiguity with nested groups.
aria-datascales (new): used for elements with any role that is a sub-class of graphics-data, to associate the data values with the metadata from the scales in the chart, map, or network graph.; The value of aria-datascales is a delimited list of ID-refs to graphics-scale objects (including axes and legends). The scales referenced in aria-datascales should not include any scale with datatype of label (for which the data values are automatically generated from the accessible name of the data point or group). There may be repeated references, if multiple data variables are measured on the same axis (e.g., for data objects that represent max/min extents).; A graphics-map document has an implicit aria-datascales value pointing to the generated latitude and longitude scales (in that order). A graphics-datachart has an implicit aria-datascales value pointing to the first graphics-datascale object in the chart with a aria-datatype other than label. These defaults should help provide minimum accessibility to incompletely marked-up charts.; The proposed data structure would follow comma-separated variables format, with nested strings when required [ISSUE: need a character escaping syntax in case data strings include apostrophes/quotation marks]:
aria-datascales="company-axis, revenue-axis"
aria-datavalues="'Acme Corp.', 12000000"
aria-datavariables (new): Human readable names for each entry in the data scales list. If not provided, it defaults to the accessible name of the scale. Explicit data variable names should be provided if there are multiple variables measured on the same scale for each data unit (for example, if the data objects represent max/min extents or intervals).; (A previous version of the proposal called this property aria-datavariablenames.)
aria-datavalues (new): for elements with any role that is a sub-class of graphics-data, to associate the actual data values on each of the scales in the chart, map, or network graph.; The value of aria-datavalues is a delimited list of data values. Each value will be interpretted according to the rules of the data type for the scale identified by the corresponding entry in the aria-datascales list.
aria-datavaluearray (new): used for elements with role graphics-datagroup, graphics-dataline, or graphics-mapregion to represent an array of datapoint values. Each entry in the array should be parsed as if it was an aria-datavalues value for a separate data item that was a child of this element.; The proposed syntax uses square brackets to delimit each data point in the array, and CSV syntax within each set of brackets. In other words, nested quotation marks would only be required if strings may contain commas or brackets:
aria-datascales="x-axis, y-axis, category"
aria-datavaluearray="[1, 100%, 'Smith, J'],[2, 70%, 'Lee, H'],
[3, 85%, 'Cisco, Y']"
aria-dataproperty (new): used to indicate which style property or attribute of the data items are modified for each data variable. This information could potentially be used by an AT to replace unsupported properties with alternative information representations, such as replacing colors with textured patterns or with text labels. More generally, it could be used to describe the chart to a non-visual user in a way that allows them to effectively communicate with visual users.; The value is a comma-separated list (matching the other lists for variable name and scale). However, each value in that list is then parsed as a space-separated list of multiple property/attribute names. Tokens are matched as style properties first, DOM attributes second. Attribute names may include prefixes according to the parsing rules of the markup. [ISSUE: should there be a syntax for clearly indicating that a token is an attribute name?][ISSUE: Should there be a way to indicate changes to text content or child DOM structure?]; For example, a chart might have two different variables measured on the same color scale, one is represented by the fill of each symbol while the other is shown by the stroke.
aria-datavariables="Date, Value, Initial Status, Final Status"
aria-datascales="date-axis, value-axis, status-legend, status-legend"
aria-dataproperty="x,y,stroke,fill"; Alternatively, a single categorical variable may be represented both by a change in symbol shape (the d attribute of a path element or the href attribute of a use element) as well as a change in color.
aria-datavariables="Height, Weight, Sex"
aria-datascales="x-axis, y-axis, legend"
aria-dataproperty="x,y,xlink:href stroke"

For all the list-based data properties, a cascading approach applies for items in groups (and for arbitrarily deep nesting of groups). The list specified for this element is appended at the end of the list assigned to a parent element. The final data set applicable to each item is the concatenation of all data values assigned to parent grouping levels. Attributes describing the variables in general can be assigned at a higher level of grouping than actual data values. For example, part of a clustered bar chart that compared accident rates by season and day of the week could be annotated something like this:

 <g role="graphics-datagroup" 
    aria-datascales="seasons, x-axis, y-axis"
    aria-dataproperty="fill transform, x, height y" >       
   <g role="graphics-datagroup" aria-datavalues="Winter"
      transform="translate(...)">
      <rect aria-datavalues="Monday, 33" ... />
      <rect aria-datavalues="Tuesday, 31" ... />
   </g>
   <g role="graphics-datagroup" aria-datavalues="Spring"
      transform="translate(...)">
      <rect aria-datavalues="Monday, 27" ... />
      <rect aria-datavalues="Tuesday, 25" ... />
   </g>
 </g>

Attributes for connectors

TODO: Probably using the following properties:

aria-owns
aria-flowsto: These provide a unique way of defining connectors, but not necessarily the most convenient. Would it be better to also have properties for the reverse relationships?

Comparison with previous proposal

Fred Esch's Chart taxonomy proposal uses labels and descriptions for most metadata. It would use aria-valuemax and aria-valuemin for axes (as above) and for data groups (including situations where it would not be required here, because it could be calculated from the data).

Fred also introduced an aria-categories property (I'm not sure if it would be a property of the data item or of the scale) and the aria-gtype property, which would be used to add extra details to many different roles, such as the type of axis.