Minutes, SVG Accessibility Task Force, 4 September 2015

Apologies for the rather sparse minutes this week.  Fred & I were trying to
switch back and forth, minuting when the other one talked, but that
somewhat fell apart when we were talking to each other.

HTML formatted minutes are here:
http://www.w3.org/2015/09/04-svg-a11y-minutes.html

Text copy-pasted below


           Protocols and Formats Working Group Teleconference

04 Sep 2015

   See also: [2]IRC log

      [2] http://www.w3.org/2015/09/04-svg-a11y-irc

Attendees

   Present
          fesch, Amelia

   Regrets
   Chair
          Fred

   Scribe
          AmeliaBR

Contents

     * [3]Topics
         1. [4]Roles & Properties Taxonomy (Amelia's Proposal)
     * [5]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 04 September 2015

   <richardschwerdtfeger> Meeting: SVG Accessibility Task Force

   <scribe> scribe: AmeliaBR

Roles & Properties Taxonomy (Amelia's Proposal)

   Fred: I think there have been some changes, do you want to
   describe them?

   <fesch> abr: main differences from earlier (week and half ago)
   is attributes, roles haven't changed much, will try and post an
   updated summary before next weeks call

   <fesch> abr: differences from how Fred has marked up, focus on
   making it machine readable.

   <fesch> abr: one conflict was different use of valuemin and
   valuemax

   <fesch> abr: some of the structural guides, Fred had distinct
   roles for guides

   Fred: Jason sent a note to the list, suggesting we focus on
   what can a sighted person perceive from a chart.

   Jason: My point was that the AT user should be able to access a
   similar level of information and precision as a sighted viewer
   would get.

   Fred: Did you think my reply was reasonable?

   Jason: I think it will depend a lot on the graphic and how much
   information the author has included. Sometimes the data is
   unreasonable to include, but the sighted user would still get
   overall, imprecise sense of the data.
   ... values and ranges and other things you would want to know
   about, that can be approximated by visual inspection, even if
   exact data isn't included.

   Fred: That sounds more like observations that statistical
   min/max/mean etc.

   Jason: Observations, yes, but we need to think of how to
   provide that in a systematic way.

   <fesch> abr: good point, approach I have done so far has been
   annotating charts with raw data

   <fesch> abr: one thing someone brought up last week, was a
   certain value was encoded on the chart - like x,y position

   <fesch> abr: - not my ideal, but reverse engineering data may
   be a possible approach, to avoid doubling the size

   <fesch> fe: becomes problematic when you have non linear
   scales, and polar transformations...

   <fesch> abr: something to think about... I prefer to keep data
   and representation separately

   Jason: I think that's reasonable, but I also think that it's
   important in those data-heavy cases for authors to include
   summary data

   Fred: That's one reason I was using the ARIA min and max
   properties all over the place. But that wouldn't do other
   statistics like medians or trends.

   Jason: Yes, there must be reasonable limits. But we also need
   to be sure that if the full data isn't included in accessible
   format, then appropriate summary is.
   ... For example, I brought up sonification, and you really need
   to know the data to know what frequencies should be used.

   Fred: The other question I had was for when data is represented
   by aesthetics, such as color or size. Could you have multiple
   palettes, and just swap one in or the other. Maybe even audio
   palettes of tones.

   Amelia: Author-supplied alternative palettes, or AT-generated?

   Fred: Maybe author, but probably AT.

   Amelia: That's pretty much what I'd suggested last week, but
   I'd suggested you'd need the raw data & then use it to create a
   new mapping. Are you suggesting an AT could map from one color
   palette to another without needing the data?

   Fred: To a degree, although it would be difficult for
   continuous color. It would be easier with a discrete set of
   values.
   ... Even just to provide pop-up labels or tooltips.
   ... In RAVE?, we had a checkbox option to give labels as an
   enhancement to color.

   Amelia: But that's slightly easier, because that's in the same
   charting software. It's more complicated when the AT doesn't
   have the raw data, only the file.

   Jason: As a reminder, we do have WCAG rule that color should
   never be the only distinguishing factor.

   <fesch>
   [6]https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug
   /0022.html

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

   Fred: We want to get a clear list of roles in the module as
   soon as possible.

   Amelia: The main change from that summary are that we agreed no
   special rules for special chart types.

   <fesch> abr: talked about doc role - letting AT know that you
   are getting into a area with semantic meaning

   <fesch> abr: figure is different

   <fesch> abr: figure role defines how it relates to the larger
   document

   <fesch> abr: graphics- doc would be the default element for SVG

   [long discussion on focus vs point of regard, figure vs
   graphics-doc: when would we use both, how would they be
   navigated.]

   Fred: Did we, or should we, resolve on the graphics-doc role?

   Jason: I'm not sure it's helpful to decide on roles one at a
   time. I think we need to assess a taxonomy as a whole.

   <fesch> abr: will try to see if graphics-doc children have
   different properties

   [follow up of Fred's email re aria-owns, Amelia suggests maybe
   an aria-labelledby relationship would have been more
   appropriate]

   trackbot, end telcon