PF F2F at Jan 2007 MGM, day 1
23 Jan 2007

See also: IRC log


Al_Gilman, Linda_Mao, Aaron_Leventhal, Becky_Gibson, Michael_Cooper, Rich_Schwerdtfeger, Janina_Sajka, Dave_Poehlman, Don_Evans, Lisa_Seeman, Tim_Boland, Dave_Pawson, Cynthia_Shelly, Masahiko_Koneko
Janina, Rich, Michael_Cooper, becka11y, aaronlev




<Al> scribing rotation for today: janina, Rich, Michael, Becky

<Al> scribe: Janina

<Al> janina 2 mins: FSG is now Linux Foundation after merger with OSDL

rich: talked with linux foundation ceo, will continue to support other initiatives like iaccessible2, other platforms

michael: working on "future of web a11y" presentation for paris conference next week
... including need for tools to transparently support aria
... also testing caucus this wednesday

becky: very focussed on dojo, trying for 1.0 release in the summer, and wants it to be accessble

aaron: working to find funding for another developer and to extend other firefox developer's funding

<n> the line is terible

aaron: aaron: has new test cases for live regions
... will be demo'd at csun

linda: studying aria for this meeting
... doesn't see any major issues to support aria
... thinks will be supported

al: asat in with voice browser and with uawg.
... voice browser so very different, 3 levels of refinement
... have extensive diagrams of dom3 that emmulate vxml2 -- impressive uml diags
... renewed my interest in state chart xml as mechanism for talking about building things

rich: intro
... how to deal with multi column lists and tree views
... grid with two nav modes
... up/down and the other that plus expand/collapse
... so stay with grid role and define nav model
... allows browser to map
... we think dave pawson is ok with this??

dave, are you there?

<Rich> Jon Gunderson's grid list

<Rich> http://cita.uiuc.edu/software/mozilla/test/dhtml/grid/grid-1.html

rich: proposing default up/down with expand/collapse

al: up/down select a row--you get a highlight

rich: different from use cases i've seen on list

becky: this is like web mail
... 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)

rich: we can't do the cells in desktop apps, just the rows
... we should put out to nav by cells, and would do trees--press enter to expand
... we have level support in aria

al: we have only two levels in html tables
... persistent row is the headers--and that's a use case

rich: so, a more complex example

<Rich> More complex examples:

<Rich> http://turboajax.com/demos/grid3/

rich: so we still have cells, but when expanded we get a sub table
... so, should we look at how daisy would handle this?
... do we give direction on how to address navigation?

al: I'd like ti go by queue ...

rich: so, first i need to know that something has expanded, and i want to know what it is before I nave into it
... do we indicate to users through properties

al: the critical unit includes header and details of one topic
... so, logically it's like tabs on the left

becky: tab panel?

al: yes
... highly orthodox re the daisy model
... daisy says you can nav to peers or drill down into the internal structure

rich: but we don't do table nav like this today?

al: yes, but you can do tree nav
... an attribute to id arc ties description to the title

rich: is that too expensive

becky: not bad. it's all there
... we're not adding text, just ids
... so what about the second example?

lisa: so we had the idea that tables could be linearized
... so if you imaged not table
... so in complex tables you'd just repeat lower and lower titles
... so you can scan through the sections, then choose to hear details with some action like spacebar
... i think it's the right nav

al: so we could have presented these examples as topic trees, show them unrolled
... these appear to have canonical toc tree, even though presented as grids

rich: i'm concerned this doesn't match what's in guis today

<DaveP> Dave P back on line

becky: well it does, because click a node, it adds more rows in a lotus prototype in our dojo work

dave: this is a conversation i've had with rich on line
... i'M concerned about mixed vocabulary
... i see you're trying to use expansion to analogy with how windows expands trees
... difference with daisy
... so can we careful circumscribe our def of "tree"

rich: , so don't say tree, just explain the properties we have when the widget is expanded

lisa: i agree, trees, grids, tables, are just visual representations of what may well be the same thing, same data

<DaveP> My contention is that tree based data is not the same as table based data.

lisa: reason to keep them separate is so people understand they're supported

