IRC log of pf on 2007-04-12

Timestamps are in UTC.

13:06:02 [RRSAgent]: RRSAgent has joined #pf
13:06:02 [RRSAgent]: logging to http://www.w3.org/2007/04/12-pf-irc
13:06:07 [MichaelC_IAD]: rrsagent, make log world
13:06:15 [MichaelC_IAD]: meeting: WAI PF Face to Face Day 2
13:06:21 [MichaelC_IAD]: chair: Al_Gilman
13:06:48 [dpoehlman]: dpoehlman has joined #pf
13:07:15 [aaronlev]: aaronlev has joined #pf
13:07:40 [aaronlev]: aaronlev has joined #pf
13:08:02 [aaronlev]: aaronlev has joined #pf
13:08:05 [Al]: Al has joined #pf
13:08:18 [MC_Projector]: MC_Projector has joined #pf
13:08:53 [Rich]: Rich has joined #pf
13:10:58 [MichaelC_IAD]: agenda: http://www.w3.org/WAI/PF/Group/meetings/f2fapr07.html#agn
13:14:49 [clc4tts]: clc4tts has joined #pf
13:17:15 [janina]: janina has joined #pf
13:19:12 [aaronlev]: aaronlev has joined #pf
13:20:00 [JRG]: JRG has joined #pf
13:20:25 [Jon]: Jon has joined #pf
13:20:25 [don]: don has joined #pf
13:23:36 [JRG]: JRG has joined #pf
13:25:22 [dpoehlman]: scibe: dpoehlman
13:25:31 [aaronlev]: Web IRC client works: http://ircproxy.emigrantas.com/
13:26:27 [MichaelC_IAD]: scribe: dpoehlman
13:26:58 [aaronlev_webchat]: aaronlev_webchat has joined #pf
13:27:50 [MichaelC_IAD]: q+
13:30:18 [clc4tts]: q+
13:30:50 [Rich]: q?
13:30:55 [MichaelC_IAD]: ack me
13:31:14 [JRG]: JRG has joined #pf
13:32:06 [aaronlev]: hi JRG
13:32:43 [Rich]: q+
13:32:46 [MichaelC_IAD]: q+ JRG
13:32:54 [MichaelC_IAD]: ack cl
13:33:37 [clc4tts]: ack me
13:33:40 [MichaelC_IAD]: ack r
13:35:18 [MichaelC_IAD]: q+ to rephrase question as "what does a UA have to do to validly claim it supports ARIA" - validly meaning meeting our requirements, and producing the expected results for the user
13:36:09 [JRG]: JRG has joined #pf
13:37:30 [clc4tts]: scribe: clc4tts
13:38:03 [clc4tts]: al: i've always thought that if there were certain things the browser had to do for the content to reach the user, we have to find a way to do that
13:38:20 [clc4tts]: al: what statement is needed for browsers to do the right thing so that developers will take it up
13:38:54 [clc4tts]: al: we can look at ua. we can ghostwrite techniques for ua that say, to make the ua provisions that the way you do aria is the following techniques, best practice
13:39:04 [clc4tts]: al: this is how you meet this requirement
13:39:23 [clc4tts]: al: the normative requirement is the ua requirement - we are just providing a suggestion for how to meet that
13:39:44 [clc4tts]: rich: i'm concerned that the w3c will say that you need a normative way to map this
13:39:57 [clc4tts]: rich: we got to do one for msaa on windows, atk on linux, etc
13:40:15 [clc4tts]: al: w3c won't lay that on us. what we put is our ambition, what we have the normative statements for
13:40:25 [clc4tts]: al: we have to publish something that publishes the techniques
13:40:41 [JRG]: JRG has joined #pf
13:40:50 [JRG]: Hello
13:40:51 [clc4tts]: al: an informative annex this is what we know about good binding would be good
13:41:07 [clc4tts]: rich: i'm ok with that, but we can't do any platform
13:41:18 [clc4tts]: rich: we'll have to choose
13:41:19 [MichaelC_IAD]: ack jrg
13:41:35 [clc4tts]: jon: problem with uag is that what is rendered and what is in the dom is not the same. sometimes you have invalid html
13:41:54 [clc4tts]: jon: we have the requirement for the dom, requirement for the window dressing not through the dom
13:42:12 [clc4tts]: jon: in terms of notification, the normative part says that changes to the document styling, only changes to the dom have to be provided
13:42:35 [clc4tts]: jon: no requirement to provide notification if dom is not changed
13:42:44 [clc4tts]: al: we feel that show and hide must be known to at
13:43:51 [MichaelC_IAD]: q+ to talk about spec versioning
13:43:53 [clc4tts]: jon: mappings have to be techniques for extendability
13:43:55 [Rich]: q+
13:43:59 [MichaelC_IAD]: ack me
13:43:59 [Zakim]: MichaelC_IAD, you wanted to rephrase question as "what does a UA have to do to validly claim it supports ARIA" - validly meaning meeting our requirements, and producing the
13:44:03 [Zakim]: ... expected results for the user and to talk about spec versioning
13:44:25 [clc4tts]: michael: maybe we got scared byt he idea of providing all apis, but we need to state what it means to support aria
13:44:50 [clc4tts]: michael: do we only ask that they expose aria? that's ok, but we need to say what we are asking for ua to do
13:45:21 [clc4tts]: michael: not all useragents are going to claim aria support. we want our definition of support to lead to something meaningful for users
13:45:43 [clc4tts]: michael: if something changes (response to jon), we should use spec versioning
13:46:10 [clc4tts]: michael: this is aria 1.0 - in aria 1.x, a compliant ua agent would be expected to handle something more
13:46:29 [clc4tts]: al: we may not invite ua to say if they are conformant or not
13:47:07 [clc4tts]: al: if it is purely a content spec, sites will claim conformance, but user agents can say they support in their vpat that they support the ua, but it is not part of aria conformance
13:47:35 [clc4tts]: al: it's a weaker publicity push if we don't have user agents advertising they support this, but it is not wired into the system that we have to have user agent conformance
13:47:42 [clc4tts]: al: it's a maybe. how normative is it?
13:48:04 [clc4tts]: michael: we're specifying a content and coding technology. if we don't say what is supposed to be done with content, it could be useless
13:48:14 [clc4tts]: al: if the author has no idea, they are not likely to follow the model
13:48:25 [MichaelC_IAD]: q?
13:48:27 [MichaelC_IAD]: ack r
13:48:50 [clc4tts]: rich: i think we need content conforming aria and ua conforming aria. we need to bridge this to the at.
13:49:06 [clc4tts]: rich: content can be retrieved through the document model - then from a content pserpective we are fine
13:50:01 [clc4tts]: rich: then we have the ua part. this show and hide thing concerns me. what we don't have is something tangible other than a technique that says you can support as a best practice by writing this whole section into the dom or using css to show this. but that's a technique and not a standard. how do we make this into a standard for an aria content developer. how do we define something that the...
13:50:02 [clc4tts]: ...browser can support.
13:50:10 [clc4tts]: rich: how can we pin something to the content piece.
13:51:14 [Al]: q+
13:51:26 [clc4tts]: michael: assistive technology wants to get to the richness of aria and ideally it wants to do it in a way without special customization. if it is only available for the dom, then at will have to add stuff to make it work. whereas if the user agent mapped to the accessibilty api, then ua that arleady support the api wouldn't have to do anything special
13:52:34 [clc4tts]: rich: i look at the two pieces. like menus, if you were to write those into the dom, then everything that you are putting in has the aria role and states that you need. you just wrote them in. that's fine. but what do we do about css? let's say you have context menus. what can we do to make that work?
13:53:07 [clc4tts]: aaron: we could add a property and ask people to add something to support aria. so if they want to do it right, they can have it.
13:53:11 [MichaelC_IAD]: q+ to suggest support for DOM 2 Style module
13:53:19 [clc4tts]: aaron: setting a certain attribute that shows or hides it
13:54:16 [clc4tts]: aaron: you can do it inline
13:54:34 [clc4tts]: aaron: there is the attribute for the dom and the javascript properties. sometimes there is a map, sometimes not
13:55:48 [clc4tts]: aaron: you could set the aria state and change the css
13:56:07 [clc4tts]: aaron: so then the user agent can support the whole thing in the dom
13:56:44 [clc4tts]: rich: if they expose the dom, you can do your job.
13:56:58 [clc4tts]: al:the full support should be in the dom, and if you can map it to the api, you should
13:57:25 [clc4tts]: rich: if we put this aria show property, at least we have compliant content
13:57:49 [clc4tts]: rich: then we look at the ua. if the ua can present everything, then you have a compliant ua for the os
13:58:17 [Al]: q?
13:58:20 [clc4tts]: michael: i would drop the all. if the api doesn't have everything, then that part can be left in the dom. but at least the accessibilty api is complete
13:59:39 [clc4tts]: rich: i don't know whre john hervatten (ie7) is on ui automation, but let's say there wasn't an aria mapping for some of the aria features, then if it is not avaiable throught he api, you could also provide it through the dom. what do you tink?
14:00:07 [MichaelC_IAD]: s/hervatten/hrvatin
14:00:50 [clc4tts]: johnhrv: i always think presenting it in the dom is a back up method. i think only a small set of properties don't map to the msaa. are you really going to go through the dom just to get those few properties?
14:00:50 [leesa]: leesa has joined #pf
14:01:24 [clc4tts]: johnhrv: should map it as best fit. if something is really incompatible, then go through the dom.
14:01:37 [clc4tts]: rich: i think for ie, freedom scientific uses a combo of msaa and dom
14:02:40 [clc4tts]: johnhrv: making everything through the dom is an important fall back. if there are browser differences.
14:03:00 [clc4tts]: aaron: we still need to support the unofficial method as well just because it is standard practice, but it shouldn't tie down the spec
14:03:18 [clc4tts]: al: question. it sounds like we convinced ourselves is that only the show and hide changes are missing.
14:04:05 [clc4tts]: al: so we want to put in something in the spec that will be used to drive those changes. and the style rules will trigger off that selector to change visibility or display properties to get these things to show up or disappear
14:04:20 [clc4tts]: aaron: we should bring back hidden
14:04:48 [clc4tts]: aaron: have hidden = true (default is hidden=false)
14:05:08 [clc4tts]: rich: that's part of the solution. we make it available through the dom. we also want this to support the accessibility api.
14:05:12 [Al]: RESOLUTION: bring back 'hidden' property
14:05:23 [clc4tts]: al: this is just one minor point, but it is worth noting
14:05:39 [Al]: q?
14:05:40 [clc4tts]: michael: all aria properties must be available in the dom, right?
14:05:43 [clc4tts]: rich: right
14:05:44 [Al]: q-
14:06:34 [clc4tts]: rich: we have an action item to add hidden property to states and properties
14:06:48 [clc4tts]: action michael add hidden back in to states and properties
14:07:22 [clc4tts]: action: michael to add hidden to states and properties
14:08:24 [clc4tts]: action: michael to add marquee
14:09:59 [clc4tts]: action: michael to add statement that all aria must be available in dom (hook in ua requirements in that statement)
14:10:44 [clc4tts]: rich: we should have techniques for the user agents.
14:11:01 [clc4tts]: al: if we think they should be out there, we need to publish them. if we don't publish, it won't happen
14:11:35 [clc4tts]: aaron: what level of detail?
14:12:01 [clc4tts]: aaron: all we do with aria properties is expose them to the accessibility api
14:12:37 [clc4tts]: aaron: the user experience techniques is something that clc could write up
14:13:47 [clc4tts]: clc: couldn't at that handle msaa just handle it the same way as standard windows apps?
14:13:56 [clc4tts]: aaron: no. live region is a new concept.
14:15:06 [clc4tts]: aaron: there are techniques of how do you map to the api, and then how do you process the aria and handle user experience
14:15:52 [clc4tts]: jon: if microsoft is implementing this for ie, then it would be nice if ie and ff do it in a compatible way
14:16:02 [MichaelC_IAD]: ack m
14:16:02 [Zakim]: MichaelC_IAD, you wanted to suggest support for DOM 2 Style module
14:16:16 [clc4tts]: aaronL they've been using our docs on that
14:16:30 [clc4tts]: al: anything to wrap up?
14:16:45 [clc4tts]: rich: do we need to make some statement about user agents?
14:17:20 [MichaelC_IAD]: action 2 = michael to add statement that all aria must be available in dom (hook in ua requirements in that statement) and mapping to accessibility API is recommended where possible
14:17:57 [clc4tts]: al: look at issue 66 when drawing up the techniques
14:18:16 [clc4tts]: resolution: close issue 27
14:18:44 [clc4tts]: RESOLUTION: close issue 27
14:19:22 [Zakim]: -Lisa_Seeman
14:22:09 [Zakim]: -John_Hrvatin
14:22:24 [Zakim]: -Glen_Gordon
14:24:03 [leesa]: folks is it Ok if I take a brake for an Hour
14:24:22 [leesa]: I have phisotheripy in a half hour so i might as well go now
14:24:43 [leesa]: is that OK or are we deeling with the speck when we get back?
14:28:18 [Stefan]: Stefan has joined #pf
14:29:35 [Al]: I would suggest that you go ahead and leave for the physiotherapy. We will likely have spec consequences from the 'interim' discussion but there will be action items to develop proposals.
14:32:10 [MichaelC_IAD]: MichaelC_IAD has joined #pf
14:33:18 [Zakim]: +Glen_Gordon
14:34:48 [Stefan]: Stefan has joined #pf
14:35:37 [Stefan]: hi
14:35:46 [Stefan]: test
14:35:50 [Stefan]: cool
14:36:07 [Stefan]: anybody else here?
14:36:34 [Stefan]: cool
14:36:50 [Stefan]: ok .. ready for some text input ..
14:38:17 [Stefan]: scribe: stefan
14:38:33 [Stefan]: scribe: Stefan
14:39:27 [Stefan]: topic: interim
14:41:07 [Stefan]: reference is http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions#Issues_and_Proposed_Solutions
14:41:14 [Al]: action: Al research the status of a possible 'busy' issue in consultation with Aaron
14:41:39 [Stefan]: topic: interim
14:41:55 [Stefan]: Charles demonstration of interim
14:42:34 [Stefan]: interim is not there in live regions, -> sometime no announcements
14:42:50 [Stefan]: e.g. in count 5 never announced
14:43:45 [Stefan]: anouncements fail if interim is set sometimes, actual speech output falls behind
14:44:37 [Stefan]: consequence for stock prices, game logs .. user falls behind considered as serious
14:45:22 [Stefan]: Aaron: interim=true means all changes in between are relevant
14:46:02 [Al]: q+
14:46:12 [Stefan]: Aaron: now way for AT to manages that
14:46:29 [MichaelC_IAD]: MichaelC_IAD has joined #pf
14:47:30 [Stefan]: Aaron: what is the default? all page changes are always important?
14:49:10 [Al]: Zakim, who is here?
14:49:11 [Zakim]: On the phone I see Face_to_Face, Glen_Gordon
14:49:12 [Zakim]: On IRC I see MichaelC_IAD, Stefan, leesa, JRG, aaronlev, janina, clc4tts, Rich, MC_Projector, Al, dpoehlman, RRSAgent, Zakim
14:50:46 [Stefan]: Aaron: all of these are just hints .. need to have way for content providers to mark-up pages
14:51:03 [Tim]: Tim has joined #pf
14:51:22 [leesa]: thanks al
14:52:17 [TimBoland]: TimBoland has joined #pf
14:52:57 [Stefan]: Glen: Last thing in region that changed info may be sufficient for update of Live Regions
14:53:54 [tm]: tm has joined #pf
14:55:00 [Stefan]: Al: are some parts of page garbage? are other needed? how to separate them? -> Markup for critical/deferrable needed
14:56:10 [Stefan]: Aaron: iterim is for things that OBLITERATE each other
14:58:12 [Stefan]: Jon: screen reader functions used to look explicitly into regions of interest
15:01:30 [Stefan]: Glen: example : update of 2 stock prices, one changes frequently, the other not - would they kill each other?
15:01:53 [Stefan]: Charles: with his algorithm NOT
15:01:53 [Tim]: Tim has joined #pf
15:05:41 [don]: don has joined #pf
15:07:02 [Stefan]: action: Charles - create real world example or problematic interrupts
15:09:08 [Stefan]: Al: back to outstanding issues
15:10:05 [Stefan]: topic: outstanding issues of yesterday (#59 etc.), causality issue first http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions#Issues_an, Issue 1d_Proposed_Solutions
15:10:21 [Stefan]: http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions#Issues_and_Proposed_Solutions, Issue 1
15:10:42 [Stefan]: he AT will need some way to know whether a control is really controlling a live region or if the onChange event for a particular control and an update to a live region that it controls is merely a coincidence (imagine a user tabbing out of the input blank after having typed something but without pressing enter and having some other user send a message at about the same time - both events...
15:10:43 [Stefan]: ...happened, but the change in the input blank was not the cause for the new message that appeared in the blank).
15:11:02 [Stefan]: The browser can trace through the stack of JavaScript function calls that resulted in a change to the page to see if that change was caused by a JavaScript function that was triggered by a user action (such as clicking on a button). This cannot determine causality for every case as it is possible that the user action causes an HTTP request to be made to the server and the response handler...
15:11:04 [Stefan]: ...for that request then causes the change; such a change would appear to be coming from a world event rather than a user action. However, knowing the source of a change could be helpful in disambiguating the two cases in other scenarios. In addition, for situations where a change can be caused by either user interaction or a world event, the recommendation is to not specify that live region...
15:11:05 [Stefan]: ...as something that the control is controlling.
15:13:46 [Stefan]: Chaals: analogue to popup-blocking issue
15:15:19 [Stefan]: Al: web security contexts matter .. there is a group in W3C working on a requirements doc
15:15:42 [chaals]: chaals has joined #pf
15:17:46 [Stefan]: Al: different effective politeness needed
15:17:52 [Zakim]: -Glen_Gordon
15:22:48 [Stefan]: Al: not in the page .. security people might not be happy with it
15:23:46 [Stefan]: Chaals: use case is having different politeness instructions
15:25:10 [Stefan]: Chaals: ..meaning politeness levels ..
15:25:33 [Stefan]: Rich: is there anything for content author to do?
15:27:06 [Stefan]: topic: still causality issue
15:28:09 [chaals]: Web Security Context group -> http://www.w3.org/2006/WSC/
15:29:25 [Stefan]: Rich: take becky's tree view example: tree item controls another piece .. what to do for page author?
15:30:53 [Stefan]: .. to be continued ..
15:31:44 [Stefan]: topic: WD #090
15:32:33 [Stefan]: topic: WD #90 what to do when activedescendent is not a decendant
15:33:21 [Stefan]: Al: go back path to root to know if its really a descendant
15:33:48 [Al]: Zakim, who is here?
15:33:48 [Zakim]: On the phone I see Face_to_Face
15:33:49 [Zakim]: On IRC I see chaals, Tim, MichaelC_IAD, Stefan, leesa, JRG, aaronlev, janina, clc4tts, Rich, MC_Projector, Al, dpoehlman, RRSAgent, Zakim
15:33:52 [Stefan]: Aaron: if it is .. what should User Agent do? Need advice
15:36:33 [Stefan]: Rich: example: table / grid is managing descendants, button outside table focused - what to do?
15:36:40 [Al]: q-
15:37:29 [Al]: ack chaals
15:37:29 [Zakim]: chaals, you wanted to say what is the problem that arises
15:37:52 [Stefan]: Aaron: put focus on container that has activedescendant ?!
15:38:45 [Stefan]: Rich: who's managing the button?
15:39:21 [Stefan]: Al: don#t understand how this is coupled with bubbling lin DOM
15:39:50 [Stefan]: Chaals: see not the problem
15:41:31 [Stefan]: Al: just question of managing the Active ID, Rich agrees
15:41:46 [Zakim]: +??P5
15:44:51 [Stefan]: Rich: leave focus where it is! no Browser change of focus
15:45:13 [leesa]: rich can you speek yo?
15:45:17 [leesa]: up
15:46:05 [Stefan]: Aaron: so ignore activedecendant if it is not a descendant? Is that the solution?
15:46:49 [Al]: q+
15:47:47 [Stefan]: proposed: ignore activedecendant if it is not a descendant (Chaals/Aaron discussion ongoing)
15:52:33 [don]: don has joined #pf
15:53:44 [JohnHrv]: JohnHrv has joined #pf
15:57:59 [Stefan]: proposed: author must ensure that activedecendant is really a descendant, the user agent should not check this before forwarding focus
15:58:39 [Al]: "really a descendant" in includes via 'owns'
16:00:03 [Stefan]: objections: none
16:00:09 [JohnHrv]: JohnHrv has joined #pf
16:01:12 [Al]: lunch until :45
16:01:14 [Zakim]: -Lisa_Seeman
16:25:24 [Al]: Al has joined #pf
16:37:48 [dpoehlman]: dpoehlman has joined #pf
16:42:16 [Al]: note -- yesterday's minutes http://www.w3.org/2007/04/11-pf-minutes.html
16:44:44 [Zakim]: +??P3
16:48:11 [JRG]: srcibe: jrg
16:48:24 [Al]: scribe: JRG
16:48:26 [JRG]: scribe: JRG
16:48:55 [JRG]: AL: AL what merit the most FTF time
16:49:11 [JRG]: AL: I am not sure about Issue 80
16:50:10 [JRG]: AG: Let's do Ramans think about Atomic
16:50:34 [JRG]: AL: I have some proposal
16:50:38 [aaronlev]: Case 1: if none of the ancestors have explicitly set atomic, this is the default (aaa:atomic="false") case, and the AT only needs to present the changed node to the user.
16:50:40 [aaronlev]: Case 2: if aaa:atomic is explictly set to false, then the AT can stop searching up the ancestor chain, and should present only the changed node to the user.
16:50:41 [aaronlev]: Case 3: if aaa:atomic is explicitly set to true, then the AT should present the entire subtree that aaa:atomic="true" was set on.
16:50:43 [aaronlev]: The AT may choose to combine several changes and present the entire changed region at once.
16:50:44 [aaronlev]: Normally, those rules apply whether the list node was changed or just the text changed.
16:50:46 [aaronlev]: However, it's possible to change that default behavior using aaa:relevant. For example, setting aaa:relevant="text" means that only text changes should be presented.
16:50:52 [aaronlev]: When a node changes, the AT should look at the current element and then traverse the ancestors to find the first element with aaa:atomic set.
16:51:43 [JRG]: JRG has joined #pf
16:52:36 [JRG]: AL: explains his proposal
16:53:14 [JRG]: AG: If you have an atomic on the grandfather and .... then only the child is spoken
16:53:23 [JRG]: AL: You can have sub regions spoken
16:53:35 [JRG]: AG: You stop reading when you see atomic
16:53:45 [dpoehlman]: dpoehlman has joined #pf
16:53:53 [JRG]: AG: It is asserted again, you stop when you hit that
16:54:08 [JRG]: AL: The closest ansestor winds
16:54:14 [JRG]: AL: Glen are you on?
16:54:20 [JRG]: AL: I don't think so
16:54:20 [clc4tts]: q+
16:54:23 [JRG]: AL: Lisa?
16:54:25 [Al]: Zakim, who is here?
16:54:25 [Zakim]: On the phone I see Face_to_Face, Lisa_Seeman
16:54:26 [Zakim]: On IRC I see dpoehlman, JRG, Al, JohnHrv, chaals, Tim, MichaelC_IAD, leesa, aaronlev, clc4tts, Rich, MC_Projector, RRSAgent, Zakim
16:54:28 [JRG]: LS: I am on the phone
16:54:37 [Al]: q-
16:54:37 [clc4tts]: ack me
16:54:48 [JRG]: CC: I agree with AL
16:54:59 [JRG]: CC: Firefox currently does this
16:55:10 [JRG]: RS: Fine with me if AT vendors are happy
16:55:21 [JRG]: AL: Can someone ask GG?
16:55:34 [JRG]: RS: Let's kepp it, no other good options
16:55:55 [JRG]: AL: AT should combine and log all events should be spoken
16:56:30 [JRG]: AL: May should be changed to should
16:56:50 [JRG]: CMN: cobine the region
16:57:32 [JRG]: CC: What happens two two regions that change at slightly different times, you need to provide some pausing
16:58:07 [JRG]: AL: I did put may because I didn't define it better, it was not intentiona;
16:58:28 [JRG]: AG: Any value spoken the change has been handled
16:58:47 [JRG]: AL: I'll except the arguement, no change
16:59:00 [JRG]: MC: The instered text is fine?
16:59:49 [JRG]: AG: Yes, use AL proposal
17:00:08 [JRG]: MC: Make a note to insert
17:00:19 [JRG]: RS: Can we close the issue?
17:00:27 [JRG]: AG: Yes, add AL text
17:01:03 [JRG]: RESOLUTION: Accept AL proposal for nested atomic properties
17:02:05 [clc4tts]: q+
17:02:23 [Al]: action: Al close issue WD#83 (atomic nesting)
17:02:34 [clc4tts]: ack me
17:02:37 [JRG]: CC: The closest one wins?
17:02:41 [JRG]: AL: yes
17:02:52 [JRG]: CC: It seems sensible and thats what I am doing
17:03:21 [JRG]: AG: The point is that polietness is herititary
17:03:37 [JRG]: AL: It is a pretty standard concept of inheritance
17:04:16 [JRG]: CC: You may want to be explicit about it
17:04:25 [JRG]: MC: That is what we want to insert right
17:04:35 [JRG]: AL: Relavent is a key word
17:04:51 [JRG]: AL: Relavent is a liveregion property
17:04:59 [JRG]: MC: I don't see it here
17:05:07 [JRG]: RS: It is a property
17:05:32 [JRG]: MC: Edting document for relevant
17:06:14 [JRG]: RS: Next?
17:07:09 [JRG]: AL: Review busy issue
17:07:51 [JRG]: AL: An author may change a region, but it may take some time before it is finished loading and then be displayed to the user
17:08:23 [JRG]: AL: The busy property makes sure the region is not presented until the autor says it is done
17:08:34 [JRG]: LS: I think it is an excellent idea
17:08:58 [JRG]: LS: When you are making lots of changes, is there nothing that already supports that?
17:09:21 [JRG]: AL: I have not seen anything
17:09:31 [JRG]: JG: What about display: none
17:09:45 [JRG]: AL: It might be visible, just not done
17:09:56 [JRG]: CMN: Is this a progress event
17:10:08 [JRG]: AL: Is this 0 percent complete...
17:10:24 [JRG]: AL: We have progress meter, but no way to link
17:10:34 [JRG]: AG: We have controls?
17:10:50 [JRG]: AL: Does the region control the progress meter, or visa versa
17:11:11 [clc4tts]: q+
17:11:16 [JRG]: CMN: The notion of progress events, there is something going on and it spits back prgoress events
17:11:43 [JRG]: CMN: It may say that is on the way, in that notion that you use those events to update the bar
17:12:03 [JRG]: AL: If something is just a few seconds, it may not be worh it
17:12:22 [JRG]: CMN: You say someting is busy and then say if is not busy
17:12:32 [JRG]: CMN: I am writing a draft
17:12:45 [JRG]: LS: -1 may mean it is ...
17:13:04 [JRG]: AL: If you don't know wne it will finish it is undetermined
17:13:16 [JRG]: LS: The value now could be a real value
17:13:40 [chaals]: Editor's draft of Progress events -> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html
17:13:40 [JRG]: LS: The value is not in the success, but in the information that something is changing
17:13:50 [JRG]: AL: There is a role progress meter
17:14:13 [JRG]: LS: We have valuenow as a state and maybe we need a progress property
17:14:27 [JRG]: LS: It is jsut useful information to pass on to the user
17:14:44 [JRG]: LS: You could go to -1 if there is an error
17:14:57 [JRG]: AL: I don't like magic values, because they cause bugs
17:15:20 [JRG]: CMN: You start event and then anything can listen to progress events
17:15:37 [JRG]: CMN: What the current value is, the final value...
17:16:07 [JRG]: CMN: in an IRC channel you can never know the end, but you might be interested in some measue of how much you have
17:16:21 [JRG]: CMN: When you know the size you can
17:16:41 [JRG]: AL: Length computable in undetermined
17:17:28 [JRG]: CC: I want to address something, the status should be a control to the user
17:17:39 [clc4tts]: ack me
17:17:49 [JRG]: CC: If you use the AT to list the controls, but the user cannot inteact with it
17:18:33 [JRG]: AL: I think the progress meter spec is a little more complicated, in the busy feature is just wait there is a tansistion
17:18:51 [JRG]: AL: the change events are artifacts, not complete
17:19:06 [JRG]: AG: IRC comes line by line anyway
17:19:21 [JRG]: AL: ATK has a state called stale
17:19:31 [JRG]: AL: Don't use it until...
17:19:57 [JRG]: AG: We can get the functional effect by using live=off, interium events don't get spoken
17:20:14 [JRG]: AL: Is there value in telling the user that something is busy
17:20:36 [JRG]: AL: This not a super long update
17:20:47 [JRG]: CC: I said something similar to what RS said
17:20:59 [JRG]: CC: This doesn't sound quite as hackey
17:21:13 [JRG]: AL: There is a busy state in the Accessibility API
17:21:31 [JRG]: CC: The advantage is that it looks cleaner
17:22:03 [JRG]: AG: I would tilt in the direction of having it, since it will be more direct for authors to use
17:22:24 [JRG]: AL: When you see busy in the spec...
17:22:51 [JRG]: RS: It is just another property
17:23:12 [JRG]: CC: Using live breaks inheritance rules
17:23:16 [JRG]: AG: True
17:23:31 [JRG]: AG: Any objection to adding busy
17:23:57 [JRG]: LS: Just waying busy is wasted,I propose progress
17:24:18 [JRG]: DP: The you have 1/4, 1/2, 3/4 done....
17:24:37 [JRG]: LS: CMN proposal is well thought out...
17:25:10 [JRG]: LS: We can add more values, people using want more information
17:25:52 [JRG]: LS: If we add a new state, we may need to add more values for future expansion and backward compatibility
17:26:01 [JRG]: AL: I think thta is a good poiint
17:26:33 [JRG]: AL: We don't want to have progress = 100 on everything
17:26:51 [JRG]: AL: We can have other values like progress like "error"
17:27:07 [JRG]: AG: Let's take the terms for web API group
17:27:22 [JRG]: AG: Is there a way to capture the last event?
17:27:30 [JRG]: AL: You listen for them
17:27:54 [JRG]: CMN: If you lifted something from the progress spec, you would just have the last event
17:28:17 [JRG]: CMN: Talked about status values from spec...
17:28:29 [JRG]: AL: Want to propose something
17:29:08 [JRG]: LS: New property called "progress": complete, error, 'not started', ...
17:29:15 [dpoehlman]: q+ what about other progress behaviours>
17:29:15 [JRG]: AG: Can this be homework
17:29:33 [JRG]: LS: I've got none, value, complete...
17:29:46 [JRG]: AL: How is a sighted person going to know?
17:29:57 [clc4tts]: q+
17:30:03 [JRG]: AL: We started this to keep the screen reader from speaking too soon
17:30:31 [JRG]: LS: this is something they can trigger on that from the value of progress, it can be visible
17:30:32 [dpoehlman]: q+ to say what about other behaviours such as count down till done? time remaining?
17:30:58 [JRG]: LS: Seeing something fast or slow, you can make decisions about reading now or later
17:31:01 [clc4tts]: ack me
17:31:27 [JRG]: LS: It is something that is usually available and authors often make available
17:31:46 [JRG]: AL: I was going to say that we cannot define the values now, we can look at it later
17:32:02 [MichaelC_IAD]: ack d
17:32:02 [Zakim]: dpoehlman, you wanted to say what about other behaviours such as count down till done? time remaining?
17:32:21 [JRG]: DP: My sentiments are similar, x number of mintes remaining, we need to think about how to measure progress
17:32:22 [leesa]: q+
17:32:53 [JRG]: RS: I am worried about confusing people
17:33:12 [JRG]: LS: People can just put in string, but have recommendations like "busy"
17:33:38 [JRG]: AL: How do developers know that these are strings and not values
17:34:17 [JRG]: AG: I think that you should have a progress control like RS said, different interfaces can show or hide the information from users
17:34:34 [JRG]: AG: The piint is that is has valuenow attribute
17:35:13 [JRG]: AG: Maybe we do need a busy property
17:35:40 [JRG]: AL: So it would be an attribute to an IDREF, if it is not there it is ...
17:35:50 [JRG]: AG: That would be one way to do it
17:36:11 [Stefan]: Stefan has joined #pf
17:36:42 [JRG]: LS: I don't know, what started with an easy use case, it is important to the user, but information now needs to create another contro and have references, i don't like it
17:36:49 [Stefan]: Stefan has joined #pf
17:37:07 [JRG]: LS: The proposal was busy, then we changed it to progress and now we have separate control with references
17:37:15 [JRG]: DP: I am alittle confused
17:37:30 [Stefan]: Stefan has joined #pf
17:37:52 [JRG]: DP: If we have progress meter, rather than something
17:38:22 [JRG]: DP: WHy not use the control
17:38:31 [JRG]: JRG: It is more work for authors
17:38:44 [Stefan]: Stefan has joined #pf
17:38:48 [JRG]: AG: Is the proposal is busy?
17:38:57 [JRG]: LS: How about progress?
17:39:01 [JRG]: LS: We can add more values
17:39:12 [JRG]: AG: What you mean add more values
17:39:33 [JRG]: LS: If we do not have a value "error", "busy" still works
17:39:57 [JRG]: AG: we don't write those rules, there is a lot of heat in the HTML working group
17:40:49 [JRG]: AG: We have 2 proposals: busy=[true|false] or progress[busy|error|complete???]
17:41:21 [JRG]: AG: If you have a progress meter you can use it, if you don't we can use one of these two properties
17:41:34 [JRG]: AG: I don't hear a consensus
17:41:44 [JRG]: LS: Straw pole?
17:41:55 [JRG]: CMN: I like progress with a string
17:42:06 [JRG]: MC: pass
17:42:23 [Stefan]: Stefan has joined #pf
17:42:23 [JRG]: CC: I like busy, with a third value error
17:42:38 [JRG]: JS: I like CC option
17:42:45 [Zakim]: +Glen_Gordon
17:43:07 [JRG]: SS: I like busy with 'error'
17:43:25 [JRG]: DP: I like progress, but describe them
17:43:47 [JRG]: JRG: I progress with enumeration
17:44:04 [JRG]: DV: Progress with string
17:44:23 [JRG]: AL: I like busy with tristate values
17:44:37 [JRG]: TB: Do we have definitions
17:44:48 [JRG]: RS: Busy with tristate
17:45:08 [JRG]: AG: Consensus is busy[true|false:error]
17:45:16 [JRG]: AG: Consensus is busy[true|false|error]
17:45:50 [JRG]: AG: Much I have advocated for short names
17:46:16 [JRG]: AG: Look at CSS have open ended media types, with a few suggestions
17:46:41 [JRG]: AG: RESOLVED: Put in the 3 state busy
17:47:08 [JRG]: action: cc write up proposal for busy
17:47:36 [JRG]: RS: We can close that
17:48:27 [JRG]: AG: Nose count for hosted dinner tonight?
17:48:47 [JRG]: AG: 9 people
17:49:18 [JRG]: Issue #86
17:49:42 [JRG]: http://pf-issues:kW9!prCy@cita.disability.uiuc.edu/pf-issues/issues-linear-wd-1.html#86
17:49:58 [JRG]: break
17:50:13 [JRG]: AG: Things around the control relationship
18:06:02 [chaals]: scribeNick: chaals
18:06:12 [chaals]: scribe: chaals
18:07:06 [chaals]: Topic: Issues 86, 50, 59
18:07:49 [chaals]: AL: It is hard for the AT to find the status bar and know whose status it represents (other part of the page, status region isn't visible, ...)
18:08:38 [chaals]: ... idea is that the status is controlled by what the user is doing. The region which has a status somewhere should use the controls property to point to the status region.
18:08:59 [MichaelC_IAD]: q?
18:09:04 [chaals]: AL: Also, what should "controls" be allowed on? Suggest anything - status quo
18:09:11 [MichaelC_IAD]: q- leesa
18:09:24 [chaals]: RS: "controls" isn't the same as statusOf - something else might control the status bar.
18:09:34 [chaals]: ... could be live, controlled by something else, ...
18:09:47 [chaals]: AL: Example?
18:09:58 [chaals]: RS: You have 2 or three things that update the status bar
18:10:13 [chaals]: AL: Those would all point to the same status as "controls"
18:10:47 [chaals]: RS: Example, I have a mail client. I select a message, and that updates the status - but the status is for the whole document.
18:11:01 [chaals]: AL: This is already what we are using it for.
18:11:23 [chaals]: AG: This is a status that is part of the scripted application.
18:11:49 [Rich]: q?
18:12:14 [chaals]: SS: Status bar means the browser one, or some internal region? We have a message area that acts as a status for an application.
18:12:45 [chaals]: AL: This is a region in the application
18:13:00 [chaals]: SS: Is this an alert?
18:13:17 [chaals]: AL: Alert only exists sometimes. Status is there all the time.
18:13:30 [chaals]: SS: Example - an alert that is there all the time
18:13:37 [chaals]: AL/RS: Should have been status
18:14:12 [chaals]: AL: Alert is urgent. It may have been chosen because it has more backwards compatibility.
18:15:51 [chaals]: AL: If status just shows something from the real world, it is just a liveRegion. Status is something that reacts to things on the page. We should come up with some language to clarify this.
18:18:19 [chaals]: CMN: Agree with the idea to use controls, and that we should look at some clearer explanation of when to use status/alert/liveRegion
18:18:45 [chaals]: RS: When we have a status bar, the thing that controls the status is the thing that the status applies to.
18:18:51 [chaals]: ... right?
18:19:09 [clc4tts]: q+
18:20:01 [clc4tts]: ack me
18:20:20 [chaals]: CC: Status and liveregion are not mutually exclusive
18:20:23 [chaals]: AL: Right...
18:20:39 [chaals]: ... just need to clarify the relationship
18:20:49 [chaals]: RS draws his mind on a whiteboard.
18:21:24 [chaals]: CC: can you have multiple things controlling status?
18:21:26 [chaals]: AL: Sure
18:23:23 [chaals]: RS: Is there some way we can group things together to make it easier to handle multiple related items?
18:23:32 [chaals]: AL: That's up to the author.
18:24:30 [chaals]: ACTION: Aaron to provide text that explains the relationships and how to choose between alert/status/liveRegion/popcorn
18:25:55 [clc4tts]: q+
18:26:05 [clc4tts]: ack me
18:26:17 [chaals]: AL: If there is nothing controlling the status, it's just a liveRegion
18:26:44 [chaals]: CC: What if there are multiple bits of status?
18:26:58 [chaals]: AL: Will have to make them all available
18:27:23 [Zakim]: -Glen_Gordon
18:28:28 [chaals]: RESOLUTION: We use controls so anything which has a status, controls its status area.
18:30:05 [chaals]: RESOLUTION: Multiple items can share a single status area.
18:30:31 [chaals]: s/50, 59/59, 60/
18:44:39 [JohnHrv]: JohnHrv has joined #pf
18:48:54 [aaronlev]: http://developer.mozilla.org/wiki-images/en/8/83/Moz_ffx_openStandards_264x198.jpg
19:07:42 [aaronlev]: 88, 79, 73, 82
19:08:49 [chaals]: Topic: Issues 88, 79, 73, 82
19:10:14 [MichaelC_IAD]: q?
19:10:14 [chaals]: AL: Limiting haspopup to certain roles is a bad idea - should be a universal property. All of our other relations are universal...
19:10:19 [Rich]: q+
19:10:56 [chaals]: ... hasPopup sounds like a boolean - prefer some other name
19:11:00 [Al]: ack Rich
19:11:01 [chaals]: AG: Seen the other culture, but...
19:11:33 [Al]: q+ to ask what is the difference among a popup, a flyout, a tooltip, a submenu
19:11:37 [chaals]: RS: So we can put this on a section. If you are creating an authoring tool, you might have context menus for poperties...
19:11:47 [chaals]: ... do you mean, for *EVERYTHING*?
19:12:12 [chaals]: AL: Effectively - not that you would use it on everything, but we only have limited granularity so that's the way we do that.
19:12:55 [chaals]: RS: Do we need a test case for everything?
19:13:04 [chaals]: AL: Not necessarily
19:13:14 [chaals]: TB: If it is a requirement, then it has to be testable
19:13:22 [chaals]: RS: Do we need a test case for each one?
19:13:42 [chaals]: AL: We can't test every possibility - it is not feasible
19:13:46 [chaals]: q+
19:14:05 [chaals]: RS: We would require it on anything that has a role
19:14:15 [chaals]: s/it/it coud be there/
19:14:26 [chaals]: AL: And things that have no role
19:14:39 [Rich]: a\q?
19:14:41 [Rich]: q?
19:14:51 [MichaelC_IAD]: ack al
19:14:51 [Zakim]: Al, you wanted to ask what is the difference among a popup, a flyout, a tooltip, a submenu
19:15:06 [MichaelC_IAD]: ack c
19:17:01 [chaals]: CMN: It isn't very hard to generate a large range of combinations (use a script and a list of elements). It is unlikely to introduce regressions on many specific cases, so testing can be done reasonably efficiently and effectively...
19:17:18 [chaals]: AG: What is the difference petween popup, flyout, tooltip, submenu?
19:18:16 [chaals]: [discussion - some people have a concept (which varies from person to person), there are some formal schemata e.g. for Windows platform...]
19:19:09 [chaals]: RS: We take id as a value for hasPopup?
19:19:17 [chaals]: AL: Yep. Would rather a boolean
19:19:21 [chaals]: RS: Me too
19:19:31 [chaals]: AL: It is implemented as a boolean in FF now
19:20:05 [chaals]: AG: So use "owns" to say what the thing is?
19:20:08 [chaals]: AL: Yep.
19:21:34 [chaals]: ... so Proposal: Make it universal, boolean, and use "owns" to identify the popup/submenu/foo
19:22:36 [chaals]: AG: Other use case is forward/back button, with a pulldown e.g. for history or more info
19:24:41 [chaals]: ... not sure that we want the submenu etc.
19:24:44 [Zakim]: +Glen_Gordon
19:25:21 [chaals]: AG: The title attribute was meant to be a stand-alone piece of text. But because it was shown as a tool-tip, it was used as somethng dependent on the content it was a title for, rather than being stand-alone
19:25:44 [chaals]: ... rich tooltips are going to take on something of menu functionality - there is a continuum here
19:26:25 [chaals]: AL: Sure. We definitely need "owns" in menu/submenu case. I don't think it is bad to use it in other places, like a tooltip. You don't have to use it if the thing is already a child, of course.
19:26:38 [chaals]: RS: You want to be able to put it on any HTML element.
19:27:03 [chaals]: AL: Yeah - same as we do with a zillion others. We don't have complicated fine-grained control, so we use this approach instead.
19:27:53 [chaals]: RS: Things like this are not showing up in the taxonomy.
19:28:03 [chaals]: AL: Right. There are a bunch of things in that category
19:28:06 [chaals]: RS: OK...
19:29:41 [chaals]: SS: We have elements and popups. Popups are extra stuff you can add to a link - put "hasPopup" and it is good
19:29:51 [chaals]: RS: Would probably want "owns" too
19:30:09 [chaals]: SS: We also have an input - for example to select colours
19:30:16 [Zakim]: +??P1
19:30:21 [chaals]: AL: hasPopup triggers the thing that is owned.
19:30:28 [chaals]: ... which could be anything.
19:30:39 [JohnHrv]: JohnHrv has joined #pf
19:30:56 [chaals]: AG: to distinguish it from something like a mouseover (which is a tooltip)
19:31:05 [chaals]: AL: We can make sure that hasPopup describes that.
19:31:18 [Al]: RRSAgent, pointer?
19:31:18 [RRSAgent]: See http://www.w3.org/2007/04/12-pf-irc#T19-31-18
19:31:23 [chaals]: RS: Mouseover is an explicit user action.
19:31:33 [JohnHrv]: yep, it's me. thanks, michael
19:32:21 [JohnHrv]: ok. thanks, al
19:32:32 [Al]: check the log for details (from RRSAgent response above)
19:33:40 [chaals]: CMN: If you are going to talk about mouseover and something as different, you need to build a complete two-level model. At the moment, my understanding is that hasPopup is only based on one level of user action.
19:34:07 [chaals]: ... you could do this with focus/activate distinction, if yu like... (modulo mouseover == cfocus debates)
19:36:28 [chaals]: [discussion of this - is there a finite set we can describe, or a messy continuum we need to model?]
19:36:49 [Sir]: Sir has joined #pf
19:37:17 [RichS]: RichS has joined #pf
19:38:33 [chaals]: AG: I think there should be a smooth transition from moving to something to activating it. What if you get to something and a submenu flies out - what is the next action?
19:38:55 [chaals]: AL: Yeah, but it turns out that it doesn't work like that...
19:39:14 [chaals]: MC: I hear a difference between tooltips, submenus, and some people are using one as the other
19:39:35 [chaals]: AG: I am predicting that the boundaries are blurring and people will do things along the range
19:39:49 [chaals]: JRG: Those things won't have a title attribute.
19:40:00 [chaals]: AL: A TV show pops up a rich title
19:40:12 [chaals]: RS: But you can't navigate around it.
19:40:15 [chaals]: AL: Yes, you can
19:40:48 [chaals]: JRG: There is a difference between a title attribute-derived tooltip, and doing something with scripting. If you are scritping it, you have to make it work.
19:41:00 [chaals]: AG: Sounds like shifting too much of the burden.
19:41:44 [chaals]: AL: We have a role of description - we could use that for tooltip.
19:42:34 [chaals]: [Oh. We don't have that role anymore]
19:42:43 [chaals]: AL: We do need one like that.
19:43:32 [chaals]: RS: Think that is cleaner
19:43:43 [chaals]: AL: Right. then you don't *have* to have it pop up.
19:44:58 [chaals]: RS: How could you navigate a rich description?
19:45:03 [chaals]: ... with links, etc.
19:45:36 [Al]: q?
19:46:18 [chaals]: SS: a tooltip window should not be confused with something that the author makes pop up.
19:48:21 [Al]: q+
19:48:54 [chaals]: JRG: Seems that you are asking to have the browser make some magic to simulate mouse behaviour to get things
19:49:08 [chaals]: AG: Don't want to ask the author to do it if we can get the user agent to do it.
19:50:17 [chaals]: LS: Can it be the AT providing the access?
19:50:30 [chaals]: AG: Think this is sufficiently basic that this should work at the UA level.
19:51:56 [chaals]: JRG: What about keyboard users without AT?
19:52:08 [chaals]: AG: Exactly: the browser has to provide an activation mechanism
19:52:17 [chaals]: CC: Ditto
19:53:25 [chaals]: CC: We have haspopup, and that is triggered on activate (which is determined by the browser)
19:53:34 [Al]: q?
19:53:38 [Al]: q-
19:53:42 [chaals]: AL: WebAPI is trying to make the parallel between hovering, focussing, etc.
19:54:06 [Al]: Chaals: WebAPI got as far as making 'click' and 'activate' synonyms
19:54:20 [Al]: 'activate' is in players for e.g. SVG
19:54:57 [Al]: With voice command, you can say 'next, next, next, ... click'
19:57:26 [chaals]: CMN: The trick is that we are trying to describe something with two interaction levels - mouseover/focus, or some equivalent. There are zillions of examples of this in the wild...
19:57:38 [chaals]: s/on activate/on activating popup/
19:58:17 [chaals]: ... so we really need to find some way of distinguishing these
19:58:51 [chaals]: AL: Can we do something like rely on the difference between hasPopup and Owns as an activation, with describedBy as the "light touch"
19:59:11 [chaals]: LS: Isn't this just presentational whether it is a mouseover or click?
19:59:47 [chaals]: AG: It is relevant, because the author will make the content according to their perception of how much work it is for the user to activate different kinds of popup, etc.
20:00:15 [chaals]: LS: Not sure. Some people hate mouseover, some love it. Why do I care which method is used on visual rendering?
20:00:29 [chaals]: AG: Because this determines for many authors how they decide which to use
20:00:34 [chaals]: LS: don't think it does.
20:00:46 [chaals]: ... think authors base the decision on focus.
20:01:00 [chaals]: s/focus/looking at what they think the users will do/
20:01:31 [JRG]: CMN: Most authors don't think about focus groups
20:01:56 [JRG]: CMN: Some authors may think about, but most authors think visually and author visually
20:02:15 [JRG]: CMN: There are arbitary implementation decisions
20:02:45 [JRG]: CMN: The basic paradigm ...
20:02:57 [chaals]: CMN: Agree mostly with Al here. What authors see as visual behaviour determines, in large part, how authors understand user interaction.
20:03:36 [chaals]: AL: If an author is using ARIA we should tell them not to rely on hoverable stuff for interaction.
20:05:23 [chaals]: AG: If you want something different to navigate into, that isn't the default action, you need a different way for them to be triggered.
20:05:44 [chaals]: JRG: Authors have a way of doing something. We are looking for markup patterns that match what auhtors actually do.
20:06:10 [chaals]: AL: If authors want a really interactive tooltip and they are looking at ARIA, we should be saying "don't rely on the light touch thing, because users need access.
20:06:22 [chaals]: JRG: The benefit is that this way they will be less useful for everyone.
20:18:44 [leesa]: are you starting again?
20:21:43 [aaronlev]: leesa: in a sec
20:21:51 [leesa]: ok
20:21:58 [leesa]: hello arron!
20:22:13 [Al]: http://maps.google.com/maps?f=l&hl=en&q=restaurant&near=Sterling+VA&layer=&sll=39.006112,-77.428894&sspn=0.144332,0.127373&ie=UTF8&latlng=39032540,-77409610,350449784873436566&ei=wZQeRvPfNY7gqwKb1YGTBA
20:22:26 [aaronlev]: hi leesa !
20:27:07 [Al]: Zakim, who is here?
20:27:07 [Zakim]: On the phone I see Face_to_Face, Lisa_Seeman, Glen_Gordon, John_Hrvatin
20:27:10 [Zakim]: On IRC I see JohnHrv, Stefan, JRG, Al, chaals, MichaelC_IAD, leesa, aaronlev, clc4tts, Rich, MC_Projector, RRSAgent, Zakim
20:30:07 [Rich]: Rich has joined #pf
20:30:31 [Rich]: Al: I still have a heartburn with using described by if it has active elements
20:31:01 [Rich]: Al: I understand you want it to be the author's responsibility to get the user there via the keyboard
20:31:18 [Rich]: aaron: if it is not a description it is a has popop with owns
20:31:41 [Rich]: aaron: it is ok to have previews that are rich
20:31:42 [dpoehlman]: dpoehlman has joined #pf
20:32:01 [Rich]: michael: we need to be clear
20:32:23 [Rich]: al: active elements must be keyboard navigable
20:32:42 [Rich]: aaron: if hte describedby has active elements then you need keyboard navigation to get there
20:33:04 [Rich]: al: we need owns in stead of describedby in that case
20:33:27 [Rich]: aaron: hover may just give you a quick synopsis of the plot
20:34:11 [Rich]: michael: a desciption with role would be a violation
20:35:34 [Rich]: rich: what have 2 pop-ups with active elements
20:35:45 [Rich]: aaron: if activated by a hover should use describedby
20:36:23 [Rich]: aaron: if activated by a discrete trigger then should use haspopup and owns
20:36:42 [Rich]: aaron: tooltips make things more accessible for some people - low vision
20:38:39 [MichaelC_IAD]: q+ charles
20:38:43 [MichaelC_IAD]: q+ jon
20:39:02 [Rich]: aaron: can use describedby for any tooltip even if it has active elements
20:39:15 [Rich]: q?
20:39:24 [MichaelC_IAD]: ack c
20:39:57 [leesa]: last thing i sa was Q
20:39:58 [Rich]: CLC: when you said the light touch you get the title
20:41:16 [Rich]: aaron: describedby is used by anything that is pop-up help
20:41:38 [Rich]: aaron: haspopup is only for things that are triggered by a key click or eneter
20:41:42 [Rich]: s/enenter/enter/
20:43:06 [Rich]: q?
20:43:16 [chaals]: q+ to say title will quietly vanish
20:43:28 [Rich]: q- Jon
20:44:07 [Rich]: chaals: in the fullness of time where ARIA can be used by any case, we are giving you the functionality of title with a richer piece of content
20:44:09 [Al]: q+
20:44:09 [clc4tts]: q+
20:44:20 [MichaelC_IAD]: ack cha
20:44:20 [Zakim]: chaals, you wanted to say title will quietly vanish
20:44:23 [Al]: ack chaals
20:44:24 [Rich]: Stefan: if you don't use title how will you do popup?
20:44:31 [Rich]: q- Al
20:44:45 [Rich]: Stefan: are you saying per element, page, or site
20:45:03 [Rich]: s/Al: Stefan/
20:45:28 [Rich]: aaron: the author will probably want to the minimum markup for what they need
20:45:48 [Rich]: CLS: I don't see this as mutually exclusive
20:46:03 [Rich]: s/CLS/CLC/
20:46:20 [Rich]: CLC: you could use title and describedby in some contexts
20:46:40 [Rich]: Chaals: If you use a tooltip you can use describedby
20:47:02 [Rich]: Chaals: you don't have to use the tooltip if you don't want to
20:47:32 [Rich]: Stefan: title (being popped up) is the default behavior of the browser
20:48:18 [clc4tts]: http://firevox.clcworld.net/tutorial/tut2.html
20:49:11 [aaronlev]: http://www.mozilla.org/access/dhtml/button
20:50:21 [MichaelC_IAD]: q+ to say options aren't mutually exclusive and practice can shake out with experience
20:50:31 [Rich]: q?
20:53:12 [Rich]: use haspopup whenever you have something that can be activated
20:53:17 [leesa]: ok
20:54:24 [Al]: schedule: we will be discussing future F2F schedule tomorrow morning at the beginning of the meeting -- 0900 EDT
20:54:35 [Rich]: lisa: I agree to al's coment
20:55:08 [Rich]: proposal: use po-up and owns to determine the default action
20:55:26 [Rich]: use descirbedby to do something that is passive
20:57:31 [Al]: RS: what do you do if there is a popup and a help on the same base element
20:57:51 [Al]: CMN: example -- base element is "try me"
20:58:12 [Al]: 'help' is HELP
20:58:27 [Al]: 'popup' is MENU
20:58:36 [dpoehlman]: dpoehlman has left #pf
20:58:51 [janina]: janina has joined #pf
20:59:02 [Al]: Tryme hooks to HELP with 'describedby'
20:59:23 [Al]: Tryme hooks to MENU by 'owns' and also asserts 'haspopup'
20:59:52 [Al]: AL: it's up to the author to decide how they afford keyboard navigation to the auxiliary panes.
21:00:21 [Al]: It could be by insertion in the tab order, exposing a hidden hyperlink extending Tryme etc.
21:00:41 [Al]: CMN: Tryme could even be a hyperlin,
21:00:59 [Al]: Tryme has actions:
21:01:09 [Al]: onMouseOver bring up MENU
21:01:18 [Al]: onHelpKey, bring up HELP
21:01:34 [Al]: onClick navigates to href destination
21:02:35 [leesa]: lisa is going to sign out now
21:02:48 [leesa]: but first
21:02:57 [MichaelC_IAD]: MichaelC_IAD has joined #pf
21:03:17 [leesa]: good night
21:03:25 [Zakim]: -Lisa_Seeman
21:03:46 [JohnHrv]: i've gotta run. any additional updat on tomorrow's agenda?
21:04:28 [Al]: no, but we will (including discussing after F2F) try to pack the a.m. with things for you.
21:05:03 [JohnHrv]: ok, cool. 9:00 to 10:30 EDT works fairly well, even if it's early
21:05:39 [JohnHrv]: talk to you all tomorrow
21:05:50 [Zakim]: -John_Hrvatin
21:08:47 [clc4tts]: q+
21:11:51 [MichaelC_IAD]: q-
21:12:11 [MichaelC_IAD]: ack c
21:17:43 [Rich]: rich: group seems to agree that should not tie in light and heavyweight user actions
21:18:54 [Rich]: rich: Proposal is that popup and owns or pop and menu document writes are used to define relationships between an object and a pop-up menu
21:18:54 [chaals]: ping
21:19:49 [chaals]: s/ping//
21:20:07 [Rich]: rich: for tooltip overrides we use describedby to refernce the tooltip description and provide a tooltip role for the actual tooltip
21:21:17 [Rich]: aaron: the author should be responsible for the keybindings
21:21:33 [Zakim]: -Glen_Gordon
21:29:54 [Rich]: Resolution: haspopup is a boolean which indicates that the object has a popup menu which may be rendered using document writes for the menu as a descendents of the object or through the use of styling in which case the relationship to the pop-up menu is established using owns
21:30:11 [Rich]: Resolution: Group agrees to have a tooltip and description role
21:30:29 [Rich]: resolution: description means you have a description but it is not used as a tooltip
21:30:56 [Rich]: Resolution: a tooltip may be used as a tooltip for the object
21:31:16 [Rich]: Resolution: if the tooltip has active elements it must be keyboard navigable
21:32:00 [JRG]: JRG has joined #pf
21:40:14 [aaronlev]: a pop-up window that displays a description of an element when the user visits that element
21:41:04 [aaronlev]: a popup that displays a description of an element when the user visits that element
21:42:45 [aaronlev]: or A tooltip is a small box that appears near an object in a graphical user interface (GUI) when a pointer or other cursor controlled by a mouse passes over or rests on that object and which contains a brief text message identifying or explaining the object.
21:44:19 [aaronlev]: A popup that displays a description for an element when a user passes over or rests on that object
21:44:51 [aaronlev]: A popup that displays a description for an element when a user passes over or rests on that element
21:48:38 [Al]: Zakim, bye
21:48:38 [Zakim]: leaving. As of this point the attendees were Glen_Gordon, +1.206.728.aaaa, Face_to_Face, Lisa_Seeman, John_Hrvatin, John_Hrvatin?
21:48:38 [Zakim]: Zakim has left #pf
21:48:49 [Al]: RRSAgent, draft minutes
21:48:49 [RRSAgent]: I have made the request to generate http://www.w3.org/2007/04/12-pf-minutes.html Al