- 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