<DaveP> I don't think they should be mixed in terminology.

<DaveP> +1 MichaelC

lisa: i do think you could make any one of these using headers

dave: agree except for word "tree"
... tree is only for where there is expanded or collapsed content

rich: so if we deal with properties ...

al: it's the age old issue of nestedd containers
... and each nest should have a heading

<becka11y> http://turboajax.com/demos/grid3/

rich: where have the additional rows gotten their headers?

michael: is it contained by something?

dave: no, question is do we have actual tree data?

michael: i'm guessing implementation is probably wrong, but we care about the use case

al: yes, in life it's probably sql data

dave is there benefit in wrapping the data?

al: yes, low vision, motor for fewer key strokes

dave: so, it's genuine tabular data, even though presented almost in tree

al: this is where we need a concrete prposal
... two patterns both match the collection of data, and we allow the user to choose

dave: does the word "wrapped" help? that how it appears to me

al: yes

becky: no

al: product id could have been a product to the right?

becky: and you would repeat

al: no, it's one order
... manifest ... manifest is a peer of product id

dave: is the source data is purely tabular then you can't use the term subtable without overloading the term

al: yes, but if you say the first is "manifest," manifest would contain additional items which are tabular collections of data
... i meant the collection of rows

dave: ok, i came out of a meeting and i think my point is made

rich: yes, you want to address properties that don't associate with list or

<Zakim> 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,

rich; so onceyou expand, how does one step in

rich: for each given cell, i like explicitly setting the described by -- and it's faster for the at

al: may be how it's done

rich: then you don't care whether it's a table or not

al: could be divs and spans and css layout
... if we get the specs in sploace, it can be appropriately navigated

becky: from the ml point of view, you gain some navigation if you present as tables

al: so you should use id, and th, and only our new described by when the older ml doesn't serve

michael: we should check whether putting aria onto div/span gives us a full mapping

al: same question, can we get implementers to build that way

ichael: is that our goal

becky: and at performance is another question we need to answer

rich: we could use the same arrow nav

janina: yes, just in a different voice

<n> \me taking a muinit brake

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

michael: we don't need to worry about the ui so much

al: yes, but we need to make sure the ml supports all models of interaction

linda: from the ua pov, there's no design problem

rich: we just need to make sure we have the appropriate properties so the user doesn't get lost
... so do we agree on expandable property on row cell?


rich: i think we need some notion of a level

al: should it be computed

rich: it's a lot of work

al: but the authors will get it wrong

lisa: we have level

al: but not an integer an tuhor writes

aaron: yes, we can write it or calculate it
... only the server knows, not the ua
... my concern is that msaa and at-spi deal with trees very differently
... we don't want to break people's expectations today
... so we could have children of a tree item to give the same nav experience
... currently atk doesn't expose the container for row objects

<Rich> scribe: Rich


<aaronlev> Tree grids

<aaronlev> ATK:

<aaronlev> ROLE_TREE_TABLE (supports Table interface)

<aaronlev> - keycell cell cell cell cell cell

<aaronlev> - keycell cell cell cell cell cell

<aaronlev> - keycell cell cell cell cell cell

<aaronlev> - keycell cell cell cell cell cell

<aaronlev> - keycell cell cell cell cell cell

<aaronlev> The key cell holds states, relations and fires events

<aaronlev> Uses RELATION_NODE_CHILD_OF to imply depth, by pointing to another keycell

<aaronlev> MSAA

<aaronlev> ROLE_TABLE

<aaronlev> - treeitem

<aaronlev> - treeitem

<aaronlev> - treeitem

<aaronlev> - treeitem

<aaronlev> - treeitem

<aaronlev> Cells are not indivudually exposed. The name of each tree item is a contatenated verison of everything.

<aaronlev> The description field is overriden to provide level and position info (this is a hack)

<aaronlev> In IA2 we have the positionInGroup() method to return that info and avoid the description hack.

<aaronlev> Proposal:

<aaronlev> Combine the two, so mostly backward compatible

<aaronlev> ROLE_TREE_TABLE -- Supports Table interface

<aaronlev> - treeitem, can have table cell children

