minutes from today

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

in text edited for readability below:

28 Aug 2015

    See also: [2]IRC log

       [2] http://www.w3.org/2015/08/28-svg-a11y-irc

Attendees

    Present
           Rich, chaals, AmeliaBR, Jason, Doug

    Regrets
           Léonie

    Chair
           Fred

    Scribe
           chaals, fesch

Contents

      * [3]Topics
          1. [4]High level Overview Ameila’s Proposed Reduced Model
          2. [5]Legends
      * [6]Summary of Action Items
      __________________________________________________________


High level Overview Ameila’s Proposed Reduced Model

    <AmeliaBR> [7]Amelia's email outlining an aria model

       [7]  
https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug/0022.html

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

       [8]  
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.

    … 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

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

    <richardschwerdtfeger> ACTION: Doug Define changes to <title>
    that specifies how to deal with child content

    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.

    <scribe> ACTION: chaals to talk to Gion Kunz (chartist.js
    maintainer) and ask him about what roles/properties would make
    sense …

    <trackbot> Created ACTION-1713

    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.

    CMN: [+1 to fesch on worked examples]

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

    <AmeliaBR> [16]Fred's experiments - see number 2

      [16] https://www.w3.org/wiki/SVG_Accessibility#Experiments_in_markup

    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]

Summary of Action Items

    [NEW] ACTION: chaals to talk to Gion Kunz (chartist.js
    maintainer) and ask him about what roles/properties would make
    sense …
    [NEW] ACTION: Doug Define changes to <title> that specifies how
    to deal with child content



-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Friday, 28 August 2015 15:39:19 UTC