SVG Accessibility Task Force -- 11 Sep 2015

<scribe> scribenick: LJWatson

Taxonomy

<fesch> https://www.w3.org/wiki/SVG_Accessibility/ARIA_roles_for_charts

FE: Suggest we look at Amelia's taxonomy.

SVG Accessibility/ARIA roles for charts

CMN: We should get agreement on what we can.

FE: How do we do that without looking at the taxonomy?

CMN: Compare the taxonomies and finding common features.

ABR: We seem to agree on roles for data, and roles for annotations and guides.
... Disagreement is on how we sub-divide those classifications.
... Fred is leaning towards author descriptions.
... We need to decide how much information is machine readable, because that decides what roles and attributes are required.

FE: Not sure that's true.
... Lets go through your taxonomy and see what we agree on, then we'll know where the differences are.

ABR: We agree on graphicsdoc.
... There are three subclasses - maps, networkgraphs and datacharts.
... Next is graphicsobject which we've accepted as useful for structured grapphics.
... graphicssymbol, which we've also accepted.
... Further broken down into two groups, datatype roles and annotation/guide roles.
... Agreement on need for a datagroup role, for organising data elements.

FE: There should be a role for a single data item. Also one for connectors.
... Also agree we need guides/annotations.
... Also something with scale in the name, and a child of that should be axis.
... Plus some kind of tick. Most of these are name conventions.

CMN: General concern... Data may or may not be graphical. Much of what's in the taxonomy should map neatly to tabular data.
... Connector is an exception.
... We should compare the taxonomy to ARIA properties, so we don't repeat things we already have.

ABR: Can you explain how there might be repetition?

CMN: Data unit is similar to gridcell. The critical thing about a data point in a graph is that it's data, not that it's graphical.
... We need to find the right balance for this vocabulary between too large and too small.

FE: Agree, but we are creating a graphics taxonomy.
... Would hate to use cell for a data point role.

CMN: Seems odd that a graphical data point has a whole different set of properties when rendered as a table.
... The medium isn't what we're trying to communicate.

ABR: That sounds sensible. The problem is that we're working with ARIA roles that don't use that approach.
... Existing roles are for trees, grids, trees etc.
... Tables aren't marked up as groups of items, they're just rows and the AT is supposed to make the connections back to the columns.
... There is no concept of data long a continuous spectrum for example.
... It's also dependent on the DOM structure.

CMN: Not quite true. A table is the same as nested lists in terms of DOM structure. So you can say this nested list represents a row of the table.

FE: Part of making a chart taxonomy is so an AT user can talk about the chart, articulating things using the same language.

CMN: Yes, but they are still just data points. If you have a table, people talk about an item of data within that table.
... For things that are not just asthetic, the important thing is that it's a piece of data.

FE: With graphics that breaks down quickly.
... With a line chart, it's a whole column of stuff broken down by category. It represents points not rows.
... All categories equate to a single column, if thinking in tabular terms.

CMN: A sin graph or a graph of an exponential?
... A bunch of points connected by a line?

FE: Yes.

CMN: That's a bar chart. The jumps up/down are visually presented differently, but the basic data is the same.

ABR: No, bar charts have different implied meanings.

FE: A line chart, for example stock closing price, you can have many stocks. You can't do that with a bar chart.

CMN; With colour contrast correct, you can.

scribe: They're essentially the same thing, you don't have to colour in the bars if you don't want to.

FE: But you wouldn't be able to see everything.

ABR: The relevant distinction is that with ARIA you'll have one DOM element that represents a whole lot of data. You can't use table roles to represent that.

CMN: That's important... one DOM element representing an entire set of cells.

JW: Usually we'd have a general ARIA role, which inherited properties that say something about it.
... We agreed last time that we want to author to specify what kind of data is being represented.

FE: Problem is that there isn't a nice role that we can use for all kinds of charts.
... We have the freedom to make a taxonomy, so we should.

CMN: "Since we can" doesn't necessarily nean we should.
... We should upstream other data stuff.
... We need a way to represent a set of data points, and an individual data point itself.
... Concepts like data points and data sets will have use outside of graphical representations.

LW: We should look to add these roles to the main ARIA spec because they have uses outside of graphics.

ABR: So we look at which features could be abstracted up a level?
... So we call them data arrays instead of data lines for example.
... We could use a different namespace - like dataunits instead of graphical.
... These roles and attributes could then be used in other situations, like with tabular data.

RS: If we want to get it in ARIA 1.1, time is tight.