<aaronlev> - treeitem, can have table child

<aaronlev> - treeitem

<aaronlev> - treeitem

<aaronlev> - treeitem

<aaronlev> Each table cell can implement the Text interface or have children that describe it's contents,

<aaronlev> such as checkbox, image, progressmeter, button

aaron: ATK every cell is the child of a table
... there is no row to get focus

rich: you have activedescendant

aaron: yes, but the activedescendent is the first cell of reach row
... There is no container object for a row
... the way that you show depth is that the key row of a cell supports an ischildof

rich: this is a mess

aaron: it is terrible
... in Mozilla we implement both MSAA/IA2 and ATK

Al: encapsulation by container is more efficient
... It only goes as far as the key cells.

aaron: I did not follow
... this is limiting because it is flat

Al: other than the keycells may have a grandchild relationship

aaron: they have no natural children - they are adopted

Al: You could mark up rich's examples with the summary and details at some depth
... in the topic with the childofs. You don't have a vehicle to define what range of cells have the focus.

aaron: msaa is also flat. There is a role of tree.
... you have to override the description field
... In IA2 you have the notion of positioningroup
... What IAccessible2 has is a container for each row in the tree and events/properties go on the row
... What is missing is individual objects for the cells


Aaron: ATK is the exact inverse

Rich: the way ATK implements it is the inverse
... there is no container object for the rows

Aaron: we are lucky that they are the inverse

Rich: don't think IE is just going to use MSAA

Linda: true. UIA would be the route we are looking at

Aaron: I think we should harmonize the apis with tree grids
... the grand children are the cells
... There is a way to harmonize this with row children and cell grandchildren and the table interface on the top object

Al: Does the table interface provide for next row navigation?

Aaron: you need both the row and the cell objects
... I am proposing that we have all those objects

Al: Let me try to summarize.
... 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
... If we do each API differently we will have a problem

Aaron: I would like to define the proper vehicle which is backward compatible

Al: should we do an example?

Aaron: we need to ensure we supply row and cell information within the markup

Al: do we need a property of atomic for table rows to supply the entire information to the users
... the keystrokes go to the focus cell but css properties go on the entire TR to show and hide

Aaron: that is a problem. You would have focus events going to cells but in this API focus should go to the row

Al: teach me. In historical HTML containers never get focus
... in the HTML spec it does not have focus for IFrames
... I am just saying that part of this confusion is Jon gave the behavior of different browsers.
... You are telling me that in the UI that IFrames do get focus

Aaron: yes, because you would need to scroll it

Rich: sure. It is like a new web page

Aaron: If visually on the screen there should be a container object that gets focus

Becky: I can handle when a cell gets focus I really want the row to get focus visually
... 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

Linda: Everything has a layout which is focusable
... If I have table it is focusable via script

Al: Different browsers handled onblur differently

Linda: onblur is a different subject

Rich: Trying to summarize

1. In the markup we need to delineate cells and rows

2. If there are column and row headers and markup is not explicit (uses HTML tables) then each cell should provid a labelledby property

3. Expandable/collapsible rows may provide the expanded property

4. Selected may be provided on cells or rows

5. Checked may be provided on cells or rows

6. For a dynamic expandable grid (not all has been loaded at once) the author should supply posinset, level, setsize on each table row

7. For a preloaded expandable grid (all rows loaded) the author should supply (posinset, setsize, level) or owns for each row.

Note: 6 and 7 refer to mult-column grids

8. note: 6 and 7 also refer to single column grids

Lunch break


<MichaelC> scribe: Michael_Cooper

<MichaelC> scribeNick: MichaelC

rs: put something in that navigation by row and by cell?

ag: CG explored having defined "grid" navigation where the four arrow keys have specific behaviors
... compare to DAISY where using the arrow keys in a cycle doesn't necessarily get you in the same place
... need to support 2-d navigation off layout, and off tree
... user needs to know which is being used
... believe user should always be able to force into a particular mode
... but script might not support it; AT needs to

rs: need to be able to go up and down topic tree

