W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2015

Minutes: SVG Accessibility Task Force

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 23 Jan 2015 09:18:57 -0600
To: "SVG WG" <public-svg-wg@w3.org>
Message-ID: <OF295E061A.B447E219-ON86257DD6.0053E52D-86257DD6.005421C4@us.ibm.com>


Web:
http://www.w3.org/2015/01/23-svg-a11y-minutes.html

Text:

IRC log of svg-a11y on 2015-01-23


Timestamps are in UTC.


13:50:25 [RRSAgent]
      RRSAgent has joined #svg-a11y
13:50:25 [RRSAgent]
      logging to http://www.w3.org/2015/01/23-svg-a11y-irc
13:50:27 [trackbot]
      RRSAgent, make logs member
13:50:27 [Zakim]
      Zakim has joined #svg-a11y
13:50:29 [trackbot]
      Zakim, this will be WAI_PF
13:50:29 [Zakim]
      I do not see a conference matching that name scheduled within the
      next hour, trackbot
13:50:30 [trackbot]
      Meeting: Protocols and Formats Working Group Teleconference
13:50:30 [trackbot]
      Date: 23 January 2015
13:50:35 [richardschwerdtfeger]
      chair: Rich
13:50:45 [richardschwerdtfeger]
      meeting: W3C WAI-PF ARIA Caucus
13:59:34 [fesch]
      fesch has joined #svg-a11y
13:59:39 [richardschwerdtfeger]
      meeting: W3C SVG Accessibility Task Force
14:02:31 [AmeliaBR]
      AmeliaBR has joined #svg-a11y
14:02:52 [cpandhi]
      cpandhi has joined #svg-a11y
14:04:40 [LJWatson]
      LJWatson has joined #svg-a11y
14:04:56 [LJWatson]
      zakim, who is on the phone?
14:04:56 [Zakim]
      sorry, LJWatson, I don't know what conference this is
14:04:58 [Zakim]
      On IRC I see LJWatson, cpandhi, AmeliaBR, fesch, Zakim, RRSAgent,
      richardschwerdtfeger, shepazutu, trackbot
14:05:06 [LJWatson]
      zakim, this is 2742
14:05:06 [Zakim]
      ok, LJWatson; that matches WAI_SVGTF()9:00AM
14:05:15 [Zakim]
      + +1.941.266.aaaa
14:05:15 [LJWatson]
      zakim, who is on the phone?
14:05:15 [Zakim]
      On the phone I see Fred_Esch, Doug_Schepers, Rich_Schwerdtfeger,
      Charu_Pandhi, ??P24, [IPcaller], Jason_White, +1.941.266.aaaa
14:05:26 [LJWatson]
      zakim, [IPcaller] is me
14:05:26 [Zakim]
      +LJWatson; got it
14:05:29 [Amy]
      Amy has joined #svg-a11y
14:06:29 [LJWatson]
      zakim, agenda?
14:06:29 [Zakim]
      I see nothing on the agenda
14:06:32 [AmeliaBR]
      zakim, ??P24 is me
14:06:32 [Zakim]
      +AmeliaBR; got it
14:07:37 [Zakim]
      +[IPcaller]
14:08:55 [richardschwerdtfeger]
      richardschwerdtfeger has joined #svg-a11y
14:09:35 [ed]
      ed has joined #svg-a11y
14:09:41 [richardschwerdtfeger]
      https://lists.w3.org/Archives/Public/public-pfwg/2015Jan/0116.html
14:09:45 [AmeliaBR]
      scribenick AmeliaBR
14:10:23 [AmeliaBR]
      Topic: Why should you care about SVG + Accessibility API
14:10:56 [AmeliaBR]
      Richard: At the end of the day, your browser is a software
      application. Access. guidelines for content are not enough.
14:11:24 [AmeliaBR]
      ... What you put in to your content, it's job of the browser to
      expose that to the accessibility platform on the operating systems.
14:11:24 [Zakim]
      +[IPcaller.a]
