14:56:52 RRSAgent has joined #html-a11y
14:56:52 logging to http://www.w3.org/2012/10/04-html-a11y-irc
14:56:54 RRSAgent, make logs world
14:56:54 Zakim has joined #html-a11y
14:56:56 Zakim, this will be 2119
14:56:57 Meeting: HTML Accessibility Task Force Teleconference
14:56:57 ok, trackbot; I see WAI_PFWG(HTML TF)10:00AM scheduled to start 56 minutes ago
14:56:57 Date: 04 October 2012
14:57:47 agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0003.html
14:58:19 Meeting: HTML-A11Y Task Force Teleconference
14:58:20 Chair: Janina_Sajka
14:58:21 agenda+ Sec. 7.1 Hidden http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0001.html
14:58:23 agenda+ Plan2014 (Revision 2) Discussion https://lists.w3.org/Archives/Member/w3c-wai-pf/2012JulSep/0312.html
14:58:24 agenda+ Subteam Reports: Bug Triage; AAPI Mapping; Text
14:58:26 agenda+ The Task Force at the TPAC
14:58:27 agenda+ Other Business
14:58:29 agenda+ Actions Review http://www.w3.org/WAI/PF/HTML/track/actions/open
14:58:31 agenda+ Identify Scribe for the next TF teleconference http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List
14:59:12 janina has joined #html-a11y
14:59:33 WAI_PFWG(HTML TF)10:00AM has now started
14:59:37 +??P50
14:59:41 +??P14
14:59:52 zakim, ??P50 is Michael_Cooper
14:59:52 +Michael_Cooper; got it
15:00:02 zakim, ??P14 is Janina_Sajka
15:00:02 +Janina_Sajka; got it
15:00:13 Judy has joined #html-A11y
15:00:41 +John_Foliot
15:00:45 +hober
15:00:52 zakim, what is the passcode?
15:00:57 +Judy
15:01:01 the conference code is 2119 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), rubys
15:01:02 Sam, passcode is 2119#
15:01:38 plh has joined #html-a11y
15:01:56 paulc has joined #html-a11y
15:02:05 +Plh
15:02:40 +Sam
15:02:43 zakim, who's on the phone?
15:02:47 -hober
15:03:16 On the phone I see Janina_Sajka, Michael_Cooper, John_Foliot, Judy, Plh, Sam
15:03:31 +hober
15:03:44 scribe: MichaelC
15:03:48 +[Microsoft]
15:04:06 +Cynthia_Shelly
15:04:15 zakim, [Microsoft] has paulc
15:04:15 +paulc; got it
15:04:47 +James_Craig
15:05:30 zakim, take up item 2
15:05:30 agendum 2. "Plan2014 (Revision 2) Discussion https://lists.w3.org/Archives/Member/w3c-wai-pf/2012JulSep/0312.html" taken up [from MichaelC]
15:05:56 js: there are ongoing discussions about specifics of the plan
15:06:19 here to solicit input on approach and role of this task force
15:06:52 formalities of relationship between the TF, PFWG, and HTML WG
15:07:57 q+
15:08:42 ack j
15:09:00 current plan 2014 link: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html
15:09:09 jb: for Plan2014 to work, the TF must have more clear ability to produce its deliverables
15:09:25 section on a11y tf: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#a11y-tf
15:09:50 there's been discussion on clarification to TF work statement
15:10:02 At the end of the "Scope of Work" section, add the following paragraph:
15:10:02 > The task force may also create specifications that extend deliverables of the HTML Working Group, in the area of accessibility. The Accessibility Task Force will have decision authority over the contents of such extension specifications. Any such specifications will be considered jointly produced by the HTML Working Group and PFWG, for purposes of W3C Publication. This means that, as with any w3c joint task force deliverable, both Working Groups must approve
15:10:11 jb: there is still stuff we're trying to sort out
15:10:20 current TF statement: http://www.w3.org/WAI/PF/html-task-force
15:10:41 The task force may also create specifications that extend deliverables of the HTML Working Group, in the area of accessibility.
15:10:56 The Accessibility Task Force will have decision authority over the contents of such extension specifications. Any such specifications will be considered jointly produced by the HTML Working Group and PFWG, for purposes of W3C Publication.
15:11:09 This means that, as with any w3c joint task force deliverable, both Working Groups must approve transitions such as First Public Working Draft or Last Call.
15:11:23 It also means that documents will create Patent Policy obligations in both groups.
15:11:33 Members of either Working Group who have technical comments or objections on Task Force publications are expected to raise them in the context of the Task Force
15:11:36 -- done
15:11:39 s/> The task force may also create specifications that extend deliverables of the HTML Working Group, in the area of accessibility. The Accessibility Task Force will have decision authority over the contents of such extension specifications. Any such specifications will be considered jointly produced by the HTML Working Group and PFWG, for purposes of W3C Publication. This means that, as...
15:11:40 ...with any w3c joint task force deliverable, both Working Groups must approve //
15:11:56 richardschwerdtfe has joined #html-a11y
15:12:13 +Rich
15:12:29 jb: accounts for things that can become standalone specs or reintegrated into HTML
15:12:46 who produces
15:12:52 implications for Patent Policy
15:13:29 right now it's clear that PFWG sign-off is needed, but whether under PFWG Patent Policy is open question
15:13:33 Stevef has joined #html-a11y
15:13:51 expectation that objections from either group would be taken to the task force to be worked out there
15:13:54 -hober
15:14:05 +[Apple]
15:14:07 Zakim, Apple is me
15:14:07 +hober; got it
15:14:11 so we'd like input on approval sign-off, patent policy, and anything else
15:14:32 +David_MacDonald
15:15:11 js: so we're talking about joint publication between PFWG and HTML WG
15:15:28 accessibility issues with HTML would start as extensions
15:15:33 worked on in this task force
15:16:00 David has joined #html-a11y
15:16:03 normal W3C Recommendation development lifecycle applies
15:16:04 +??P29
15:16:20 opportunity to integrate into HTML at particular milestones
15:16:43 zakim, ??p29 is me
15:16:43 +Stevef; got it
15:16:54 need to work out when WGs might legitimately oppose publication
15:17:01 jcraig has joined #html-a11y
15:17:24 vs when the answer would be that the concerns need to [be|have been] worked out in TF
15:17:43 Zakim, who is on the call?
15:17:43 On the phone I see Janina_Sajka, Michael_Cooper, John_Foliot, Judy, Plh, Sam, [Microsoft], Cynthia_Shelly, James_Craig, Rich, hober, David_MacDonald, Stevef
15:17:44 q+
15:17:46 [Microsoft] has paulc
15:17:54 not giving carte blanche to TF, but need a basis for deciding
15:17:57 ack p
15:18:00 q?
15:18:50 pc: my experience with XQuery and XSL WGs was that the concerns became moot if there was active representation from both sides
15:19:10 q?
15:19:27 so one way to mitigate concerns is make sure TF is able to accommodate participation from both WGs
15:19:33 q?
15:19:35 js: yes, we want to work on that
15:19:47 q+
15:20:02 ack j
15:20:19 jb: other questions on proposal?
15:20:29 q+
15:20:44 cs: sounds like a good step in the right direction
15:20:44 +1 to cyns
15:20:48 ack d
15:21:12 dmd: no plan to remove anything from HTML, except perhaps the alt text advice?
15:21:42 js: that's current plan
15:22:05 q+
15:22:06 any overall concerns?
15:22:15 ack s
15:22:50 sf: note the alt guidance is normative
15:23:02 js: right - I meant "non-lexical" earlier
15:23:07
15:23:42 expect proposed language to come out by email soon
15:24:02 sr: will run by HTML WG as well, then post by email
15:24:22 zakim, next item
15:24:22 agendum 1. "Sec. 7.1 Hidden http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0001.html" taken up [from MichaelC]
15:24:43 Q+
15:25:10 js: email exchange between RS and TOC
15:25:28 rs: discussed with ARIA team Monday, have a couple tweaks to meet concerns
15:25:36 toc: will review
15:25:51 rs:
15:26:03 sounds like @hidden not treated as in navigation
15:26:12 cs: will test IE10
15:26:19 rs: test file attached to message on list
15:26:27 sf: found not implemented in IE10
15:26:58 Rich's email: http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0011.html
15:27:24 ack j
15:27:44 jf: proposal is that elements are hidden from presentation but still active
15:27:50 yet not focusable
15:28:00 concerned about that
15:28:23 how does someone interact with form if they can't focus on element
15:28:25 rs: they can't
15:28:34 jf: so form is effectively disabled
15:28:38 rs: from user input, yes
15:28:47 jcraig_ has joined #html-a11y
15:28:55 jf: what about event handlers, are they disabled as well?
15:28:57 q+
15:29:01 q?
15:29:35 toc: they're technically still attached, but they can't be actuated
15:29:40 so effectively disabled
15:29:57 rs: you can't direct input to them, because they're no binding to the UI
15:30:06 though a script could still e.g., submit the form
15:30:44 q?
15:31:11 consider hidden fallback content
15:31:34 it's in keyboard navigation order and events can be routed to it
15:31:35 q?
15:31:45
15:32:00 cs: what happens if you try to set focus on it?
15:32:02 rs: not sure
15:32:08 jc: expect a runtime error
15:32:42 js:
15:33:13 jf: concern that user could get landed on hidden content
15:33:23 if that won't happen, then my concerns are allayed
15:33:35 just need to be really sure of edge cases
15:33:40 toc:
15:33:54 jf: my formal objection has been that an element with tab focus could be hidden
15:34:09 so your sentence addresses my concern
15:34:18 If you set focus on a non-focusable element, you get a js runtime error. I expect the same of non-rendered elements such as elements contained in hidden="" nodes. (With the one notable exception for canvas shadow DOM.)
15:34:19 q+
15:34:35 ack s
15:34:37 s/so your sentence addresses my concern/so that sentence addresses my concern/
15:34:46 q+ to ask what happen to focus if an element with focus is set to hidden
15:35:18 sf: @hidden is just a semantic marker that corresponds to css display:none
15:35:43 shouldn't it be treated exactly the same?
15:35:54 if you put display:block on a hidden element, it is displayed
15:36:48 q?
15:36:57 jc: have observed this as well
15:37:19 q+ to indicate the difference is with media presentations
15:37:19 ack me
15:37:20 jcraig, you wanted to indicate the difference is with media presentations
15:37:34 though note css is tied to a particular presentation, whereas @hidden is across all
15:37:42 sf: seems not implemented that way
15:38:08 want clarity
15:39:03 mc: perhaps should specify whether @hidden overrides CSS or vice versa
15:39:06 ack me
15:39:06 MichaelC, you wanted to ask what happen to focus if an element with focus is set to hidden
15:39:23 what about [hidden] { display: block !important; }
15:39:41 mc: ^
15:40:18 not sure what the answer should be, but we should address it explicitly
15:40:34 q+
15:41:02 js: sometimes in a form a default action can still happen
15:42:23 mc: could say the focus should be automatically advanced to the next element
15:42:25 jf: or previous
15:42:49 mc: or we could say the focus is on a hidden element, next time user tries to advance they get to the next focusable element
15:42:52 q?
15:42:58 ack st
15:42:59 or focus could go to page overall, though less useful
15:43:01 sf:
15:43:27 jcraig_ has joined #html-a11y
15:43:42 q?
15:44:03 it would be an authoring error
15:44:04 q?
15:44:14 mc: should still specify error recover behaviour
15:45:11 q+
15:45:20 ack j
15:45:57 jb: JamesC can you run this discussion past Maciej?
15:46:16 toc: would like to have issues raised on mailing list so entire group can discuss
15:46:36 js: would ask someone to extract issues in the minutes to a list discussion starter
15:46:40 +1 to mailing list discussion; just don't want the detail to get lost, after this discussion
15:46:47 q?
15:47:28 q?
15:47:34 rs:
15:47:42 jf: question is of focusability
15:47:54 need to be sure focus [on @hidden elements] will never happen, period
15:47:59 q?
15:47:59 rs: need to test that out
15:48:07 jf: need to be clear about expected outcome first
15:48:36 q?
15:48:52 rs: have tested the current proposal on a number of browsers, though still need to exercise script tests
15:49:10 cs: can add text that focus method will fail
15:49:28 ACTION: MichaelC to file two HTML defects on his raised issues: 1) to determine whether @hidden overrides all CSS, and 2) to determine where focus goes when a focused element becomes hidden.
15:49:29 Created ACTION-141 - File two HTML defects on his raised issues: 1) to determine whether @hidden overrides all CSS, and 2) to determine where focus goes when a focused element becomes hidden. [on Michael Cooper - due 2012-10-11].
15:49:31 js: also that @hidden overrides CSS display values
15:49:47 and decide what happens if element with focus gets set to @hidden
15:50:13 cs: the CSS stuff should also be run past the CSS WG
15:50:42 do want to specify that certain methods should fail
15:50:53 note that may be different from current implementation
15:51:01 jc: can propose wording?
15:51:03 cs: yes
15:51:21 rs:
15:51:34 toc: this doesn't change the overall normative content so it's ok
15:53:31 action: cynthia to file HTML bug about methods that should fail when an element has @hidden set
15:53:31 Created ACTION-142 - File HTML bug about methods that should fail when an element has @hidden set [on Cynthia Shelly - due 2012-10-11].
15:54:01 rs: objection to current text? (knowing it needs expansion)
15:54:26 toc: will get to that from my inbox
15:54:41 jf: sounds good, just need expansions from today's discussion
15:55:02 closing these loops will allow me to withdraw my Formal Objection
15:56:25 js: sounds like we'll be able to wrap this topic up soon
15:56:32 -James_Craig
15:56:33 -Rich
15:56:33 -Michael_Cooper
15:56:34 -Janina_Sajka
15:56:35 -David_MacDonald
15:56:36 -John_Foliot
15:56:36 -hober
15:56:37 -Stevef
15:56:38