ag: in simple table, that's table, row, cell
... as the three available levels
... master-detail table at http://turboajax.com/demos/grid3/ is not a simple table
... have row and cell navigation, and use <enter> for expand-collapse
... don't use left/right arrows for expand/collapse because that's used for cell navigation

js: should be able to move to a column, then move up and down rows with focus staying in that column

al: in such a use case, wlil read the cell even though focus moving to row (reads the delta of the selection)

rs: question of focusing whole row, or just the cell

al: depends on editable, interactive, etc.

rs: how does user know what situation is when they land on it

js: AT needs to indicate

al: usually indicates
... but navigation may depend on whether you're in an expandable/collapsable row or not

rs: prefer right/left arrow just for cell navigation

dp: if you move to either end of row, you're put in cell navigation; if you're in a row sticks in row

ag: prefer up/down arrow be row; right/left be cell

bg: how do you know how to navigate?

js: AT have specific ways to support

al: no standard way, you have to know the possibilities
... we don't know the best way yet
... we define the background markup, but others figure out the navigation
... most of this is techniques
... enter to enter cell mode, escape to exit

ag: prefer overflow the row mode
... escape key should be left to OS

rs: specify cell navigation as default, but author can override?
... concern that we know we have all the properties we need

al: we've got everything

rs: what do I do to switch from row to cell navigation

mc: leave that to AT/UA

ag: we need a consistent feel
... we need to provide a documented, but not required, keyboard navigation

al: enter good way to enter children, and escape good way to return to parent


al: issue of whether in row or cell navigation handled by UA because either container or child has focus and AT reports which


continuing previous list

9. issue of whether in row or cell navigation handled by UA because either container or child has focus and AT reports which

10. use of predefined keys to go down and up level, respectively

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

Multilevel menus

ag: can have arbitrarily nested menus
... want to ensure we have the needed ways to spec

bg: when get to a menu item that has submenu options
... do you end up in the child menu automatically?
... or explicitly open it?

dp: would like to first explicitly open the menu
... or have option to skip
... if open, can go into to start exploring the options

bg: want to avoid extra keystrokes

al: have "expanded"
... but not on combobox

mc: expect to be able to open submenus on demand

bg: how do you know you can?

al: visual arrow, which represents the "haspopup" property

ag: making it very treelike

bg: but we're agreeing it's not exactly a tree

ag: use "menu" with "haspopup"

bg: unsure how to open submenu

