See also: IRC log
<trackbot> Date: 23 February 2012
<janina> Meeting: HTML-A11Y Task Force Teleconference
<scribe> scribe: MichaelC
js: who's unavailable next week?
John, Janina, Léonie at CSUN
js: what about following week?
Janina, Michael, Cynthia at PF FtF and / or SXSW
jb: would like to schedule a fallback meeting time
js: haven't succeeded in past at finding a time
jf: hard to do meetings after start of working day Pacific
RESOLUTION: Next meeting is 15 March 2012
js: note some of us will have face to face opportunities at the upcoming locales and may have opportunity to get work done
lw: Bug triage meeting once every other week to track new bugs
most not accessibility
<LeonieW> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16018
but want input on a couple
wanted to explore whether form controls that are disabled should be focusable or not
HTML doesn't exclude disabled controls
the bug requests that they be non-focusable
cs: think most browsers remove them from tab order
lw: bug filer goes into specifics of UA behaviour
jf: if disabled should be non-focusable
mc: checking spec, apparently via a double negative spec says disabled form controls are not focusable
so bug is on what happens if you use tabindex
js: benefit to landing on controls and knowing they're disabled, otoh benefit to not being bothered with them
cs: propose correct behaviour would be not to focus disabled controls
mc: even if tabindex set?
cs: yes
mc: ok, but would change meaning of tabindex in a limited circumstance
cs: means "disabled" is a higher order bit than "tabindex"
RESOLUTION: add a11ytf keyword to 16018
lw: note bug triage sub-team is low on members
only Léonie, Michael, Hans regularly participating
-- AAPI
cs: working on the spec
table is more dynamic now so easier to use, since lots of columns
some details being added
-- Text
jb: discussed meta name=generator and denial of reopen request
thought the denial didn't address the main point
and questions were on tangential aspects
question of pursuing Formal Objection, something the text sub-team thought might be needed in next few weeks
also looked at HTML-ISSUE-204
aria-describedby vs longdesc
have requested coordination discussion
<JF> +q
also looked at location of alt guidance change proposal
is more of a TF item now
need a way to keep discussion moving, given that meetings canceled next couple weeks
and address questions already raised
finally looked at figcaption
ended up not filing a change proposal
evidence for cutoff length wasn't as strong as expected
still interested in this issue, may work in background and bring forward later
so this is no longer on the urgent path
Text sub-team also not meeting next week
jf: am in process of putting together a test suite for aria-describedby
focus on HTML-ISSUE-30 as well as HTML-ISSUE-204
note your blog entry on aria-hidden useful
<http://john.foliot.ca/aria-hidden/>
I plan to do same for aria-describedby as I did for aria-hidden
rs: why use aria-describedby in place of longdesc? it's a hack
jb: think there's not understanding of the issues behind it
rs: setting aria-hidden not necessarily hidden from AAPI
ARIA UAIG permits not hiding it
want to address via new ARIA property down the road, not misuse the current version of ARIA
jb: need to clarify some stuff
<discussion of what to clarify where>
cs, rs: have proposal to add aria-describedat in ARIA 1.1
js: but that doesn't solve the immediate situation, so we still have to address
jf: there are some contradictions that need to be clarified in ARIA
and then state that the current HTML proposal doesn't meet the use case requirements
-- Canvas
rs: all change proposals are in
one on caret and selection
resubmitted an earlier one minus text-based line and focus ring
because what's in spec now is fine
frank submitted a proposal to use bounds of object for hit testing
hasn't been reviewed
would probably need some proposed ARIA 1.1 features to support
cs: is this what we discussed last November?
rs: he submitted one that we did discuss
but also another one that uses caret and selection in script apis
that we haven't examined
there's a third change proposal that you shouldn't do rich text editing in canvas because it's too hard
not sure what to do with that as a change proposal
working on a presentation for SXSW that will demo this in three browsers
when will change proposals be reviewed?
js: it's started
rs: due to travel over next month, will be hard to respond to counter-proposals
js: hasn't come up yet, can request these things not be tossed our way too quickly
cs: asks Rich to send concerns to Frank
jb: CS can you help on that?
cs: can't get response inside Microsoft before 29th
<of March?>
would be helpful to ask chairs to put this at end of queue
<March company deadlines make hard to work on W3C stuff right now>
jb: process guidance confusing and affecting our response times
js: we don't have a whole
bifurcation of the proposals is affecting our success
understand why need to have breaking down of the problem
but we're chasing details and not meeting the whole
maybe not useful to pursue details
jf: would like to request HTML-ISSUE-203 be put on hold until outstanding issues resolved
js: chairs were happy to put processing on hold, but wanted a conditional proposal in by deadline
but I'm not convinced the conditional proposal working in our favour
cs: could we do a conditional proposal that outlines the various conditions we would support?
jf: that's a
js: decision tree
jf: all the options we're bringing forward are in limbo
don't know how to put together a change proposal
maybe CS proposal not to close issue until dependencies resolved is the way to go
cs: there was proposal to resolve using resolution to HTML-ISSUE-30
but what happens if we're not happy with resolution to that?
would be good to provide options
js: an aria-describedat solution might work here also
jf: but that doesn't exist yet
and hard to substantiate a proposal with something that doesn't yet exist
<related examples tossed around>
so we're chasing our tails
js: we're getting pushed into talking about Y when we need to talk about X
cs: we had come to agreement on a conditional proposal that seemed to satisfy everyone
we should write that, backing out might seem like bad faith
jf: but don't know how to write it sensibly
to many if-then-else in it
but will take a try
js: reminder we're past deadline, so need it by tomorrow
jf: do we let it go then?
jb: do proposal as a placeholder, we can refine later
prefer not to drop this
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/faour/favour/ Found Scribe: MichaelC Inferring ScribeNick: MichaelC Default Present: John_Foliot, Cooper, Cynthia_Shelly, Janina_Sajka, Steve_Faulkner, Judy, Léonie_Watson, Rich Present: John_Foliot Cooper Cynthia_Shelly Janina_Sajka Steve_Faulkner Judy Léonie_Watson Rich Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2012Feb/0162.html Found Date: 23 Feb 2012 Guessing minutes URL: http://www.w3.org/2012/02/23-html-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]