See also: IRC log
<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