<scribe> ACTION: Becky and Aaron to revisit multilevel menus [recorded in http://www.w3.org/2007/01/23-pf-minutes.html#action01]

<becka11y> scribe: becka11y

sitebuilder / Cynthia Shelly feedback

based on feedback sent to the public list - Cynthia will give oral overview

cs: conflicts between aria and html semantics
... concerned with interaction between built in html roles and aria
... concerned avail of aria will encourage dev. to create non-semantic html
... which will prevent older /other tools that don't support aria from working correctly
... already much div soup on the web with styled divs rather than semantic markup
... for ex: using a div and marking up as text input rather than using input element
... what about changing the role of an exising html element - marking an input as a list
... exp. has been that very good devs don't do a very good job of determining the correct roles
... there are some controls that could go either way - is it a menu or a tree? end up with inconsistencies

rs: I think that devs will do div soup, etc whether aria is there or not
... need to be explicit that if html element is avail it should be used as it is defined

bg: what about a case of a tree that I create out of lists to make it degrade? I then want to mark the ul and li elements with roles of tree and treeitems

ag: but spec does rec. that author's use /prefer html semantics where avail.
... can do accessible things with script and style that can sway people who say that should only use straght html
... but, to RS argument - we need to allow people to go further
... it can have side effect to make it less painful to do bad things

al: if create a widget set that provides correct aria markup doesn't this become less of an issue?
... authors can use canned widget set but can also go further and create their own customized set - this tech. allows that

cs: ms approach in Windows LIve has been to attempt to model those controls in native html - menus for ex. are nested links
... we require script but it generates a semantically correct DOM
... they may not have the role of menu but since it is created from links it will allways work
... true that toolkits will hit many devs. there are still plenty of devs who "roll their own"
... concern is for those type of devs who are building commerce sites that build it with divs and spans and then will go back and make accessible via aria w/o going back and making correctly semanti
... concern isn't for windows live but for generic devs who think they have more knowledge than they do

al: think the realistically toolkits will hit the marjority of people

rs: using list of links is not a good idea because it puts everything in the tab order - it is accessible but not usable
... IBM is going to focus on a widget library with accessibility built in
... writing gui applications with or w/o aria is a very big job
... thus most organizations will use reusable libraries

de: responding to rich - what does aol do? We don't have the time to focus on reusable widgets

dp: has mixed feelings about nested list of links
... dev community is split into several camps. devs I am most concerned about are ones that want me to join their organizations and list, these are the ones that have the ability to pull off the advanced techs
... people that are already developing "wrong" will continue to do so

cs: list of links implementation doesn't put everything into the tab order
... concern over inconsistenciies between toolkits
... there is a major retailer who has very bad a11y bugs in their controls even tho they are trying
... there are mid level product teams who roll their own web dev and get it wrong
... believe it is possible to model most ui via semantic html and script and make it accessible

al: how would you do a spreadsheet?

cs: hard to design off top of head - needs design work

dp: understand that if there is no scripting support, links would be available - how does this behave?

cs: aria has the same problem with no scripting - depends on wcag baseline

rs: are u saying no one should use a div?

cs: I think there are better semantic elements to use than a div

al: I think her concern is that some sites will be less accessible because of aria?

ag: aria is trying to make simple aria extentions to enhance a11y, but cs is saying that we could have stayed closer to semantic html
... are the MS libaries something that we can look at for help in creating an implementers guide and techniques?
... in the rules we say u should use html where it works and it would be helpful to add addn example

cs: has examples that she will share with pf

mc: will notify group when examples are publically avail.

rs: when u have lists in lists - how does someone semantically know that something is expandable

cs: is a link that is scripted to open a list
... it has user tested quite well since using link can use onclick and have it keyboard accessible

rs: so why wouldn't redo a desktop to create menus as links. hard to believe that when go to an arbitrary page and know how those nested lists will behave

cs: felt to AT uses that list of links what there and it worked quite well - assuming titles of links were sufficient
... users expect web pages to work one way and desktop app to behave another. this method works more like users expect a web page to work
... other issues are about making it easier for html implementors
... diff between html and xhtml implementation - most html devs don't understand the different
... fact that two implementations are so different that it will confuse devs
... other issue is about maintainability of web site -would like to see aria implementation separated out like css
... then someone could create aria sheet ( like a css sheet) that someone knowledgeable could create

al: problem is that DOM needs to be acertain way to properly expose roles
... are u suggesting that aria is separated out like css?

cs: yes separate aria from markup
... would like to see more similarity between html and xhtml implementation

al: can use just the html implementaion

cs: think there are alot of devs who won't know which one to use

rs: not sure what you are asking? do you want us to mark certain sections of doc as aria?

cs: would like to see the same syntax in html as xhtml
... would like to be able to just put a class on a tag and put all the role and state somewhere outside of the tag in a model much like css

rs: not sure separating out is possible in reasonable timeframe

al: that is what xbl does
... that is being worked on by web app formats but is still years away

mc: agree it may be hears away, lisa's tool could do this

al: isn't that what Dojo does?

bg: dojo embeds all of the roles and states via scripting to html or xhtml works the same way

ag: aaron and I have had this conv. about xbl before
... approach of xbl would make us dependent on things that don't exist yet (or didn't exist at all when we started aria)
... once html 5 gets underway we could modify aria to work with them - but they aren't there yet - we are working to build working model
... it may get re-engineered in new html reforms from new html working group

rs: we are also working to build a style guide for this so we are consistent

ag: but there are two distinct style guides for xhtml and html

cs: my point is that many devs will make the wrong choice since they don't know the difference

mc: as in Wcag - there is the what would we like that doesn't work now vs. what works now ;

<MichaelC> ackm

<Zakim> MichaelC, you wanted to say we don't have to rule out binding in the future, but still provide techniques for what works now

