HTML Accessibility Task Force Teleconference -- 04 Oct 2012

<trackbot> Date: 04 October 2012

<scribe> Meeting: HTML-A11Y Task Force Teleconference

<janina> Sam, passcode is 2119#

<scribe> scribe: MichaelC

Plan2014 (Revision 2) Discussion https://lists.w3.org/Archives/Member/w3c-wai-pf/2012JulSep/0312.html

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

expect proposed language to come out by email soon

sr: will run by HTML WG as well, then post by email

Sec. 7.1 Hidden http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0001.html

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

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

HTML Accessibility Task Force Teleconference

04 Oct 2012

Attendees

Contents

Plan2014 (Revision 2) Discussion https://lists.w3.org/Archives/Member/w3c-wai-pf/2012JulSep/0312.html

Sec. 7.1 Hidden http://lists.w3.org/Archives/Public/public-html-a11y/2012Oct/0001.html

Summary of Action Items

Scribe.perl diagnostic output