Protocols and Formats Working Group Teleconference -- 28 Aug 2015

<trackbot> Date: 28 August 2015

<richardschwerdtfeger> meeting: SVG Accessibility Task Force

<chaals> scribe: chaals

<scribe> Meeting: SVG accessibility TF

<fesch> scribe: fesch

<scribe> scribe: chaals

High level Overview Ameila’s Proposed Reduced Model

<AmeliaBR> Amelia's email outlining an aria model

<AmeliaBR> https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug/att-0022/graphics-roles.html

ABR: Trying to take a high-level approach, and grouped the roles based on the hierarchy to make it easier to see how they relate.

<fesch> ab: trying to take a more generalizable approach to roles that is more focused on data, grouped roles by hierarchy

… broken down in roles that inherit from graphics-doc

… and roles that inherit from graphics-object.

…graphics-doc is a concrete role for diagrams that have structures but not particularly unique structures. Might still have directional nav, but that is about it.

… There are 3 subsets - maps, network graphs such as org charts where the connections matter but topology is mutable, and data charts, which have e.g. axes relevant to the data.

… have suggested some subtypes, not sure if we want to get that specific. Is it possible to talk of default behaviours for common types e.g. bar or pie charts

… e.g. pie charts may not need to declare axes, just auto-generate from the graphic structure.

… one idea people can look at.

… or will it introduce too much complexity and we should require explicit authoring.

… those top-level types would be set, we've already talked about the collection types where you want to nest.

… other objects have specific charting roles.

… tried to cover most of the things fred had, but grouped them together more so you use the same role for charts and maps, regardless of how they are displayed.

… gridlines and tickmarks are conceptually teh same, for example.

… ahve basic graphic-symbol - one for data-related objects, one for annotation-related objects - all the metadata of a chart.

… I have used this more generally than Fred's term meaning text annotations.

FE: I used guides for everything like that.

ABR: Within that I have data-scale, important for properties that define dimensions of the data, datatype (number, date, …)

… this will explain the valid ranges.

… within that are seperate subclasses for axes vs legends - legends can be moved independent of the rest of the blocks without changing the meaning, but axes can't.

… They both use the same properties, such as circle size being meaningful, and you show examples in a legend.

… Other type of annotations are the category names and tickmark labels, which are 2 different roles.

… category is exhaustive list, tickmarks are rough pointers along the way...

… For data I have datapoint, datagroup, datalines e.g. for a trend line, and dataregions.

… have connectors listed as a subclass of data.

… connectors might have data attached to it. Also have a role for summary objects.

… still need to think about how you explain what type of summary that is.

… To get into properties. To have machine-readable data we need to define what type of data that is, so you have a property on scale, what type of data is in there - number, datetime, enumeration, etc.

… For each of those I have some rules for converting strings to machine-readable value in the category.

… referencing ECMAscript parsing for most, but not datetime where I ref HTML5 - which inherits from ISO8601

… Idea is you declare the actual data on objects - data points, or bars, as a string attribute, and it would be matched up.

… farther down data-values are attached to data objects, data scales are a list of idrefs to the values.

… e.g. for a bar chart you would have legend - X axis, with value on category, to minimise markup suggest data-scales attribute would be inheritable.

… You could define the order of data once for the chart or group.

… and single attribute for giving an array of data values all at once.

… please look at syntax, does it make sense, etc

… (please skip typos…)

… not sure how we represent network graphs, have some things using the area value attributes that exist for widgets describing range of axis.

… and to associate readable names with short codes, so you need a numeric code defining order of ordinals, but might want to have meaningful text values like never, sometimes, often, always. Using aria value attributes we already have for that.

… mostly trying to get things in writing that I talked about.

FE: Can you make examples using this

<Zakim> chaals, you wanted to say it will introduce too much complexity

<inserted> scribe: fesch

chaals: make an example of the hierarchy using your markup, worried about trying to identify chart types, focus on data
... wouldn't you use aria-labeledby when you have a label
... can't we use desc or describedby?

<chaals> scribe: chaals

<fesch> chaals: when i put examples on the wiki I used a description of a trend line ...

RS: Do we need a summary property?

ABR: Not sure.

… maybe when we start working out examples we discover they are just normal text annotations...

DS: Stupid question. Glad to see datatype. Is there something that gives you the unit? This is an SVG question - don't now how to have child elements in the title element. Have we fixed that?

ABR: Nothing supported cross-browser. You can put them there but they won't have any impact.

DS: In the spec?

ABR: Says you are allowed, but not what happens.

DS: Spec should have a way of saying what can go in there - like tspan allowing you to seperate out different values, add units, …

… datapoints may carry more than one-dimensional info. We need to allow for that