cs: would the group be open to seeing a proposal on separating aria stuff into separate constructs ( like css)?

mc: we can't promise what will become of a proposal but of course we want proposals
... provide a high level of propsal at first and if group feels it is worthwhile develop it further

cs: sounds like group is in favor of developing toolkits to help developers
... could a typical college soph working in notepad do this - is that the target

rs: no - that is not target dev.

al: there are some constructs that are easier than others - example: required and describedby fill holes in html spec.
... can publish articles on fundamentatl things that are simpler to use

cs: while they aren't building dojo web devs are building menus

al: but are using ajax and want to mark things as live regions
... full tree grid implentation - would recommend (even on the desktop) to find an existing one rather than building from scratch
... my view of this tech. is that it is targeted to a trickle down discemination - we don't have the capacity to put hte power to create competitive gui interfaces into the sat. morning dev except via libraries
... native posistioning of this tech. - big highly competitive web sites will use it; market forces will force others to be competitive with these - will be a trickle down - sat. morning devs will steal code from existing sites and will learn hwo to use

rs: expect supprt by tooling

al: I understand that there will be tools but there is a long distance between tools and sat. morning web dev. having access

previous comment was al gilman

aaron: I agree with concerns but we need to address the problems now - need to be able to make cool ajax apps accessible now
... wish it could be more simple but it won't be like that until we raise the bar to make web more accessible
... want this embedded in html

cs: agree that we want this in native html

rs: took 7 years for css 2 to reach mainstream use

aaron: we can't wait that long for better a11y - need something now

rs: agree that we want this in native html so am joining the html 5 working group

cs: forcing alignment of semantic html and aria is the goal


drag and drop

rs: problem with dnd spec is not what is in it but when it will actually show up? could be years
... issues: when will it be complete? when will it show up in mainstream browsers
... how does it address AT - there are new events? there is no a11y api
... several different types: drag start, drag in, etc.

<Rich> Issues with waiting on Drag and Drop API

<Rich> * How long before will show up in browsers?

<Rich> * What major browser manufacturer will implement?

<Rich> * What is the runway for standards completion?

<Rich> * How does this address the AT? These are new events.

<Rich> Possible strategy to address using ARIA model

<Rich> 1. DragStart is performed using a keyboard with a pop-up menu ot select the action.

rs: suggest drag start be implemented via keyboard with a ocntext menu;

<Rich> 2. DragStart sets a property called dragsourcenode=True and visibibly shows the drag starting point (based on the dragsourcenode being set).

<Rich> 3. User uses keyboard navigation defined by the application to navigate to each element which is a designated target. Navigation could be assisted by role landmarks, or other roles possibly. As a minimum, DOM navigation should be used.

<Rich> 4. Upon entering a node dragtargetnode is set to true on the node and a relationship is defined to associate the source and the target. Setting a target results in an event notification to the AT and the activation of a target style like a dotted border or insert line.

<Rich> 5. To drop, three options should be available Drop Before, Drop, Drop After and they should be available via a context menu. All drag properties are then cleared. Some sort of event could be fired to indicate the drag operation was complete

<Rich> 6. This proposal may require accessibility API changes. The OS does provide Drag and drop events, however these are not exposed as accessibility API and we may not be able to simulate the OS. If this were to occur that should be something the browser developers should do in the WebAPI effort.

see direct input from Rich for proposal

aaron: regarding drop - how is this different than not being able to click anywhere

algilman: u can't navigate to the insertion point when it is between item 3 and item 4
... currently can only focus to an existing objects

aaron: can you navigate to any pixel point in this proposal?
... usually dragging to another object but sometimes dragging to a particular pixel point

rs: think there is another way - that bg and I submitted as a patent - need to make that open source

algilman: agree that this proposal doesn't address droping at a particular pixel point

rs: once have established pt in dom structure can drop before, drop on, drop after or drop as child
... proposal will likely require a11y api changes

dp: apple may have apis for drag n drop

rs: need to know that you have landed on an object that will accept a drag or if it is about to accept a drop
... rich explains item 6 above

