See also: IRC log
<trackbot> Date: 04 October 2012
<scribe> Meeting: HTML-A11Y Task Force Teleconference
<janina> Sam, passcode is 2119#
<scribe> scribe: MichaelC
js: there are ongoing discussions about specifics of the plan
here to solicit input on approach and role of this task force
formalities of relationship between the TF, PFWG, and HTML WG
<rubys> current plan 2014 link: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html
jb: for Plan2014 to work, the TF must have more clear ability to produce its deliverables
<rubys> section on a11y tf: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#a11y-tf
there's been discussion on clarification to TF work statement
<rubys> At the end of the "Scope of Work" section, add the following paragraph:
<rubys> > 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
jb: there is still stuff we're trying to sort out
<rubys> current TF statement: http://www.w3.org/WAI/PF/html-task-force
<rubys> The task force may also create specifications that extend deliverables of the HTML Working Group, in the area of accessibility.
<rubys> 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.
<rubys> 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.
<rubys> It also means that documents will create Patent Policy obligations in both groups.
<rubys> 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
<rubys> -- done
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...
scribe: with any w3c joint task force deliverable, both Working Groups must approve //
jb: accounts for things that can become standalone specs or reintegrated into HTML
who produces
implications for Patent Policy
right now it's clear that PFWG sign-off is needed, but whether under PFWG Patent Policy is open question
expectation that objections from either group would be taken to the task force to be worked out there
so we'd like input on approval sign-off, patent policy, and anything else
js: so we're talking about joint publication between PFWG and HTML WG
accessibility issues with HTML would start as extensions
worked on in this task force
normal W3C Recommendation development lifecycle applies
opportunity to integrate into HTML at particular milestones
need to work out when WGs might legitimately oppose publication
vs when the answer would be that the concerns need to [be|have been] worked out in TF
not giving carte blanche to TF, but need a basis for deciding
pc: my experience with XQuery and XSL WGs was that the concerns became moot if there was active representation from both sides
so one way to mitigate concerns is make sure TF is able to accommodate participation from both WGs
js: yes, we want to work on that
jb: other questions on proposal?
cs: sounds like a good step in the right direction
<JF> +1 to cyns
dmd: no plan to remove anything from HTML, except perhaps the alt text advice?
js: that's current plan
any overall concerns?
sf: note the alt guidance is normative
js: right - I meant "non-lexical" earlier
<though scribe hadn't captured that>
expect proposed language to come out by email soon
sr: will run by HTML WG as well, then post by email
js: email exchange between RS and TOC
rs: discussed with ARIA team Monday, have a couple tweaks to meet concerns
toc: will review
rs: <technical notes in implementations>
sounds like @hidden not treated as in navigation
cs: will test IE10
rs: test file attached to message on list
sf: found not implemented in IE10
<JF> Rich's email: http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0011.html
jf: proposal is that elements are hidden from presentation but still active
yet not focusable
concerned about that
how does someone interact with form if they can't focus on element
rs: they can't
jf: so form is effectively disabled
rs: from user input, yes
jf: what about event handlers, are they disabled as well?
toc: they're technically still attached, but they can't be actuated
so effectively disabled
rs: you can't direct input to them, because they're no binding to the UI
though a script could still e.g., submit the form
consider hidden fallback content
it's in keyboard navigation order and events can be routed to it
<though you wouldn't land on it unless it's unhidden>
cs: what happens if you try to set focus on it?
rs: not sure
jc: expect a runtime error
js: <clarification, missed>
jf: concern that user could get landed on hidden content
if that won't happen, then my concerns are allayed
just need to be really sure of edge cases
toc: <missed>
jf: my formal objection has been that an element with tab focus could be hidden
so that sentence addresses my concern
<jcraig> 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.)
sf: @hidden is just a semantic marker that corresponds to css display:none
shouldn't it be treated exactly the same?
if you put display:block on a hidden element, it is displayed
jc: have observed this as well
<Zakim> jcraig, you wanted to indicate the difference is with media presentations
though note css is tied to a particular presentation, whereas @hidden is across all
sf: seems not implemented that way
want clarity
mc: perhaps should specify whether @hidden overrides CSS or vice versa
<Zakim> MichaelC, you wanted to ask what happen to focus if an element with focus is set to hidden
<jcraig> what about [hidden] { display: block !important; }
mc: ^
not sure what the answer should be, but we should address it explicitly
js: sometimes in a form a default action can still happen
mc: could say the focus should be automatically advanced to the next element
jf: or previous
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
or focus could go to page overall, though less useful
sf:
it would be an authoring error
mc: should still specify error recover behaviour
jb: JamesC can you run this discussion past Maciej?
toc: would like to have issues raised on mailing list so entire group can discuss
js: would ask someone to extract issues in the minutes to a list discussion starter
<Judy> +1 to mailing list discussion; just don't want the detail to get lost, after this discussion
rs: <missed>
jf: question is of focusability
need to be sure focus [on @hidden elements] will never happen, period
rs: need to test that out
jf: need to be clear about expected outcome first
rs: have tested the current proposal on a number of browsers, though still need to exercise script tests
cs: can add text that focus method will fail
<jcraig> 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. [recorded in http://www.w3.org/2012/10/04-html-a11y-minutes.html#action01]
<trackbot> 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].
js: also that @hidden overrides CSS display values
and decide what happens if element with focus gets set to @hidden
cs: the CSS stuff should also be run past the CSS WG
do want to specify that certain methods should fail
note that may be different from current implementation
jc: can propose wording?
cs: yes
rs: <missed>
toc: this doesn't change the overall normative content so it's ok
<scribe> ACTION: cynthia to file HTML bug about methods that should fail when an element has @hidden set [recorded in http://www.w3.org/2012/10/04-html-a11y-minutes.html#action02]
<trackbot> Created ACTION-142 - File HTML bug about methods that should fail when an element has @hidden set [on Cynthia Shelly - due 2012-10-11].
rs: objection to current text? (knowing it needs expansion)
toc: will get to that from my inbox
jf: sounds good, just need expansions from today's discussion
closing these loops will allow me to withdraw my Formal Objection
js: sounds like we'll be able to wrap this topic up soon
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) WARNING: Bad s/// command: 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... Succeeded: s/so your sentence addresses my concern/so that sentence addresses my concern/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** WARNING: Bad s/// command: 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... Found Scribe: MichaelC Inferring ScribeNick: MichaelC Default Present: Michael_Cooper, Janina_Sajka, John_Foliot, hober, Judy, Plh, Sam, Cynthia_Shelly, paulc, James_Craig, Rich, David_MacDonald, Stevef Present: Michael_Cooper Janina_Sajka John_Foliot hober Judy Plh Sam Cynthia_Shelly paulc James_Craig Rich David_MacDonald Stevef Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0003.html Found Date: 04 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/04-html-a11y-minutes.html People with action items: cynthia michaelc WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]