See also: IRC log
<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?
agreement
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
test
<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
s/IAccesible2/MSAA/
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
http://turboajax.com/demos/grid3/
<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
<discussion>
al: issue of whether in row or cell navigation handled by UA because either container or child has focus and AT reports which
<agreement>
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
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
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
break
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
<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:
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 *** RESTARTING DUE TO EMBEDDED OPTIONS *** 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]