don: demos AOL mail done with Dojo
... can drag and drop mails into mail folders
... can drag and drop pictures into albums and can select multiple items and drag/drop
... AIM pages - (AOL competition to myspace) - users can create modules; can drag n drop modules onto the web page

rs: in keyboard nav - finding where to drop in the middle of something is hard - does model of before and after make sense

don: can drag into a folder or between existing folder

algilman: am used to this behavior in layout manager; not sure we want a drop event - what happens at the source node some to a cut or copy
... don't know if cut or copy until u reach the drop point
... are applying a method on the object that you have lifted from the source point when you reach the drop point
... may be doing an insert on the destination but may be doing other options on the item that was dragged
... need the intent based semantics - user needs to be controlling this - for ex: is it a file compress, is it a file move, is it a file copy
... in exposing the interface to drag n drop we need to expose the context of the operation (need to establish relationship between source and target)

aaron: when something goes in context menu that usually goes up front - for example must pick cut or copy

algilman: have to work context menu to enable the functionality not necessarily mimic the navigation of actually dragging

aaron: know that anchor by selecting or focusing

dp: I think of rubberband as selecting in a group - is it contiguous or not? need to know that

algilman: in the case of compressing a file, the default is that the original file remains - user doesn't have to select cut or copy
... whether the file remains on not depends upon where you drop it - in some cases it remains and others it does not

aaron: why isn't this something the OS should do?

algilman: mousekeys exist and they are generally not usable - is too restrictive

aaron: I want to say move the mouse to focus, move mouse to paricular object, click and hold, click, and also want to be able to move to any location all via the keyboard

Linda's (lm) review of roles

<MichaelC> http://lists.w3.org/Archives/Member/w3c-wai-pf/2007JanMar/0079.html

lm: what is the level of semantics?

<Al> Linda's email at http://lists.w3.org/Archives/Member/w3c-wai-pf/2007JanMar/0079.html

rs: we haven't done an api for brand new widgets - need a way to define abstract roles

al: idea is that base roles are abstract roles

rs: base classes are there to define if an obj is structural or a widget - those base classes will hav eproperties that are inherited by acutal roles which are instantiated in the cod
... user agent shouldn't expect to see those base class roles in a document
... like canvas - need to subclass it
... at some point need to create an api to expose knowledge about information of new widget - it is like the existing xyzzy widget and hax hte following properties
... the rdf taxonomy is a class hierarchy and you can inherit to create own custom widget

al g: there is aconcept of distinguishing widget roles from structural roles

al g: structural roles are distinguished by navigation behavior

al g: widget roles are typified by behaviors in context - they do application functions

lm: if the sturctural role is for navigation are tree treegroup, radiogroup, option structural? they are currently under widget

al g: tree group certainly seems like it is structural

lm: msaa is flat but ui automation has the concept of hierarchy and inheritance

al g: sometimes properties inherit from part whole hierarchy - I see hierarchy and inheritance as separate

al g: there is a part / whole hierarchy and a derivation hierarchy

lm: ui automation has those concepts - and lm can review with others

al g: we can do this at a meeting - we want two implentations. ATK is one implementation of these concepts, UI automation is another possible implementation

al g: would be good if all of this maps gracefully into different api implementations

lm: I think ui automation exemplifies many of these patterns
... can apply patterns to roles - for ex: in a tree can apply collapse patter

rs: challenge will be to figure out what action will cause the events to occur

lm: do we talk about the events in aria? or just the static roles? what about xml events?

rs: at some point in hmlt working group we considered adding purpose to events - it has not made it into xhtml spec
... would help to allow events that are not keyboard dependent - to expand via voice input instead of just keyboard

