- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Fri, 17 Jul 2015 08:53:49 -0600
- To: public-svg-a11y@w3.org
- Message-ID: <CAFDDJ7wnNwy36S9-MB9VgwrVfBqDci=_-UrLFTD7cvHEp4vNSw@mail.gmail.com>
We spent the hour talking about Fred's draft Chart Taxonomy, available on
the wiki here: https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy
Minutes, as HTML: http://www.w3.org/2015/07/17-svg-a11y-minutes.html
Minutes, as plain text:
http://www.w3.org/2015/07/17-svg-a11y-minutes.html,text
Copied below for the email archives.
_________________________________
- DRAFT -
Protocols and Formats Working Group Teleconference
17 Jul 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/07/17-svg-a11y-irc
Attendees
Present
AmeliaBR, shepazu, fesch, jasonjgw
Regrets
Chair
SV_MEETING_CHAIR
Scribe
AmeliaBR
Contents
* [3]Topics
1. [4]Chart Taxonomy
* [5]Summary of Action Items
__________________________________________________________
Chart Taxonomy
<fesch>
[6]https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Kno
wn_Bug_in_Navigation
[6] https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Known_Bug_in_Navigation
trackbot, start telcon
<trackbot> Date: 17 July 2015
<fesch>
[7]https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Kno
wn_Bug_in_Navigation
[7] https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Known_Bug_in_Navigation
Fred: I put together a sample chart taxonomy, extending the
basic graphics-document and graphics-object for the ARIA roles
for graphics.
Doug: Is this just based on your taxonomy from previously, or
did you try to integrate mine?
Fred: No, I haven't integrated that yet.
... In addition to roles, I'm using the aria-type attribute to
clarify between different features when there are multiple
objects of the same role, such as x or y axes.
AmeliaBR: For axes, we could use the specific ARIA role for
defining horizontal vs vertical direction.
Fred: Maybe, but it isn't just for axes. E.g., on the box and
whisker plot, there are multiple types of data for each object:
median, quartiles, ranges, etc.
... I have a definition there. Basically, it depends on the
role which type of information is used in aria-type.
Doug: Is there any precedent in ARIA for an open-ended string
to be used to distinguish between different objects? Basically,
you have no restrictions on the values for aria-type. Are there
any other ARIA attributes that take string instead of
enumeration?
Fred: Well, aria-label, I guess.
Doug: I understand why you did it this way, but you've now got
an attribute that is supposed to be context-dependent and
flexible but also machine readable for distinguishing
functionality.
Fred: Well, I have labels as way, but I expect the browser
would also have a way to localize the role and type and add
that to the name.
Doug: That's not what I'm getting at.
AmeliaBR: I agree that it is a problem to use one attribute for
many things. We want to keep things simple, but we would need
to enumerate all the possible values at some point.
Fred: I'm not sure that's possible.
AmeliaBR: If you want flexible distinctions, you could use
aria-roledescription, which accepts freeform strings. But don't
expect AT to do anything with that except repeat it to the
user.
Doug: This is similar to my point. aria-type could mean
different things in different contexts, which make it different
to implement. It varies depending on the role. So aria-type
only has meaning when it is paired with something else.
Fred: Paired with the role. So maybe call it aria-roletype.
Doug: It introduces a little ambiguity with regards to what
values it can take. I understand you want to be flexible for
any data facets, many different axes or legends for different
types of charts.
Fred: And you can have multiple chart panels that are
themselves nested in other axes, e.g. a SPLOM a giant matrix of
charts.
Doug: There's any number of type of axes you can have, so I'm
sensitive to that. But there are two things to consider: the
conventions around what type of axes are used for a given chart
and what they are called, but also the machine has to
distinguish between them.
... Honestly, I was always uncomfortable with this part. There
need to be defined semantics, but it also needs to be
extensible.
Fred: Where there are conventions, I have tried to give things
distinct roles, such as graphics-charttitle.
Doug: I'm mostly talking about aria-type. I'm uncomfortable
with it being able to be anything. That creates incredibly
loose semantics.
... It's not machine-readable.
Fred: If you expect the machine to do anything other than
announce it.
... but it is really just for announcing and navigation. You
can't make the machine do everything, you can't capture all the
possibilities.
AmeliaBR: We need to distinguish which parts of information
need to be machine-readable and which need to be open-ended.
<fesch>
[8]https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Nav
igation_Between_Features
[8] https://www.w3.org/wiki/SVG_Accessibility/Chart_Taxonomy#Navigation_Between_Features
Doug: I'm looking at this as someone who has implemented a
screen reader, albeit a very simple one, for charts. Axis type
means something to my screen reader as a grouping mechanism. I
also called the axes x and y, but you could also say, e.g.,
dependent and independent.
Fred: But the screen reader shouldn't have to figure that out.
The aria-type just get appended on the end.
Doug: Would this be translated?
Fred: No, the role axis would be, but the type would not. It
would be given in the language of the document.
... The author should know what's meaningful in that domain,
more than an AT developer.
... It guides the chart navigation to split the feature when
the type is different. If elements have the same parent and
same role & type, they are treated the same. If different, they
are treated differently.
Doug: For one thing, I'm not comfortable with a generic name
like aria-type, which could conflict with other taxonomies, and
that it can be used for so many different things. It is being
used for data-related things but also for other things like
annotations.
... I would like to separate out the data facets (axes,
legends, etc.) from other things in the chart. I don't what to
use the same property for everything.
... My screenreader would deal with those completely
differently. For data facets, it doesn't just announce them
when you get to the axis, but it uses them as a set of values
as the basis for summary statistics for the whole chart,
regardless of where in the graphic they are displayed.
Fred: I think the problem there would be if you've got
mutliple-panel charts, where axes can be different for each
nested chart.
Doug: I kind of treat that as a different feature of the chart
from axes.
... I would call each one a separate chart. But I understand
why you're not, since they may share common features.
<jasonjgw>
<jasonjgw>
Fred: For panels, they share the same data set, they are just
different columns of the graphic. But in other examples, you
can have paired charts which are separate data sets but share
axes, e.g., the box and whisker charts on the wiki page.
<fesch>
[9]https://www.google.com/search?q=napoleon%27s+march+to+moscow
https://www.google.com/search?q=napoleon%27s+march+to+moscow+minard&biw=1122&bih=657&tbm=isch&imgil=9_ZYZP9kn3XOgM%253A%253B--a2gg5AGLlanM%253Bhttp%25253A%25252F%25252Fwww.masswerk.at%25252Fminard%25252F&source=iu&pf=m&fir=9_ZYZP9kn3XOgM%253A%252C--a2gg5AGLlanM%252C_&usg=__AUtBR_65T5wBRYE2Fp_hJmGbDUU%3D&ved=0CDMQyjdqFQoTCPbMtrWr4sYCFcGMDQoddsILfQ&ei=NwypVbbVLcGZNvaEr-gH#imgrc=9_ZYZP9kn3XOgM%3A&usg
+minard&biw=1122&bih=657&tbm=isch&imgil=9_ZYZP9kn3XOgM%253A%253
B--a2gg5AGLlanM%253Bhttp%25253A%25252F%25252Fwww.masswerk.at%25
252Fminard%25252F&source=iu&pf=m&fir=9_ZYZP9kn3XOgM%253A%252C--
a2gg5AGLlanM%252C_&usg=__AUtBR_65T5wBRYE2Fp_hJmGbDUU%3D&ved=0CD
MQyjdqFQoTCPbMtrWr4sYCFcGMDQoddsILfQ&ei=NwypVbbVLcGZNvaEr-gH#im
grc=9_ZYZP9kn3XOgM%3A&usg
<fesch> =__AUtBR_65T5wBRYE2Fp_hJmGbDUU%3D
<fesch> [10]http://www.masswerk.at/minard/
[10] http://www.masswerk.at/minard/
Doug: I think it is usually easier to just create two separate
charts, and just not show the axis on one of the charts than to
try to explain to the machine that the axis should be used from
a separate chart.
Amelia: That is asking the author to insert extra markup that
they wouldn't otherwise do. And yes, if you're using software
it wouldn't necessarily be difficult, but it is still asking
authors to do something extra, keep two things coordinated,
just to make things easier for a computer.
Fred: I've pasted the link to the Minard chart of Napoleon's
retreat. This is one of the most famous data visualizations.
The axes are re-used and you can't divide it into distinct
sub-charts.
Doug: This is a particularly complex example. How you recreate
it, and how you make all the data facets accessible, is going
to be much more difficult than simply defining extra axes and
then making them invisible.
... I'm not sure why you're bringing it up.
Fred: Simply because I think you're trying to over simplify
data visualization, and say that everyone has to make charts a
certain way.
Doug: That's basically what we're trying to do in this working
group. Create simple rules for how people can make simple
charts.
Fred: I don't think you can ask people to put extra elements in
the chart that they don't want to draw.
Doug: But we're asking them to add in values, which might not
ever be printed on the chart.
Amelia: Doug, why don't you try to come up with some
alternative proposals for things you have a concern with? And
I'll do the same.
Received on Friday, 17 July 2015 14:54:18 UTC