- From: Mark Sadecki <mark@w3.org>
- Date: Fri, 18 Oct 2013 15:33:33 -0400
- To: W3C WAI Protocols & Formats <public-pfwg@w3.org>
- CC: Richard Schwerdtfeger <schwer@us.ibm.com>, clown.idi@gmail.com, cyns@exchange.microsoft.com, dmazzoni@chromium.org, jason@accessibleculture.org, jcraig@apple.com, mark@w3.org, "Michael[tm] Smith" <mike@w3.org>, shane@aptest.com, surkov.alexander@gmail.com, Tamii Stephens <tamiis@us.ibm.com>
Here are the minutes from the special coordination call for AAPI Implementation Guides held on October 18, 2013. Thanks to all those who attended. Minutes are available in HTML or Plain text below. Please let me know if you are missing from the list of those present. Since we weren't dialed into Zakim, there was no automated attendance. HTML: http://www.w3.org/2013/10/18-pf-minutes.html Text: [1]W3C [1] http://www.w3.org/ Implementation Guide Coordination Call 18 Oct 2013 See also: [2]IRC log [2] http://www.w3.org/2013/10/18-pf-irc Attendees Present Joseph Scheuhammer, Janina, Jason Kiss, Mark Sadecki, Richard Schwerdtfeger, Cynthia Shelley, Shane McCarron, Steve Faulkner Regrets Chair Rich Scribe cyns, MarkS Contents * [3]Topics * [4]Summary of Action Items __________________________________________________________ <janina> Hi, I seem to have put the wrong access code in the invitation! <trackbot> Date: 18 October 2013 <trackbot> Meeting: Protocols and Formats Working Group Teleconference <trackbot> Date: 18 October 2013 <clown> scribenick: cyns <richardschwerdtfeger> meeting: make log public RS: topic of the meeting is implementation guide coordination <richardschwerdtfeger> meeting: Implementation Guide Coordination Call RS: plan is this, but we can adjust ... there are things we need to coordinate around the various implementation guides ... aria and html5 have good work, need to adress aria in svg, is there anything we need to do with CSS? <MarkS> CS: We need to figure out how to coordinate with UAAG <MarkS> JS: about to go last call with 2.0 (UAAG). Should start engaging them for next version <MarkS> CS: need to start coordinating JS: how do we want to coordinate? we're not on the same meetings ... suggestion: in some cases we say the same thing in the different guides, can we build some boilerplate that shared between the multiple docs, using a database/include approach clown: It would be nice to have a list of all the documents? <richardschwerdtfeger> UAIG, UAAG, <richardschwerdtfeger> and HTML5 Accessibility Implementation Guide <clown> UAIG: [5]http://www.w3.org/WAI/PF/aria-implementation/ [5] http://www.w3.org/WAI/PF/aria-implementation/ <MarkS> [6]http://www.w3.org/TR/html-aapi/ [6] http://www.w3.org/TR/html-aapi/ JS: UIAG, html accessiblity implementaiton guide, using wai-aria in HTML, section in HTML 5 spec about mapping html elements to aria roles <MarkS> [7]HTML to Platform Accessibility APIs Implementation Guide [7] http://www.w3.org/TR/html-aapi/ JS: Shadi's group is doing some things about authoring guidance, should coordinate too RS: do we want to map mobile APIs CS: is ios api different than osx api? RS: much lighter weight, no table headers for example. ... android is different too ... don't have a role or type in ios CS: so how does ios work? clown: it's tied to safari <richardschwerdtfeger> can you hear me? cs: but it work on apps too <richardschwerdtfeger> can you hear me? SF: I thought ios and osx api was similar. <janina> Rich, we don't hear you <richardschwerdtfeger> I am calling back in SF: thought main differnce was that safari wasn't as far ahead in ios <MarkS> RS: Chromium is moving away from plugin and going with an AAPI over the next year JS: question for James Craig: is the api on ios the same as the one on osx? <clown> [8]https://developer.apple.com/library/ios/documentation/UserEx perience/Conceptual/iPhoneAccessibility/Accessibility_on_iPhone /Accessibility_on_iPhone.html see 4th section. [8] https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html RS: good we're on the 5.1 timeframe, because there is a lot left out of mobile browsers today ... do we see separate docs for aria, html5? those could be the same. ... separate sections for SVG, etc in one big doc? <MarkS> CS: I think putting ARIA and HTML5 in the same doc is fine, but they are on a different timeline. <MarkS> …There is a lot of overlap there, but I don't want to tie ARIA 2.0 to the HTML5 timeline <MarkS> …SVG really seems very separate to me. I don't see a reason to put those two together. <MarkS> RS: Would be good to refer to sections of the document RE: and events section <MarkS> CS: Think modularizing is a good idea. SM: aria core, aria+html5, aria+svg etc. RS: html5 bigest issue is html native host semantics ... checkbox with aria-checked=mixed, for example ... do we want to change aria spec to no longer require role? SF: should be defined in aria spec so that doesn't have to happen. current browser impl is all over the place. there's no reason to require an aria role when you already have a native role ... it's already being mapped to tha api RS: if we were doing modularization, we'd say " for these elements in html5 you don't need an aria role because..., and the aria spec would say you don't need it too" ... is it possible to have a generic doc covering host language semantics and eventing ... can we have one general document that talks about mapping, and then specific things for html5 and for aria. refer to generic doc for a host a language CS: is this just for host language, or would there be other stuff too? <clown> Quote from the UAIG: "Processing document changes is important regardless of WAI-ARIA." RS: events, focus SM: core specification would have things that are universal across any mapping. and then separate things that are specific to one technology RS: what do you think about a core mapping for core features like focus changes, showing and hiding content, etc. across apis ... and then satelite docs that cover html, svg, aria, css and other things ... for example, what are the events that need to be generated for a menu, whther that menu is implemented with html or aria ... maybe somehting specific to graphics, with graphics ontology, for SVG and canvas. the semantics would applicalble across the technologies CS: applicable to other drawing techs too... visio, pdf, illustrator, etc. RS: question about CSS. where does that belong CS: I don't think we know yet. I think we need to take on a project to answer that question RS: would a core spec be UAAG? CS: last time i looked it was much more UI focused and less api focused RS: when we try to specify UI, browser mfgr say no JS: we don't want to take over UAAG space CS: should UAAG own core API spec? <MarkS> CS: Do we want to ask the UAAG WG to take the lead, do we want to offer our resources to help? <MarkS> SF: We shouldn't be worried about where the documents will live, but getting the documents written. CS: is there overlap? we need to figure that out RS: do we agree on modularization? (no objections) RS: ACTION rich: talk to mobile manufacturers about how to include their apis SM: also include core-mob, mobile interest group <MarkS> ACTION: Rich to talk to mobile manufacturers about how to include their apis [recorded in [9]http://www.w3.org/2013/10/18-pf-minutes.html#action01] <trackbot> Created ACTION-1279 - Talk to mobile manufacturers about how to include their apis [on Richard Schwerdtfeger - due 2013-10-25]. RS: look at existing spec, what would make sense to pull into core spec? JS: yes, we should work on that ACTI <scribe> ACTION: rich to take a first pass at pulling aria core implementation out of aria UIAG [recorded in [10]http://www.w3.org/2013/10/18-pf-minutes.html#action02] <trackbot> Created ACTION-1280 - Take a first pass at pulling aria core implementation out of aria uiag [on Richard Schwerdtfeger - due 2013-10-25]. RS: everyone start thinking about what areas they'd like to work on ... issue with role and host language semantics is important. SF: yes, agree ... already in spec that global state and property don't need role, there are a few role-specific ones that we'd want to change to work without a role, like checked ... there aren't that many, we should be able to resolve it RS: currently directing product teams to use section element and also put role on it for back-compat Summary of Action Items [NEW] ACTION: rich to take a first pass at pulling aria core implementation out of aria UIAG [recorded in [11]http://www.w3.org/2013/10/18-pf-minutes.html#action02] [NEW] ACTION: Rich to talk to mobile manufacturers about how to include their apis [recorded in [12]http://www.w3.org/2013/10/18-pf-minutes.html#action01] [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [13]scribe.perl version 1.138 ([14]CVS log) $Date: 2013-10-18 19:29:10 $ [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [14] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 18 October 2013 19:33:37 UTC