<scribe> ACTION: shepazu to ensure title can carry multiple children for e.g. data arrays [recorded in http://www.w3.org/2015/08/28-svg-a11y-minutes.html#action01]

<trackbot> Error finding 'shepazu'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

<richardschwerdtfeger> ACTION: Doug Define changes to <title> that specifies how to deal with child content [recorded in http://www.w3.org/2015/08/28-svg-a11y-minutes.html#action02]

<trackbot> Error finding 'Doug'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

FE: Didn't finish reading, but agree with chaals about using visible text and desc elements when you need a description.

… concern about chart breakdowns, think they need work.

… not sure if we really need a datatype in practice

… not sure chart engines will provide that information.

ABR: Anyone who uses D3 will be familiar with most of these names. That is how they do it.

RS: ARIA TF is supportive of putting a figure role in. Want to tweak this a bit.

… need that in HTML-AAM spec too.

… need something for basic shapes. Don't see that. Would that be another subclass of graphics object?

ABR: Don't recall what I did but we agreed not to have specific roles for different shapes. Decided it wasn't going to be useful

… suggested it would be a symbol.

… otherwise img

RS: If you draw the US, each state has a name. Are the states symbols?

ABR: Yes you have 50 labelled symbols with descriptions.

… you could use dataregions, too.

RS: So someone labels a circle, with no role, what should it default to?

ABR: Decided not to have specific primitives, so it would be a symbol. We could discuss whether it makes sense to have defaults for properties.

… so if you have stoplight with 3 circles you get 3 symbols.

RS: So we would have CA symbol for an outline of California. OK, will have to update mapping spec.

ABR: Have this in there as notes...

… a note says if symbol is introduced it would become the default mapping.

… to get this integrated we need to look at what roles exist in accessibility APIs

RS: We may have to create new ones.

<Zakim> chaals, you wanted to get action to ask the chartist.js guy about this in an hour

<scribe> ACTION: talk to Gion Kunz (chartist.js maintainer) and ask him about what roles/properties would make sense … [recorded in http://www.w3.org/2015/08/28-svg-a11y-minutes.html#action03]

<trackbot> Error finding 'talk'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

<scribe> ACTION: chaals to talk to Gion Kunz (chartist.js maintainer) and ask him about what roles/properties would make sense … [recorded in http://www.w3.org/2015/08/28-svg-a11y-minutes.html#action04]

<trackbot> Created ACTION-1713 - Talk to gion kunz (chartist.js maintainer) and ask him about what roles/properties would make sense … [on Charles McCathie Nevile - due 2015-09-04].

FE: So read this carefully for next week please.

… one issue I found, that I think will apply for any taxonomy...

Legends

FE: When you have a legend entry it has a symbol and text label.

… trying to make a shadow DOM the AT could use now I ran into a problem where we say a graphic symbol is atomic - no meaningful children. A square box or path cannot have a lot of children

… In a legend entry you would read the label, but no way to give the description of a symbol itself...

<Zakim> chaals, you wanted to suggest how you do this

CMN: You say the text key is labeledBy the box, whose desc says "fuchsia with cross-hatching" or whatever…

FE: OK

… was intrigued by the ARIA data scales and where they would be defined…

… where would they be defined, what would they look like?

ABR: Got some and some issues. You attach metadata for scales to axis or legend…

… guess that is where you put units.

… that would be another attribute on the axis.

… e.g. date range, or 0-100000 in USD …

… definitely something to talk about - we want machine-readable data

<Zakim> chaals, you wanted to say we have values, min, max, in aria, and lots more in XSD

CMN: We can use XML Schema datatypes instead of reinventing it

ABR: These are datatypes for schemata of allowed values

RS: How does that go in accessibility API mapping

CMN: Think in most cases we can use the raw text as descriptions through the accessibility API

FE: posted examples with what is in the markup, and a page to show the shadowDOM

… as an exercise in trying to figure out how this works.

[+1 to fesch on worked examples]

… mostly so e.g. Jason/Léonie can see how this might actually work out.

<AmeliaBR> Fred's experiments - see number 2

RS: Would really like to lock down roles we have and focus on attributes we need. The fewer roles the better. So we have to work through more examples, to give us a chance of getting this out at the same time as SVG 2

… can we lock roles in the next month, to get mapping guide fleshed out, and include native semantics in SVG2 pointing to this…

… Aim is to lock down by the end of the year for CR.

… Want to start new charters for ARIA, need to do a lot for web components. Want to get SVG on the same level as HTML for accessibility.

RS: What attributes are we going to need, how do we map them to accessibility APIs

… would like to get a version of the graphics module out in next 6 weeks

FE: Why not decide what we are going to do with Amelia's stuff...

… and I'll edit module to reflect that

CMN: We need to work examples to make rational decisions.

ABR: I'll try doing that by early next week.

DS: I'll be away for next 2 weeks.

… Or 3.

… Like the datayping from Amelia's module, isn't just accessibility issue, but helps make portable data.

… There are more cases than just screenreaders for this.

JW: Will be busy over the next few weeks and cannot commit much work...

[adjourned]

- DRAFT -

Protocols and Formats Working Group Teleconference

28 Aug 2015

Attendees

Contents

High level Overview Ameila’s Proposed Reduced Model

Legends

Summary of Action Items

Scribe.perl diagnostic output