<Joshue> hi GJR and y'all

previous: http://www.w3.org/2008/11/21-pf-minutes.html

<scribe> scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

JOC: good time for Steve, just has conflict today
... good time for me

GJR: good time for gez, not for laura

Agenda Shaping

AG: 4 items form "agenda" for today - smart headers update, summary issue status, dialog versus dialogue, search for regular time schedule for HTML Caucus
... any additions?
... review dialog versus dialogue - test for is this interesting but not PF charter material

<Al> dialog about dialog and dialogue: http://lists.w3.org/Archives/Public/wai-xtech/2008Dec/0014.html

http://esw.w3.org/topic/PF/XTech/HTML5/Dialogue

<Joshue> +q

GJR: explains verbosely

JS: the last thing al said, resonates for me - no accessibility spin here, necessarily; see both opportunity and danger -- extent they want to debate and work on this; problem probably doens't have clean sollution; natural language is ambigious; gives example of lexicographers
... look out for: however spelled, machines don't break down; don't know if anyone going to succede getting a clear-cut clean solution

GJR: there is the conflict between the aria-dialog and DIALOG the element and it was persons outside of the accessibility sphere who brought that up as a point of confustion and potential harm

JS: accessibility reason to push for spelling change

GJR: what i picked up on was hixie's willingness to change the element name in part because there may be a need for a DIALOG or DIALOGBOX element in HTML5
... 2 things that hixie stated: one was that dialog may be needed as an element name and b) that dialog was the most appropriate name for the the element in HTML5

<Joshue> GJR: I decided to try to come down on the side of common sense. Hixie was open to changing the element name, he states that this is a case of disambiguation.

<Joshue> Janina: Two closely spelt elements is a recipe for trouble.

JS: summarize concern: 2 different kinds of element markup may be recipie for problems; especially for hand coders

JOC: that concern makes sense
... valid point JS makes; has common sense authoring situation; disambiguate CS use of dialog and natural language use of dialogue is good; semantics of HTML probably over-ride semantics of ARIA

AG: not necessarily true
... default would be explicit aria markup is stronger

JOC: does hixie know that?

AG: HTML5 could still say a datepicker widget has a strong purpose, but not amenable to casting a different role; can set aside constructs that are impervious to ARIA because script can go on everything; overriding rules have to be respected first by browsers, then by authoring tools
... post on XTech announcing a draft that RichS and Aaron commented upon; dovetailing; default is ARIA markup rules unless specific provisions in host language for overriding

JOC: use cases - higher level abstraction; think disambiguation would be useful;

AG: leading PF connection here is in ARIA caucus - this will confuse authors; going to slow acceptance by HTML5 WG by integration; what is our plan
... suppose text-to-speech pronounces them both the same

<Joshue> GJR: To make this clear would be the cite element vs the cite attribute.

AG: no technical concept; matter of perception by humans dealing with spec and definition; same symbol used in 2 diff places as role value and element value; parser building DOM has no problem - CITE element versus @cite attribute

<Joshue> GJR: There is a Drama Markup language in DAISY

AG: on other hand, a) don't know how much GJR been through drama markup in DAISY; in term of stage directions, that level of meta-conversation would look for precedence and structure in DAISY drama markup
... 2 homonyms recipie for confusion; logically makes more sense to leave dialog/dialogue alone and recast aria-dialog as aria-dialogbox

GJR: i understand and support that because then if HTML5 did introduce a dialogbox element, it would be in line with the ARIA concept of dialog box

<Joshue> +q

JS: makes more sense - a lot of those using tech non-native english speakers

JOC: is a need to disambiguate dialog from CS and natural language sense

AG: dialog not an aria- attribute - is a value of the role attribute - role="dialog" resisted putting aria- on beginning of role values

JOC: that could be confusing as well

AG: spirit of shared invention; dialogbox element in HTML5 would preclude need to use aria's dialogbox in markup

<Joshue> GJR: Should I take and action to propose that dialog be changed to dialogbox?