ABR: Don't expect this to be 1.1.
... Suggest we do this within the graphics module, but indicate which roles/attributes are intended to go into the main spec.
... We could alternatively split into two documents.

JW: This is definitely 2.0 material.

CMN: The catch... We'd like to get some of this stuff before SVG 2.0.

ABR: Earlier we focused on diagrams and other structured graphics, we discussed Graphics 2.0 with the other bits in.
... We could go back to the simpler approach.
... graphicsdoc, graphicsobject and graphicssymbol.

FE: Would be nice to have data in there too.
... For data item and data group.

RS: What about axis?

ABR: Then we go into chart annotations. You don't want to do that piecemeal.
... Could use title/desc to provide information in the meantime.

FE: That doesn't work for different axes.

ABR: No, but labelling would work.
... Not suggesting this is ideal, but it's one way to get something into 1.1.

JW: There's no reason to keep to an SVG 2.0 timeframe. So defer major chart taxonomy to ARIA 2.0, and use the SVG 2.0 timeline to define those things that will be in the acc API mappings.
... We're not held to decisions we might regret later.

FE: What is the SVG timeframe?

RS: CR by Q1 2016.

FE: Don't see we can't do everything in that timeframe.

RS: Worried about a taxonomy that only hhas two/three roles.

CMN: If they're the right roles... it makes it easier to get implementors to act upon.

FE: You can't get there with just those three roles.
... You can't differentiate between features for one thing.

ABR: Getting these core roles for structured drawings is an important advancement.
... That's all that will be normative in the SVG spec. None of the chart specific roles will be used by default.
... Would definitely push for getting these three roles done and implemented in the acc APIs etc.

RS: Admit getting the name computation work is not going to be a small undertaking.

ABR: No, we need to be pushing on that.

FE: If things have the one role how will the acc name computation work?

RS: Think people will question why things like axis are missing.

ABR: Don't oversell it. This is a starting point for the graphics module.

FE: There would be no point in implementing it though.

RS: Could we do this in parallel?

ABR: Yes. We shouldn't throw out what we're working on, but the short doc will be done sooner.

RS: For SVG 2.0 we need to get the basic plumbing in place.
... If we work on the rest in parallel it will let us make progress with the browsers.

ABR: If we can get browsers to recognise title/desc properly, that would be huge.

FE: Agreed.
... That's more than three roles.

ABR: Yes, only three roles, but additional acc API mapping information.

+1 to starting with the three roles first.

JW: Concern if we want to generalise roles for inclusion in ARIA 2.0, we have to keep this in mind as we work on things.
... Better to do this once, and in the right context.

ABR: We could do the basic SVG graphics, then a second module that also includes data roles/props and data visualisation roles/props.
... We would need to check with others to make sure they're ok with the SVG TF stretching beyond it's original remit.

JW: Agree we should keep matters separate.

RS: There is also the dPub module to consider. Also work on an API for device independent interaction.
... So sometime in the ARIA 2.0 timeframe it would be good to have the second edition of the graphics module.
... We have to handle keyboard support, interaction support, title/desc etc.

FE: How many docs is that? Mapping spec/ Module itself/ Others?

RS: We have SVG Acc Mapping spec (including all the ARIA 1.1 stuff), Core Acc Mapping Guide (ARIA 1.1 only), name computation (ARIA 1.1), plus small module and mapping, and the SVG spec itself.
... Do we want to include these roles in the SVG mapping guide, or have a separte doc?

ABR: They're referenced as notes.

RS: Let's agree to get the basic three role doc out, and also into the mapping spec.

JW: Then continue on the data/chart bits in parallel.

FE: What about the SVG accessibility guide?

RS: It would require an update. Not currently referenced in the SVG 2.0 doc because it's too out of date.

CMN: Would like some authoring guidance in the appendix.

RS: Who will be at TPAC?

CMN: Yes, but flat out busy.

JW: Possibly.

RS: Hoping the ARIA WG will exist by TPAC.
... Want to set aside time early in the week.

LW: Web Platforms WG is planning to meet Mon/Tue.
... That'll be my priority, but will try to get to the discussions about High Level User Events with Cynthia + ARIA.

<richardschwerdtfeger> chair: Fred

<AmeliaBR> https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html#mapping_role_table

- DRAFT -

SVG Accessibility Task Force

11 Sep 2015

Attendees

Contents

Taxonomy

Summary of Action Items

Scribe.perl diagnostic output