<scribe> ACTION: lisa to add an issue to explain related concept as a borrowed concept (for example not subclassing from xforms but are borrowing hte concept) [recorded in http://www.w3.org/2007/01/23-pf-minutes.html#action02]

<aaronlev> scribe aaronlev

<aaronlev> scribenick aaronlev

<aaronlev> scribe: aaronlev

JA: 2 things which which are interrelated
... UAAG issues around ARIA
... one issue was about live regions, ARIA markup, and when should the user's context change. Maybe based on user configuration or politeness?
... another issue was, should the user agent provide some kind of live region support if the author doesn't do it
... does the UA need to allow for that

Rich: a screen reaer can do that repair
... a screen magnfier will also be able to do that
... maybe that depends on the level of navigation

JA: what about users with mobilty impairments with no AT
... what about sliders

aaronlev: a slider is not what we usually mean by a live region -- that's more of a widget

Rich: you might want to follow a relationship

Al: if there's something the thing can do you need to be able to navigate to it
... it might not be in the tab order
... so yes there's a case for this

JA: our first provision in the document

claws: it's the job of the javascript author to do this, not the AT or the user agent
... because we have no way to know how to repair it

becka11y: agree

Al: not true
... firing any event is in DOM 2, and in DOM 3 we can ask what events it handles

aaronlev: we can do it now but not via the DOM (we can do it in C++)

JA: if i can't even get to it, there's no chance

Al: then you're violating wcag

aaronlev: let's enable a better mouse keys by exposing any object with event handlers and what those handlers are
... we do that for onclick

claws: i think it's a problem to require the AT to fix content

Al: i'm hearing that the base browser should operates some navigation mode that lets you navigate to all those things

claws: the browser should let you key navigate to anything with an event handler

Rich: expose it thru accessibility api

Linda: i expect user agent to handle it

Rich: if the app didn't provide a keyboard nav mechanism to get to it, how can you get to it and use it

Al: device independence has taken this issue

Linda: the operating system should control the mouse pointer, not web browesr

claws: the user agent could do it

MichaelC: wednesday is joint WAI meetings to talk about a roadmap or timeline for testing
... we'd like to share resources between different groups
... there's a page: http://www.w3.org/2007/01/wai-testing
... the QA working group provided a lot of materials and then disbanded
... several of us have test suites as well
... the plan is to get a little bit technical, this could lead to some kind of coordination group for testing, depending on the interest level (for all of WAI)

<Al> joint VXML-MMI meeting will begin in Kiva (G449) on Wednesday starting at 9:

Summary of Action Items

[NEW] ACTION: Becky and Aaron to revisit multilevel menus [recorded in http://www.w3.org/2007/01/23-pf-minutes.html#action01]
[NEW] ACTION: lisa to add an issue to explain related concept as a borrowed concept (for example not subclassing from xforms but are borrowing hte concept) [recorded in http://www.w3.org/2007/01/23-pf-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/01/23 22:03:25 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/tile/child/
Succeeded: s/aaron/Al/
FAILED: s/IAccesible2/MSAA/
Succeeded: s/the cell/the row/
Succeeded: s/should be supported/may be provided/
Succeeded: s/rows should support/rows may provide/
Succeeded: s/but can/but author can/
Succeeded: s/document,/documented,/
Succeeded: s/enter and escape is/predefined keys/
Succeeded: s/want/won't/
Succeeded: s/exlains/explains/
Succeeded: s/use/user/
Found embedded ScribeOptions:  -final


FAILED: s/IAccesible2/MSAA/
Found Scribe: Janina
Inferring ScribeNick: janina
Found Scribe: Rich
Inferring ScribeNick: Rich
Found Scribe: Michael_Cooper
Found ScribeNick: MichaelC
Found Scribe: becka11y
Inferring ScribeNick: becka11y
Found Scribe: aaronlev
Inferring ScribeNick: aaronlev
Scribes: Janina, Rich, Michael_Cooper, becka11y, aaronlev
ScribeNicks: MichaelC, janina, Rich, becka11y, aaronlev
Default Present: MIT531, leesa, Dave_Pawson
Present: Al_Gilman Linda_Mao Aaron_Leventhal Becky_Gibson Michael_Cooper Rich_Schwerdtfeger Janina_Sajka Dave_Poehlman Don_Evans Lisa_Seeman Tim_Boland Dave_Pawson Cynthia_Shelly Masahiko_Koneko
Got date from IRC log name: 23 Jan 2007
Guessing minutes URL: http://www.w3.org/2007/01/23-pf-minutes.html
People with action items: aaron becky lisa

[End of scribe.perl diagnostic output]