Protocols and Formats Working Group Teleconference -- 21 Aug 2015

<scribe> Scribe: Amelia

trackbot, start meeting

<trackbot> Date: 21 August 2015

<scribe> Chair: Fred

<scribe> Scribe: Amelia

Graphics module Roles

Fred: I've removed the iconbutton role, as we agreed last week.
... Last week, we were talking about data visualizations. Doug requested the NACM reference, which I sent out.

Jason: I raised a few issues on the list after last week's meeting. But lets decide what we want to do about optional data values first. We'd discussed earlier how we need a way for authors to specify actual data values, for e.g. sonofication tools or summary statistics. We agreed we wouldn't *require* raw data, but we were discussing how it might be done, by specifying different data dimensions.
... So I think we have some work to do on that side, as well as fine tuning of the taxonomy.
... In Fred's response, he identified some areas where we will need to specify lacuna values in order to support some of the navigation issues I brought up in my notes.

Rich: I'm trying to understand the first paragraph of your post, re "Charts are very diverse..."

Fred: It comes down to trying to draw things without z-index: an axis may be broken into two groups, some drawn underneath the data and some drawn on top of it.

Rich: So does the issue become a timing issue, or what?

Fred: It's about organization of the navigation of the axis. You navigate to the axis as a whole, and then to the content, the categories or the labels.

Rich: As an aside, we're really going to have to come up with an alternative to "labels". That's a little confusing. These are data objects on their own.

Fred: Well the other name is "ticks". You have major and minor ticks, although minor ticks would really just be noise, you wouldn't want to read those out. But that's somewhat a technical jargon word.

Rich: But I think that's the correct word. There will be some need for education, if people aren't familiar with the terminology.

Jason: I certainly would want to learn the correct terminology that people actually creating the software would use.

Rich: Something to discuss is how the ARIA properties apply. For example, aria-setsize and related properties. You may not be drawing the entire dataset at all times, you may be zoomed in and only drawing some, so you need to keep track of the position in the larger dataset.
... Likewise, the DOM order may not be the logical order.
... For ticks, we would need a role and a label.

Fred: But we wouldn't really want people to navigate to the little tick, but to the label. Sometimes the tick wouldn't be there.

Amelia: Basically, we would say that an author-supplied name is required for the role, but name could come from contents and the role could be applied to the visible text element instead of the mark.

Fred: But if you're navigating through, wouldn't be easier to have the text highlight from the focus instead of the tiny tick line?

Amelia: Ideally it would be both, but that's somewhat difficult to do in CSS currently.

Rich: Can you explain the issue with grouping?

Fred: You may have lots of intermediary groups for positioning or styling. So are we going to have to use aria-owns?

Rich: Or the intermediary groups would have a role of none, which I think they should by default.

Amelia: Yes, based on our API mappings. If there is no specified role and no title, etc., it should be ignored.

Fred: OK, that works. Now the problem that I have with ticks is you really want the focus to be on the visible label, and you want it to read out the formatted text for that label, regardless of how the category is represented in the underlying data set.

Rich: So someone exploring an axis group would want some overall summary information about the axis. And then inside it, they could cycle through the relevant tick labels.
... How should this navigation be communicated to the user?

Fred: Sighted users would depend on arrow keys, but otherwise you'd just cycle through based on DOM order.

Rich: I'm not sure we can depend on the DOM order. We have to be open to other author patterns.

Amelia: DOM order would be the default, but aria-posinset could be supplemental information or alternative information if the DOM tree doesn't represent the complete logical data set.

Jason: One thing with posinset, it is currently information presented to the user, but it isn't used to actual re-order the values as they are presented to the user.

Rich: That would be something new, we would have to require user agents to navigate through based on set positions.

Amelia: I don't think it's unfair to require authors to organize their DOM so that ticks are organized in a logical order and use that.

Jason: Maybe for tick labels, but the same issue comes up with navigating through data.

Fred: For data navigation, you have a few different requirements. Sighted users will want to use 8-way directional navigation. But non-visual users might want something like going straight to the max or min.

Rich: When it comes to sorting data, I think we want to ask ATs to implement those sort of sorting functions.

Fred: Because the actual DOM order is usually based on the drawing order, which might have other purposes, or might be based on the source data table.

Rich: I think we could make a resolution, that we are not going to require authors to re-organize their DOM, ATs should be able to sort things into the correct order based on posinset.

Fred: posinset doesn't work for data points

Rich: Or the data values for data points.

<scribe> ACTION: Rich to add mention of aria-posinset calculation for axis ticks to the SVG AAM spec [recorded in http://www.w3.org/2015/08/21-svg-a11y-minutes.html#action01]

<trackbot> Created ACTION-1704 - Add mention of aria-posinset calculation for axis ticks to the svg aam spec [on Richard Schwerdtfeger - due 2015-08-28].

<scribe> ACTION: Rich to talk with AT vendors about how they can present axis structures [recorded in http://www.w3.org/2015/08/21-svg-a11y-minutes.html#action02]

<trackbot> Created ACTION-1705 - Talk with at vendors about how they can present axis structures [on Richard Schwerdtfeger - due 2015-08-28].

Fred: Do we want to talk about how data is represented?

Amelia: I still have a TODO to write up a proposal.
... One thing I thought of based on Fred's comments earlier, sometimes you'll have a simple category scheme, e.g. integer values, versus longer labels that are human readable
... So we would want a way for user agents to match short codes attached to each data object with the readable label defined on the axis/label.

Fred: That sort of encoding may not always save data; it depends on how many categories there are in the data compared to what you're displaying.
... And the data should not depend on the axis, that axis could be optional or could change depending on the view. There isn't a native-to-SVG way to describe this.

Amelia: I'll try to write something up so we have something concrete to discuss.

Fred: The other issue is number formatting. The precise numbers that are useful to the computer aren't necessarily what we want read out to users.

trackbot, end telcon

- DRAFT -

Protocols and Formats Working Group Teleconference

21 Aug 2015

Attendees

Contents

Graphics module Roles

Summary of Action Items

Scribe.perl diagnostic output