Minutes: August 14, 2015 SVG Accessibility Task Force

http://www.w3.org/2015/08/14-svg-a11y-minutes.html

Text:

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
      Topics
         1.	Graphics Module
         2.	iconbutton
      Summary of Action Items



<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]


Rich Schwerdtfeger