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