13:59:45 RRSAgent has joined #pf 13:59:45 logging to http://www.w3.org/2007/01/23-pf-irc 14:00:29 RRSAgent, make log member 14:00:35 Zakim has joined #pf 14:00:40 Zakim, this is WAI_P 14:00:40 Al, I see WAI_PFWG(f2f-at-MgM)9:00AM in the schedule but not yet started. Perhaps you mean "this will be WAI_P". 14:00:54 Zakim, this will be WAI_P 14:00:54 ok, Al; I see WAI_PFWG(f2f-at-MgM)9:00AM scheduled to start now 14:01:06 Zakim, code? 14:01:06 the conference code is 92473 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Al 14:02:42 WAI_PFWG(f2f-at-MgM)9:00AM has now started 14:02:49 +MIT531 14:11:13 +??P8 14:12:12 n has joined #pf 14:12:29 Zakim, ??P8 is leesa 14:12:41 +leesa; got it 14:13:45 agenda+ scribing rotation for today 14:13:46 n_ has joined #pf 14:14:05 becka11y has joined #pf 14:14:15 MichaelC has joined #pf 14:15:10 Linda has joined #pf 14:18:11 becka11y has left #pf 14:18:48 Rich has joined #pf 14:20:11 janina has joined #pf 14:20:25 scribing rotation for today: janina, Rich, Michael, Becky 14:20:31 scribe: Janina 14:20:53 meeting: PF F2F at Jan 2007 MGM, day 1 14:20:55 chair: Al 14:23:16 -leesa 14:23:34 janina 2 mins: FSG is now Linux Foundation after merger with OSDL 14:24:27 +??P5 14:24:29 rich: talked with linux foundation ceo, will continue to support other initiatives like iaccessible2, other platforms 14:24:58 michael: working on "future of web a11y" presentation for paris conference next week 14:25:07 becka11y has joined #pf 14:25:36 michael: including need for tools to transparently support aria 14:25:57 michael: also testing caucus this wednesday 14:26:32 becky: very focussed on dojo, trying for 1.0 release in the summer, and wants it to be accessble 14:28:19 aaron: working to find funding for another developer and to extend other firefox developer's funding 14:29:29 the line is terible 14:29:41 aaron: aaron: has new test cases for live regions 14:30:05 aaron: will be demo'd at csun 14:30:13 linda: studying aria for this meeting 14:30:34 linda: doesn't see any major issues to support aria 14:30:51 linda: thinks will be supported 14:31:09 Zakim, who is here? 14:31:11 On the phone I see MIT531, ??P5 14:31:14 On IRC I see becka11y, janina, Rich, Linda, MichaelC, n, Zakim, RRSAgent, Al, DaveP 14:33:41 al: asat in with voice browser and with uawg. 14:34:00 al: voice browser so very different, 3 levels of refinement 14:34:55 al: have extensive diagrams of dom3 that emmulate vxml2 -- impressive uml diags 14:36:09 al: renewed my interest in state chart xml as mechanism for talking about building things 14:38:08 rich: intro 14:38:17 rich: how to deal with multi column lists and tree views 14:38:24 rich: grid with two nav modes 14:38:30 aaronlev has joined #pf 14:38:39 rich: up/down and the other that plus expand/collapse 14:38:54 rich: so stay with grid role and define nav model 14:39:18 rich: allows browser to map 14:39:30 rich: we think dave pawson is ok with this?? 14:39:38 dave, are you there? 14:40:05 Jon Gunderson's grid list 14:40:07 http://cita.uiuc.edu/software/mozilla/test/dhtml/grid/grid-1.html 14:41:09 rich: proposing default up/down with expand/collapse 14:41:19 al: up/down select a row--you get a highlight 14:41:28 rich: different from use cases i've seen on list 14:41:38 becky: this is like web mail 14:42:04 becky: so as you move row to row, the info you've asked for is spoken in that row, but you can still go cell to cell (left/right) 14:43:28 rich: we can't do the cells in desktop apps, just the rows 14:44:35 rich: we should put out to nav by cells, and would do trees--press enter to expand 14:44:46 rich: we have level support in aria 14:45:01 al: we have only two levels in html tables 14:45:03 q+ to say a tree typically uses arrow keys to open/close; will need to consider the expected UI (not that that necessarily affects ARIA properties) 14:45:33 al: persistent row is the headers--and that's a use case 14:45:40 rich: so, a more complex example 14:46:00 More complex examples: 14:46:02 http://turboajax.com/demos/grid3/ 14:46:54 rich: so we still have cells, but when expanded we get a sub table 14:47:51 rich: so, should we look at how daisy would handle this? 14:48:15 rich: do we give direction on how to address navigation? 14:48:36 al: I'd like ti go by queue ... 14:48:52 q- 14:49:38 rich: so, first i need to know that something has expanded, and i want to know what it is before I nave into it 14:49:48 q+ 14:49:51 rich: do we indicate to users through properties 14:50:52 al: the critical unit includes header and details of one topic 14:51:13 al: so, logically it's like tabs on the left 14:51:45 becky: tab panel? 14:51:47 al: yes 14:52:16 al: highly orthodox re the daisy model 14:52:36 al: daisy says you can nav to peers or drill down into the internal structure 14:54:14 rich: but we don't do table nav like this today? 14:54:20 al: yes, but you can do tree nav 14:54:42 al: an attribute to id arc ties description to the title 14:54:48 rich: is that too expensive 14:54:56 becky: not bad. it's all there 14:55:14 becky: we're not adding text, just ids 14:55:39 becky: so what about the second example? 14:56:01 lisa: so we had the idea that tables could be linearized 14:56:34 lisa: so if you imaged not table 14:56:47 lisa: so in complex tables you'd just repeat lower and lower titles 14:58:30 lisa: so you can scan through the sections, then choose to hear details with some action like spacebar 14:58:48 lisa: i think it's the right nav 14:59:40 al: so we could have presented these examples as topic trees, show them unrolled 14:59:58 al: these appear to have canonical toc tree, even though presented as grids 15:00:52 rich: i'm concerned this doesn't match what's in guis today 15:01:05 +Dave_Pawson 15:01:24 Dave P back on line 15:01:34 becky: well it does, because click a node, it adds more rows in a lotus prototype in our dojo work 15:02:37 dave: this is a conversation i've had with rich on line 15:02:52 dave: i'M concerned about mixed vocabulary 15:03:35 dave: i see you're trying to use expansion to analogy with how windows expands trees 15:03:45 dave: difference with daisy 15:04:00 dave: so can we careful circumscribe our def of "tree" 15:04:50 rich:, so don't say tree, just explain the properties we have when the widget is expanded 15:06:15 lisa: i agree, trees, grids, tables, are just visual representations of what may well be the same thing, same data 15:06:35 My contention is that tree based data is not the same as table based data. 15:06:38 lisa: reason to keep them separate is so people understand they're supported 15:06:46 I don't think they should be mixed in terminology. 15:06:56 q+ to say that in "Al-speak" we now have three proposals that are "mathematically equivalent". Just need to acknowledge their equivalence, choose our own terms, and know we'll be mapping them to other things 15:07:16 +1 MichaelC 15:07:43 lisa: i do think you could make any one of these using headers 15:08:08 dave: agree except for word "tree" 15:08:29 dave: tree is only for where there is expanded or collapsed content 15:08:59 rich: so if we deal with properties ... 15:09:10 al: it's the age old issue of nestedd containers 15:09:21 al: and each nest should have a heading 15:09:46 http://turboajax.com/demos/grid3/ 15:11:42 rich: where have the additional rows gotten their headers? 15:11:50 michael: is it contained by something? 15:12:04 dave: no, question is do we have actual tree data? 15:12:25 michael: i'm guessing implementation is probably wrong, but we care about the use case 15:12:36 al: yes, in life it's probably sql data 15:13:00 dave is there benefit in wrapping the data? 15:13:10 al: yes, low vision, motor for fewer key strokes 15:13:30 dave: so, it's genuine tabular data, even though presented almost in tree 15:14:08 al: this is where we need a concrete prposal 15:14:20 al: two patterns both match the collection of data, and we allow the user to choose 15:14:45 dave: does the word "wrapped" help? that how it appears to me 15:14:48 al: yes 15:14:53 becky: no 15:15:04 al: product id could have been a product to the right? 15:15:09 becky: and you would repeat 15:15:18 al: no, it's one order 15:15:53 al: manifest ... manifest is a peer of product id 15:16:15 dave: is the source data is purely tabular then you can't use the term subtable without overloading the term 15:16:45 al: yes, but if you say the first is "manifest," manifest would contain additional items which are tabular collections of data 15:16:55 al: i meant the collection of rows 15:18:26 dave: ok, i came out of a meeting and i think my point is made 15:18:34 -Dave_Pawson 15:18:50 rich: yes, you want to address properties that don't associate with list or 15:18:52 ack m 15:18:52 MichaelC, you wanted to say that in "Al-speak" we now have three proposals that are "mathematically equivalent". Just need to acknowledge their equivalence, choose our own terms, 15:18:56 ... and know we'll be mapping them to other things 15:19:06 rich; so onceyou expand, how does one step in 15:19:30 rich: for each given cell, i like explicitly setting the described by -- and it's faster for the at 15:19:35 al: may be how it's done 15:19:44 rich: then you don't care whether it's a table or not 15:19:55 al: could be divs and spans and css layout 15:20:14 al: if we get the specs in sploace, it can be appropriately navigated 15:20:29 becky: from the ml point of view, you gain some navigation if you present as tables 15:21:15 al: so you should use id, and th, and only our new described by when the older ml doesn't serve 15:21:46 michael: we should check whether putting aria onto div/span gives us a full mapping 15:21:59 al: same question, can we get implementers to build that way 15:22:03 ichael: is that our goal 15:22:14 becky: and at performance is another question we need to answer 15:22:54 rich: we could use the same arrow nav 15:23:00 janina: yes, just in a different voice 15:23:04 \me taking a muinit brake 15:24:02 al: so what's the diff between a grid and a table? in a grid you can go right, then down, then left and then up and come back to where you started, can't do that in a table 15:25:55 michael: we don't need to worry about the ui so much 15:26:06 al: yes, but we need to make sure the ml supports all models of interaction 15:26:56 linda: from the ua pov, there's no design problem 15:27:14 rich: we just need to make sure we have the appropriate properties so the user doesn't get lost 15:30:09 rich: so do we agree on expandable property on row cell? 15:30:15 agreement 15:30:51 rich: i think we need some notion of a level 15:30:56 al: should it be computed 15:31:03 rich: it's a lot of work 15:31:08 al: but the authors will get it wrong 15:31:22 lisa: we have level 15:31:30 al: but not an integer an tuhor writes 15:31:40 aaron: yes, we can write it or calculate it 15:31:54 aaron: only the server knows, not the ua 15:32:56 aaron: my concern is that msaa and at-spi deal with trees very differently 15:33:46 aaron: we don't want to break people's expectations today 15:34:13 aaron: so we could have children of a tree item to give the same nav experience 15:35:08 aaron: currently atk doesn't expose the container for row objects 15:48:08 scribe: Rich 15:49:04 test 15:49:15 Tree grids 15:49:17 ATK: 15:49:19 ROLE_TREE_TABLE (supports Table interface) 15:49:21 - keycell cell cell cell cell cell 15:49:22 - keycell cell cell cell cell cell 15:49:24 - keycell cell cell cell cell cell 15:49:26 - keycell cell cell cell cell cell 15:49:27 - keycell cell cell cell cell cell 15:49:29 The key cell holds states, relations and fires events 15:49:30 Uses RELATION_NODE_CHILD_OF to imply depth, by pointing to another keycell 15:49:32 MSAA 15:49:33 ROLE_TABLE 15:49:35 - treeitem 15:49:37 - treeitem 15:49:38 - treeitem 15:49:40 - treeitem 15:49:41 - treeitem 15:49:43 Cells are not indivudually exposed. The name of each tree item is a contatenated verison of everything. 15:49:44 The description field is overriden to provide level and position info (this is a hack) 15:49:46 In IA2 we have the positionInGroup() method to return that info and avoid the description hack. 15:49:48 Proposal: 15:49:50 Combine the two, so mostly backward compatible 15:49:51 ROLE_TREE_TABLE -- Supports Table interface 15:49:52 - treeitem, can have table cell children 15:49:54 - treeitem, can have table child 15:49:56 - treeitem 15:49:58 - treeitem 15:50:00 - treeitem 15:50:02 Each table cell can implement the Text interface or have children that describe it's contents, 15:50:04 such as checkbox, image, progressmeter, button 15:50:37 aaron: ATK every cell is the tile of a table 15:51:00 aaron: there is no row to get focus 15:51:17 rich: you have activedescendant 15:51:35 aaron: yes, but the activedescendent is the first cell of reach row 15:52:05 aaron: There is no container object for a row 15:52:31 aaron: the way that you show depth is that the key row of a cell supports an ischildof 15:52:58 rich: this is a mess 15:53:06 aaron: it is terrible 15:53:27 s/tile/child 15:53:28 aaron: in Mozilla we implement both MSAA/IA2 and ATK 15:54:04 aaron: encapsulation by container is more efficient 15:54:14 s/aaron/Al/ 15:54:29 Al: It only goes as far as the key cells. 15:54:34 aaron: I did not follow 15:54:43 aaron: this is limiting because it is flat 15:54:59 Al: other than the keycells may have a grandchild relationship 15:55:13 aaron: they have no natural children - they are adopted 15:55:33 Al: You could mark up rich's examples with the summary and details at some depth 15:56:06 Al: in the topic with the childofs. You don't have a vehicle to define what range of cells have the focus. 15:56:20 aaron: msaa is also flat. There is a role of tree. 15:57:27 Aaron: you have to override the description field 15:57:51 Aaron: In IA2 you have the notion of positioningroup 16:01:19 Aaron: What IAccessible2 has is a container for each row in the tree and events/properties go on the row 16:01:36 Aaron: What is missing is individual objects for the cells 16:01:57 s/IAccesible2/MSAA/ 16:02:07 Aaron: ATK is the exact inverse 16:02:19 Rich: the way ATK implements it is the inverse 16:02:28 Rich: there is no container object for the rows 16:02:41 Aaron: we are lucky that they are the inverse 16:03:18 Rich: don't think IE is just going to use MSAA 16:03:30 Linda: true. UIA would be the route we are looking at 16:03:45 Aaron: I think we should harmonize the apis with tree grids 16:04:01 Aaron: the grand children are the cells 16:05:14 Aaron: There is a way to harmonize this with row children and cell grandchildren and the table interface on the top object 16:05:31 Al: Does the table interface provide for next row navigation? 16:06:10 Aaron: you need both the row and the cell objects 16:07:00 Aaron: I am proposing that we have all those objects 16:07:07 Al: Let me try to summarize. 16:07:38 Al: From your looking at the API bindings the logical way to keep the API binding software from going nuts that we follow the model that we were following 16:07:46 dpoehlman has joined #pf 16:07:56 Al: If we do each API differently we will have a problem 16:08:29 Aaron: I would like to define the proper vehicle which is backward compatible 16:09:09 See http://www.w3.org/2007/01/23-pf-irc#T16-08-29 16:09:42 Al: should we do an example? 16:11:02 Aaron: we need to ensure we supply row and cell information within the markup 16:11:43 Al: do we need a property of atomic for table rows to supply the entire information to the users 16:12:09 Al: the keystrokes go to the focus cell but css properties go on the entire TR to show and hide 16:12:41 Aaron: that is a problem. You would have focus events going to cells but in this API focus should go to the cell 16:12:55 s/the cell/the row/ 16:13:15 Al: teach me. In historical HTML containers never get focus 16:13:29 Al: in the HTML spec it does not have focus for IFrames 16:14:19 Al: I am just saying that part of this confusion is Jon gave the behavior of different browsers. 16:15:09 Al: You are telling me that in the UI that IFrames do get focus 16:15:27 Aaron: yes, because you would need to scroll it 16:15:40 Rich: sure. It is like a new web page 16:15:58 Aaron: If visually on the screen there should be a container object that gets focus 16:16:37 Becky: I can handle when a cell gets focus I really want the row to get focus visually 16:17:20 Becky: Except when a particular cell gets focus then the entire row gets focus but if I go to a differenct cell then if it is not consistent I have issues 16:17:36 Linda: Everything has a layout which is focusable 16:18:08 Linda: If I have table it is focusable via script 16:18:56 Al: Different browsers handled onblur differently 16:19:06 Linda: onblur is a different subject 16:19:36 Rich: Trying to summarize 16:20:21 1. In the markup we need to delineate cells and rows 16:21:32 2. If there are column and row headers and markup is not explicit (uses HTML tables) then each cell should provid a labelledby property 16:25:34 3. Expandable/collapsible rows should support the expanded property 16:26:32 4. Selected should be supported on cells or rows 16:29:10 s/should be supported/may be provided/ 16:29:35 s/rows should support/rows may provide/ 16:30:24 5. Checked may be provided on cells or rows 16:54:43 6. For a dynamic expandable grid (not all has been loaded at once) the author should supply posinset, level, setsize on each table row 16:57:13 7. For a preloaded expandable grid (all rows loaded) the author should supply (posinset, setsize, level) or owns for each row. 16:57:52 Note: 6 and 7 refer to mult-column grids 17:11:46 8. note: 6 and 7 also refer to single column grids 17:12:30 dpoehlman has left #pf 17:13:11 -??P5 17:13:13 Lunch break 17:23:41 http://turboajax.com/demos/grid3/ 17:41:29 +??P0 18:07:37 scribe: Michael_Cooper 18:07:41 scribeNick: MichaelC 18:09:20 rs: put something in that navigation by row and by cell? 18:10:54 ag: CG explored having defined "grid" navigation where the four arrow keys have specific behaviors 18:11:14 ... compare to DAISY where using the arrow keys in a cycle doesn't necessarily get you in the same place 18:11:38 ... need to support 2-d navigation off layout, and off tree 18:11:46 ... user needs to know which is being used 18:12:42 ... believe user should always be able to force into a particular mode 18:13:00 ... but script might not support it; AT needs to 18:13:18 rs: need to be able to go up and down topic tree 18:13:33 ag: in simple table, that's table, row, cell 18:13:48 ... as the three available levels 18:14:41 ... master-detail table at http://turboajax.com/demos/grid3/ is not a simple table 18:15:05 ... have row and cell navigation, and use for expand-collapse 18:15:21 ... don't use left/right arrows for expand/collapse because that's used for cell navigation 18:16:51 js: should be able to move to a column, then move up and down rows with focus staying in that column 18:20:53 al: in such a use case, wlil read the cell even though focus moving to row (reads the delta of the selection) 18:22:15 rs: question of focusing whole row, or just the cell 18:22:23 al: depends on editable, interactive, etc. 18:22:35 rs: how does user know what situation is when they land on it 18:22:41 js: AT needs to indicate 18:23:15 al: usually indicates 18:23:37 ... but navigation may depend on whether you're in an expandable/collapsable row or not 18:24:00 rs: prefer right/left arrow just for cell navigation 18:25:39 dp: if you move to either end of row, you're put in cell navigation; if you're in a row sticks in row 18:26:02 ag: prefer up/down arrow be row; right/left be cell 18:27:06 bg: how do you know how to navigate? 18:27:16 js: AT have specific ways to support 18:27:33 al: no standard way, you have to know the possibilities 18:27:37 ... we don't know the best way yet 18:28:04 ... we define the background markup, but others figure out the navigation 18:28:51 ... most of this is techniques 18:29:03 ... enter to enter cell mode, escape to exit 18:29:08 ag: prefer overflow the row mode 18:29:35 ... escape key should be left to OS 18:30:34 rs: specify cell navigation as default, but can override? 18:31:03 s/but can/but author can 18:32:06 ... concern that we know we have all the properties we need 18:32:15 al: we've got everything 18:33:34 rs: what do I do to switch from row to cell navigation 18:33:43 mc: leave that to AT/UA 18:33:50 ag: we need a consistent feel 18:34:25 ... we need to provide a document, but not required, keyboard navigation 18:34:35 s/document,/documented,/ 18:34:52 al: enter good way to enter children, and escape good way to return to parent 18:35:55 18:36:41 al: issue of whether in row or cell navigation handled by UA because either container or child has focus and AT reports which 18:36:48 cyns has joined #pf 18:36:58 18:37:50 mkaneko has joined #pf 18:40:23 continuing previous list 18:40:29 9. issue of whether in row or cell navigation handled by UA because either container or child has focus and AT reports which 18:40:36 Zakim, who is here? 18:40:36 On the phone I see MIT531, ??P0 18:40:37 On IRC I see mkaneko, cyns, aaronlev, becka11y, janina, Rich, Linda, MichaelC, n, Zakim, RRSAgent, Al 18:41:06 10. use of enter and escape is to go down and up level, respectively 18:42:36 s/enter and escape is/predefined keys 18:43:45 11. need to establish a common key convention to go down a level, and up a level. Discussion of enter and escape for those functions, but concerns about overloading 18:45:09 topic: Multilevel menus 18:45:19 +??P7 18:47:08 -??P0 18:48:03 ag: can have arbitrarily nested menus 18:48:16 ... want to ensure we have the needed ways to spec 18:49:42 bg: when get to a menu item that has submenu options 18:49:54 ... do you end up in the child menu automatically? 18:49:59 ... or explicitly open it? 18:50:18 dp: would like to first explicitly open the menu 18:50:25 ... or have option to skip 18:50:35 ... if open, can go into to start exploring the options 18:51:41 bg: want to avoid extra keystrokes 18:51:47 al: have "expanded" 18:51:58 ... but not on combobox 18:54:32 mc: expect to be able to open submenus on demand 18:54:46 bg: how do you know you can? 18:55:05 al: visual arrow, which represents the "haspopup" property 18:55:14 ag: making it very treelike 18:57:03 bg: but we're agreeing it's not exactly a tree 18:57:23 ag: use "menu" with "haspopup" 18:59:11 bg: unsure how to open submenu 18:59:24 action: Becky and Aaron to revisit multilevel menus 19:08:49 Rich has joined #pf 19:09:48 scribe: becka11y 19:10:21 topic: sitebuilder / Cynthia Shelly feedback 19:10:47 based on feedback sent to the public list - Cynthia will give oral overview 19:11:05 cs: conflicts between aria and html semantics 19:11:28 cs: concerned with interaction between built in html roles and aria 19:11:54 cs: concerned avail of aria will encourage dev. to create non-semantic html 19:12:15 cs: which will prevent older /other tools that don't support aria from working correctly 19:12:35 cs: already much div soup on the web with styled divs rather than semantic markup 19:13:13 cs: for ex: using a div and marking up as text input rather than using input element 19:13:45 cs: what about changing the role of an exising html element - marking an input as a list 19:14:29 cs: exp. has been that very good devs don't do a very good job of determining the correct roles 19:14:51 cs: there are some controls that could go either way - is it a menu or a tree? end up with inconsistencies 19:15:20 q+ 19:15:28 ack n 19:15:38 dpoehlman has joined #pf 19:16:04 rs: I think that devs will do div soup, etc whether aria is there or not 19:17:15 rs: need to be explicit that if html element is avail it should be used as it is defined 19:17:30 q+ 19:17:51