<scribe> ACTION: raise dialogbox as substitue for dialog as an ARIA role on pf list [recorded in http://www.w3.org/2008/12/05-pf-minutes.html#action01]

<trackbot> Sorry, couldn't find user - raise

GJR: ironic thing i thought i could cut to the quick with proposed solution, but i was wrong

<Stevef> may be of interest RIA User Input Widget role tests - Firefox 3 + Assistive Technology http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html

<Joshue> GJR: I thought I could resolve this quickly, didn't think it would take this much discussion

AG: poll on old business

JOC: @summary

AG: and @headers
... and meeting times

@headers

<Joshue> http://lists.w3.org/Archives/Public/public-html/2008Nov/0483.html

JOC: on HTML call yesterday, MikeSmith keen to get more feedback; don't know what more can provide - sent a post to public-html
... i've been saying this is it from our perspective, need movement/comment from HTML5 side
... HTML5 chairs keep asking for more evidence on @headers; don't know what else to say other than what we've already given them
... BenM's work not what we are concerned with at this time; not comparison between algorithms, want functionality discussion

<Joshue> -q

SF: no further comment on @headers -- clear where it stands

<Joshue> +1 to Steve

AG: feedback: on one hand, agreed we wanted to improve things with algorithms so don't need to rely on explicit bindings; want to work long-term on markup for author and algorithm for browser
... from our perspective, not too soon to get this through HTML WG -- binding poll to say, "put headers back because don't have algorithms deployed and fully developed" - would remove bone of contention between HTML profile we will test ARIA test suite against (will include @headers and @summary); agreed to disagree and rejoin debate later when can test algorithm to ascertain when one still needs to provide explicit bindings
... can then look at concrete examples of how algorithm fails; will still need explicit bindings, but much less so; hard to deal with hypotheticals; concentrate on the concrete - should we push HTML WG to run a binding poll that editor put @headers back in form that can get explicit markup that works and continue to work on algorithms and consider saying "need for headers will be obviated if algorithm works"

JOC: that is a very big IF

AG: understand, just being practical politically; @headers forever going to engender disagreement; @headers needed now less explosive; in terms of practice, need headers in HTML5

JOC: might be worth to speak with DanC -- has aske me explicitly "what do you think is best solution" - perhaps good idea for AG to talk to DanC about this; talked about scope/header support; would be good to get DanC on board

AG: been wondering if should ask Ben to join call

JOC: not much use - challange to comment on real-world usage of algorithms

AG: the ball of tumbleweed contains both @headers and an improved algorithm

JOC: working on the algorithm path is useful

AG: agree
... perfect opportunity if have manpower to do work on this

TEN MINUTE WARNING

AG: MikeS continues to return to JOC because HTML WG decision maker, but he wants our input

JOC: can't answer Mike anymore about progress on headers, need some action on behalf of HTML WG; i have nothing more to add; ball firmly in their court

SF: Mike has longstanding action to get hixie to re-review issue again

AG: we think stage is ready for HTML WG to put @headers back into draft; have to stress not opositional; is current @headers in draft too limited to make necessary markup possible?

JOC: put together a lot of solutions

SF: debated a couple of months ago in HTML WG -- ChrisW said very simple change, this is only 1 line, will happen, but went dead

AG: didn't go dead, got diverted -- charter issues demanded more study; can tell MikeS that we are ready to do poll

JS: i would remind action item was hixie to come back; waiting upon hixie; ready to go beyond that, but need progress report from editor and chairs

JOC: will ask for something from their side at next week

JS: hixie did offer to "ramp it up" - could gentlely point out can't go futher - process we agreed on, up priority now, all that needs to be said is said

<Joshue> @anne to some degree what we are waiting for is outside Bens research

<Joshue> @anne Bens research is useful but it is algorithm comparison and I think we need a decision on explicit semantics

<anne> I thought the main issue was about table headers having table headers of their own?

<Joshue> @anne, thats one part of it

<Joshue> http://lists.w3.org/Archives/Public/public-html/2008Nov/0483.html

SF: does Ben's research have that much of an effect on @headers reinstated as required?

TWO MINUTE WARNING

<anne> Joshue, yeah, Ben did research into that as well as into algorithms

<Joshue> @anne, ok

AG: if Ben's research indicated over the long haul can remove headers or don't need what we are asking for now; basic argument: assistive tech in place and runs off headers; continuity "thing" - paving cowpaths on one hand and solving real problems; removing headers solved perceived not real problem; need to put @headers back in until running code shows they are no longer needed; we need it now
... need people to read Ben's research report

<anne> based on what Hixie last said he'd work on this relatively soonish

<Joshue> @anne, good stuff

JOC: want to get algorithm implemented in major browsers, but then have to get AT vendors to use new algorithm instead of their own

<Joshue> @anne, aside from the algorithm one elegant solution (which is well supported by current AT) is headers/id combinations. For more see http://esw.w3.org/topic/HTML/IssueTableHeaders#head-29de33199bf5222d55c4a52b8970245d24bd286f

AG: poll of devs spotty but general support

<Joshue> @anne, use of @scope has advantage for authors but is very poorly supported (but that could change is UA support improved)

AG: don't chain if use headers, list them all; what i mean, browsers said "yes, should pick up algorith and hand over to AT" -- AT devs said, under such a scenario, would implement that
... @scope left to AT to do whole job in past; now proper division of work - browser provides more friendly info to AT

<anne> Joshue, that doesn't say that a header having headers associated with it is also acceptable

AG: proposition that get @headers reinstated and repaired is a simple change and brings HTML5 back in line with accessible process

<anne> Joshue, which is what I got out of the PFWG/HTMLWG meetings in Mandelieu

<anne> e.g. it starts with "Reinstate headers/id AND their functionality into the spec by specifically stating that headers are allowed to reference a td." though that's not how many people felt afaict

<Joshue> @anne, ok. some kind of staggered combination of improved algorithms and explicit semantics should fly I guess

AG: in reply to josh on public-html, can deprecate if have running code that is effective, but don't remove from spec until meets WCAG standard for accessibly supported -- most browsers and ATs supporting it; that's the roadmap for progress we've outlined

<Joshue> @anne, headers for header is needed

AG: ready for HTML WG to work on this; fix @headers now and continue to work on algorithm; doesn't need a poll

SF: once WCAG2 is a REC, then the use of test of accessibility supported will be useful tool to benchmark various a11y issues in HTML5
... thanks, al -- that makes things clearer

<Joshue> @anne, the headers/id idea is attractive because of good existing support. It may not be perfect..

AG: thank josh for doing his action item and work in HTML WG

<Joshue> thanks al

<anne> Joshue, yeah, the point is that header for header is not the same

<anne> Joshue, and that therefore the wiki page summary might not be accurate of what the acceptable solutions actually are

<Joshue> @anne, ok

<Joshue> @anne, thanks for the heads up, if there is confusion we should try and clear that up?

JS: probably need to discuss time of caucus calls on-list; would 1500 UTC be better? 1500 UTC collides with HTC call

<Joshue> @anne, the wiki does need to be tidied

JS: same time next week (1400 utc)

JOC: thanks for a very good meeting

<anne> Joshue, yeah, that'd be nice

JOC: maybe should revisit contents of wiki -- ensure reflects what we have agreed upon

<aaronlev> I provided feedback on @headers on whatwg mailing list, and it hasn't really been addressed yet

@aaronlev - did you cross-post to a w3c list?

<Joshue> bye bye

<aaronlev> no, sorry

<aaronlev> i'll send

<scribe> ACTION: review HTML wiki on @headers issue (http://esw.w3.org/topic/HTML/IssueTableHeaders) [recorded in http://www.w3.org/2008/12/05-pf-minutes.html#action02]

<trackbot> Sorry, couldn't find user - review

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/sens/sense/
Found Scribe: Gregory_Rosmaita
Found ScribeNick: oedipus
Default Present: Janina, Al, Gregory_Rosmaita, Joshue, Steven_Faulkner
Present: Janina Al Gregory_Rosmaita Joshue Steven_Faulkner
Regrets: Gez_Lemon Laura_Carlson
Got date from IRC log name: 05 Dec 2008
Guessing minutes URL: http://www.w3.org/2008/12/05-pf-minutes.html
People with action items: raise review

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.