14:11:38 [ed]
      Zakim, [IP is me
14:11:38 [Zakim]
      sorry, ed, I do not recognize a party named '[IP'
14:11:45 [shepazutu]
      Zakim, IPcaller.a is ed
14:11:45 [Zakim]
      +ed; got it
14:12:27 [AmeliaBR]
      ... with HTML, a gap was discovered for JavaScript custom widgets; no
      way for browser to know what these were, or how to tell Accessibility
      API.
14:13:30 [AmeliaBR]
      ... How it works: the accessibility tree mirrors the DOM tree. It is
      a tree so that event propogation works, and there is correct context
      for accessibility technologies (AT)
14:14:05 [AmeliaBR]
      ... e.g., options in a listbox are all members of same container.
      Container knows how many objects there are. Each item communicates
      information.
14:14:36 [AmeliaBR]
      ... Info for each item includes role infor (e.g., listbox item) and
      also state info (e.g., checked vs not checked)
14:15:12 [Zakim]
      +??P10
14:15:15 [AmeliaBR]
      ... Also includes label information. Various ways to compute this,
      either from names provided by the other or by descendent content
      (e.g. text inside a button element)
14:15:58 [Tav]
      Tav has joined #svg-a11y
14:16:19 [AmeliaBR]
      ... This info is used to create the name. You can also provide
      description for more info. One way is of course the SVG <desc>
      element. Alternatively, the aria-describedby can point to any element
      (s) you want.
14:16:41 [AmeliaBR]
      ... That element (pointed to) doesn't have to be part of the
      accessibility tree itself, could be hidden.
14:17:21 [AmeliaBR]
      ... With the Access tree and info, technologies can pull this
      information every time something changes, e.g. from user
      interactions.
14:18:25 [AmeliaBR]
      ... One thing not fully addressed in ARIA 1.0 is rich text. Still not
      sure how we're going to deal with that. E.g. contenteditable
      attribute in HTML5 -- need to know caret position, selection region.
      But also need to know paragraph breaks and so on.
14:19:20 [AmeliaBR]
      ... There are new developements, allowing ATs to really drill down
      into embedded objects. Not sure if we'll get to that on SVG.
14:19:44 [AmeliaBR]
      ... For SVG, the key is having a way to describe the basic essentials
      of drawings and charts.
14:20:03 [Zakim]
      -Rich_Schwerdtfeger
14:20:18 [chaals]
      chaals has joined #svg-a11y
14:20:23 [AmeliaBR]
      ... This has never been done before on an industrial scale. To have
      authors be able to provide this information in the main content, and
      have it be properly exposed to ATs.
14:21:17 [AmeliaBR]
      ... There are a number of features of ARIA that have turned out to be
      relevant, e.g. aria-flowto can help organize the reading order of
      content from different parts of the document. There may be others we
      haven't discovered yet.
14:21:52 [Zakim]
      +[IPcaller.a]
14:21:56 [AmeliaBR]
      ... One difficult, vs HTML, is that there isn't a natural, flowing
      order to the content where markup matches display on the screen.
14:22:05 [chaals]
      zakim, [ipcaller.a is me
14:22:05 [Zakim]
      +chaals; got it
14:22:30 [AmeliaBR]
      ... However, SVG does have grouping information, and this can
      sometimes replace special attributes.
14:22:49 [AmeliaBR]
      ... re the Accessibility API mapping guide. This was a major change
      in strategy overall.
14:23:26 [chaals]
      rrsagent, draft minutes
14:23:26 [RRSAgent]
      I have made the request to generate
      http://www.w3.org/2015/01/23-svg-a11y-minutes.html chaals
14:23:52 [richardschwerdtfeger]
      http://rawgit.com/w3c/aria/master/core-aam/core-aam.html
14:24:02 [richardschwerdtfeger]
      http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
14:24:02 [AmeliaBR]
      ... For ARIA accessibility guide, it originally did not fully
      integrate with HTML. There isn't always a clear association between
      native HTML 5 elements and platform accessibility roles. This is may
      the Core accessibility mapping guide was created.
14:24:27 [AmeliaBR]
      ... Also a separate spec for Accessible name and description
      calculation.
14:25:11 [AmeliaBR]
      The original name calculation was too specific for HTML. We needed to
      generalize, so that there are rules for HTML and other rules for SVG,
      according to the semantics of the language.
14:25:35 [AmeliaBR]
      On the Core accessibility mapping, we cover a number of features:
14:26:00 [AmeliaBR]
      richard: (still) One is keyboard focus control.
14:26:28 [AmeliaBR]
      ... SVG introduces tabIndex. It's a good start, but it won't be
      enough; it's not enough even for HTML.
14:27:07 [AmeliaBR]
      ... As a developer, you can go in and control keyboard level at a
      much more detailed level, according to what you're seeing on screen.
14:28:07 [AmeliaBR]
      ... Core Accessibility also talks about native language semantics.
      You can't override native semantics (e.g. checkbox) with ARIA. For
      SVG, this is less of an issue since there are fewer native semantics,
      although there are a few (highlighted in the mapping).
14:28:32 [AmeliaBR]
      ... Similarly, for native semantics of attributes, these need to be
      pulled out and included in the accessibility tree.
14:28:52 [shepazutu]
      q+
14:29:17 [AmeliaBR]
      ... The role mapping in the Core accessibility API describes how the
      ARIA roles are mapped to roles within the operating system's
      accessibility API
14:30:13 [AmeliaBR]
      ... One thing we can't do is tell the accessibility techs exactly how
      they should present information. This is a cottage industry, people
      don't like being told what to do. We can try to get the browsers on
      board.
14:30:48 [shepazu]
      q-
14:30:52 [AmeliaBR]
      ... We need to work with people from the various platforms to be sure
      we have a solid mapping across the board from ARIA to accessibility
      API.
14:31:22 [AmeliaBR]
      ... There are also mappings for ARIA states and properties.
14:33:07 [AmeliaBR]
      ... The final info is the list of allowed features -- descendent
      content as well as states and properties -- for each role. This
      becomes the signature of that role. This hadn't previously been
      defined in accessibility APIs, and as a result ATs had to somewhat
      reverse engineer.
14:33:32 [AmeliaBR]
      ... Different authors were using things in different ways. Now, ARIA
      validators can text whether the tree organization makes sense.
14:34:37 [AmeliaBR]
      shepazu: to confirm, this means that if you have a list box, children
      have to be list items. You couldn't have a button as a child of a
      list box?
14:34:43 [AmeliaBR]
      Richard: Exactly.
14:35:42 [AmeliaBR]
      ... One other thing we did was make sure that most relationships only
      had to be specified once. This avoids error from inconsistent
      relationships. The browsers automatically create the reverse
      relationships when the accessibility API requires it.
14:36:09 [AmeliaBR]
      ... Another thing in APIs that we dont' currently have on the web is
      Actions.
14:36:45 [AmeliaBR]
      ... The big problem with access keys and buttons and such is there is
      no way to communicate to the user what that input action will do.
14:37:07 [chaals]
      [noted the comment on accesskey, since the HTML accessibiltiy TF is
      working on that topic. Agreed that having a description of what an
      action is for would be useful]
14:37:40 [AmeliaBR]
      ... Other pieces that are really important, generic to SVG and HTML,
      is things like dynamic content. When something changes, the
      accessibility API is notified, and AT has to re-calculate their view
      of the document.
14:38:04 [AmeliaBR]
      ... E.g. the virtual buffer in JAWS, which stores the part of the doc
      being viewed.
14:38:09 [chaals]
      Present+ Chaals, DougS
14:38:34 [AmeliaBR]
      ... Because this is all in the core accessibility, we don't have to
      deal with it SVG specifically.
14:39:04 [AmeliaBR]
      ... Another issue is menu events, which are available on MS platforms
      to track progress through menus.
14:39:11 [richardschwerdtfeger]
      http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
14:39:16 [AmeliaBR]
      ... But I want to get to the SVG specific specs.
14:39:56 [AmeliaBR]
      ... Except first, the accessible name specs. This is itself
      complicated enough to take a whole call.
14:40:25 [AmeliaBR]
      ... But basically, it talks about how you find the name when you have
      different attributes or content types.
14:41:06 [richardschwerdtfeger]
      https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics
14:41:26 [AmeliaBR]
      ... We broke this into different steps based on the computation that
      is usually used. This is mostly based on HTML, but there are some
      things specific to SVG; we'll have to get Ray (editor) to make sure
      everything works with SVG, e.g. a document title inside a <defs>
14:42:02 [AmeliaBR]
      ... Now, for SVG. We have implicit roles. What is the default for
      each element.
14:42:53 [AmeliaBR]
      ... Right now, we're using group role for a lot of things. It's
      probably not the right role, but it reflects a problem across ARIA
      languages that we don't always have a specific role.
14:43:36 [AmeliaBR]
      ... So audio and video are mapping to group role, because they are
      containers for other content. Except on Linux platforms, where there
      is a specific audio/video role in the platform API.
14:43:54 [AmeliaBR]
      ... Another thing you'll notice in the mapping is that many things
      map to none. This is important.
14:44:16 [AmeliaBR]
      ... For the accessibility tree, if we create nodes for things that
      have no value, that will really slow things down.
14:44:57 [AmeliaBR]
      ... E.g. circle. *Unless* the author has specifically given labels,
      etc., by the author, it won't be included in the accessibility tree.
14:45:27 [AmeliaBR]
      ... If there is info, ideally we would map to a specific role for
      circles, but that doesn't currently exist. So for now we are also
      mapping to group role.
14:45:51 [richardschwerdtfeger]
      http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html
14:45:57 [AmeliaBR]
      ... We still have other things to adjust (e.g. ellipse had
      incorrectly not been treated like other shapes).
14:46:26 [AmeliaBR]
      On the specific mapping guide. Thanks to everyone for their detailed
      feedback. It both helps with this spec, and other docs we will create
      down the road.
14:47:35 [AmeliaBR]
      richard: ... Notice that, wherever possible, the SVG mapping spec
      just references the core accessiblity mapping spec, to avoid having
      things in two places.
14:48:03 [AmeliaBR]
      ... One thing, from erik's comments, is whether this SVG2 spec, or is
      this a generic SVG spec?
14:48:23 [Zakim]
      -chaals
14:48:24 [AmeliaBR]
      shepazu: I agree this is a generic SVG spec.
14:48:43 [AmeliaBR]
      richard: But what about when SVG 3 adds new elements?
14:49:01 [AmeliaBR]
      shepazu: Then we update the accessiblity spec.
14:49:14 [AmeliaBR]
      richard: so should we use a version number.
14:49:43 [Zakim]
      +[IPcaller.a]
14:49:45 [AmeliaBR]
      shepazu: That works. Because I agree (with Amelia's email), that this
      spec should also apply backwards to SVG 1.
14:50:05 [chaals]
      zakim, [ipcaller.a is chaals
14:50:05 [Zakim]
      +chaals; got it
14:50:08 [chaals]
      zakim, who is here?
14:50:08 [Zakim]
      On the phone I see Fred_Esch, Doug_Schepers, Charu_Pandhi, AmeliaBR,
      LJWatson, Jason_White, +1.941.266.aaaa, [IPcaller], ed, ??P10, chaals
14:50:10 [richardschwerdtfeger]
      q?
14:50:11 [Zakim]
      On IRC I see chaals, Tav, ed, richardschwerdtfeger, Amy, LJWatson,
      cpandhi, AmeliaBR, fesch, Zakim, RRSAgent, shepazu, trackbot
14:50:26 [chaals]
      ack she
14:50:32 [shepazu]
      q-
14:50:36 [AmeliaBR]
      ... We revise this spec when required. But we always have a current
      version of accessibility spec that applies to all versions of SVG.
14:51:22 [AmeliaBR]
      richard: If we're going to support all versions of SVG, will other
      things like tabindex also apply back to SVG 1.
14:52:00 [AmeliaBR]
      Amelia: One thing to remember, the SVG has basically gotten rid of
      the idea of explicit versions. Browsers will apply latest SVG rules
      to all SVG content.
14:52:29 [AmeliaBR]
      Richard: Okay. We may have to explicitly state some things from SVG
      2, such as tabindex, and how they work with other content.
14:52:44 [chaals]
      [you won't *have* svg3-only elements in SVG1 content, right?]
14:53:08 [AmeliaBR]
      Doug: For new elements, it's not a big issue. Since browsers will
      just ignore new elements they don't support.
14:54:00 [AmeliaBR]
      Richard: Does that include SVG Tiny? Cause that included new elements
      we don't yet have accessibility mappings. Should we mention that?
14:54:35 [AmeliaBR]
      Doug: I doubt there is a lot of overlap between agents that support
      SVG Tiny and ATs.
14:54:45 [AmeliaBR]
      (someone): That sounds like a big assumption...
14:54:49 [chaals]
      [That is a big call - are you sure?]
14:55:01 [chaals]
      s/(someone)/chaals/
14:55:01 [AmeliaBR]
      Doug: Ok, well we can talk off line.
14:55:28 [AmeliaBR]
      Richard: So, to go back to the mappings we have.
14:56:53 [AmeliaBR]
      ... For many elements, we have the none role. "none" is new in ARIA
      1.1.; it was formerly called presentation. It just means that it
      isn't in the accessibility API.
14:56:59 [Zakim]
      -??P10
14:58:17 [AmeliaBR]
      ... is this clear?
14:59:34 [AmeliaBR]
      AmeliaBR: I had suggested grouping similar elements, so that you
      could avoid repeated content and also provide more of a prose
      description of *why* certain roles are used.
14:59:45 [AmeliaBR]
      Richard: Is that required for FPWD?
15:00:12 [AmeliaBR]
      AmeliaBR: It might help with questions and comments
15:00:56 [AmeliaBR]
      Richard: What about keeping things as "group"? We're working on this
      in ARIA.
15:01:15 [AmeliaBR]
      AmeliaBR: Probably keep it, but add an editor's note explaining why
      it is used and that work is ongoing.
15:01:44 [AmeliaBR]
      chaals: It's generally a good idea in WD to include editor's notes
      for anything that is likely to change.
15:02:33 [AmeliaBR]
      Richard: One more thing that needs to be addressed is the recursive
      name and description computation. We need to make sure that <desc> is
      ignored when using contents to calculate a name.
15:02:42 [chaals]
      s/chaals/jason/
15:02:56 [chaals]
      Present+ Jason
15:05:42 [AmeliaBR]
      Richard: Amelia, what was your concern about <title> elements?
15:05:54 [AmeliaBR]
      Amelia: Not sure.. (discussion ensues)
15:06:39 [AmeliaBR]
      Amelia: So main thing is that <title> and <desc> have special role
      (step D) in the computation, they should be ignored for generating
      names from contents
15:07:30 [AmeliaBR]
      Richard: We're over time. I'm going to go through all the comments.
      We're still aiming for a FPWD in February.
15:08:03 [AmeliaBR]
      ... I'm going to change the title to SVG Mapping Guide form SVG2;
      I'll let Michael know.
15:08:08 [Zakim]
      -LJWatson
15:08:11 [Zakim]
      - +1.941.266.aaaa
15:08:12 [Zakim]
      -Doug_Schepers
15:08:12 [Zakim]
      -chaals
15:08:13 [Zakim]
      -Charu_Pandhi
15:08:15 [Zakim]
      -Jason_White
15:08:18 [Zakim]
      -ed
15:08:31 [cpandhi]
      cpandhi has joined #svg-a11y
15:08:42 [richardschwerdtfeger]
      RRSAgent make log public
15:08:46 [Zakim]
      -Fred_Esch
15:08:52 [richardschwerdtfeger]
      zakim, bye
15:08:52 [Zakim]
      leaving. As of this point the attendees were Fred_Esch,
      Doug_Schepers, Rich_Schwerdtfeger, Charu_Pandhi, Jason_White,
      +1.941.266.aaaa, LJWatson, AmeliaBR, [IPcaller], ed, chaals
15:08:52 [Zakim]
      Zakim has left #svg-a11y
15:08:57 [richardschwerdtfeger]
      RRSAGent, make minutes
15:08:57 [RRSAgent]
      I have made the request to generate
      http://www.w3.org/2015/01/23-svg-a11y-minutes.html
      richardschwerdtfeger
15:14:52 [AmeliaBR]
      richardschwerdtfeger: My W3 password isn't allowing me to access that
      page. Are you able to take care of last finalization and sending it
      out?
15:15:06 [AmeliaBR]
      (or shepazu or anyone else)
15:15:48 [shepazu]
      RRSAgent, make minutes public
15:15:48 [RRSAgent]
      I'm logging. I don't understand 'make minutes public', shepazu.
      Try /msg RRSAgent help

Rich Schwerdtfeger
Received on Friday, 23 January 2015 15:19:37 UTC

This archive was generated by hypermail 2.3.1 : Friday, 23 January 2015 15:19:37 UTC