Implementation Guide Coordination Call
18 Oct 2013

<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: http://www.w3.org/WAI/PF/aria-implementation/

<MarkS> 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> HTML to Platform Accessibility APIs Implementation Guide

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> https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html see 4th section.

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