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
15:17:50 <shepazu> RRSAgent, make public minutes
15:17:50 <RRSAgent> I'm logging. I don't understand 'make public minutes', shepazu.  Try /msg RRSAgent help
15:18:03 <AmeliaBR> rrsagent, make logs public
15:18:18 <shepazu> sigh
15:18:23 <AmeliaBR> Thanks shepazu.  Found the docs: http://www.w3.org/2002/03/RRSAgent
15:18:30 <shepazu> I hate our bots :(
15:18:40 <AmeliaBR> Aren't robots helpful?  Don't they make your life easier?
15:19:01 <shepazu> DESTROY ALL ROBOTS!
16:30:56 <LJWatson> LJWatson has left #svg-a11y
16:45:31 <richardschwerdtfeger> richardschwerdtfeger has joined #svg-a11y
17:19:01 <chaals> chaals has joined #svg-a11y
17:20:17 <richardschwerdtfeger> richardschwerdtfeger has joined #svg-a11y
18:41:33 <richardschwerdtfeger> richardschwerdtfeger has joined #svg-a11y
19:21:52 <richardschwerdtfeger> richardschwerdtfeger has joined #svg-a11y