Chair: Jon Gunderson
Date: Wednesday, April 28th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Discussion and resolution of navigation issues. The following issues related to navigation are currently on the issues list:
Chair: JG-Jon Gunderson
Scribe: JA-Jim Allan
HB-Harvey Bingam
CMN-Charles MacCathieNevile
MN-Mark Novack
Ian Jacobs
JG: Review Action Items
Dennis proposal discussion 3 types of pages - gateway, query, content JG need to add interactive pages
HB: thats buried in query pages
JG: 2 types of users familiar with page and unfamiliar related checkpoints to types of pages
HB: likes concepts presented
JG: my proposal concerns checkpoints and techniques and reach resolution listed checkpoints, subgroups, priorityhttp://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0066.html
JA: nested lists, bullet indication jg: chuncking, moving to new list need something that says view attribute of list item cmn: sounds like search for thing that is the same jg: when you enter a list item or sublist item orient to list-how many items in list, relation to other list, cmn: walk the document tree
JG: document tree is not alway walkable, if you add image then the image becomes a node cmn: example at hand, moving down list, children are 10 list item, first 5 are list item, 6 and seven are also lists, allows us to do wha we want
JG: Opperman objectd
CMN: opperman was wrong
JG: what about inline elements that fragment words cmn: then read the text, do both things, traverse active elements hb: mixture of pcdata with embedded other inlines, pcdata is sibling in the dom para with some words bold, bold is a sibling,
CMN: content follows text logically, node to siblings, text---bold node---text etc cmn: node 47 children, what type of node it is, then tell me more, configure how it tells you information
JG: ACTION: cmn to write checkpoint for node navigation description with speech output, how are inline elements handled write a proposed checkpoint walking the tree with techniques
HB: tree is only one implementation of dom, don't presume tree, other views may be easier to implement jg: must view how user sees and interacts with infromation cmn: how does user see a page, if not a tree then what
JG: view it as linear, no concept of nodes, siblings, etc, could be very complex, must work in all situations, if i must navigate 3 format table to get text it gets confusing.
HB: look at dennis's materials, sequentially nav headers
JG: sequential nav of headers should be checkpoint
HB: distinguish page type by nav type
JG: 3 types of techniques sequential search text sublist of elements - text content and attrib values
HB: what about prior previous
JG: part of cmn action
MN: keep tree metaphor, user understanding not important, sequential next similar item - what user wants, immaterial the technical aspect, just do it.
JG: techniques - use algorithm to implement checkpoints
MN: yes-lists with sublist, headers with subheaders, can do them, walking some kind of tree, but user doesn't care, just wants to do a task.
MN: this is a good start, based on other browsers, must evolve, get global stuff and review,
JG: must have this done by next week, or we go to recommendation in december instead of fall, look at stuff now, to move to recommendation.
CMN: we are close to checkpoint list, need some work, main comment- doesnt say navigate the tree, propose checkpoint, priorities are a little off
JG: what about proposed list, ok then add doc tree
CMN: drop prioity, then doc tree provides most features, need list, fix prioities, add check point for tree, and tree may replace items on the list
HB: walking dom provides access to hierarchy and attribute value.
JA: /* comment */
JG: how do checkpoints reflect functional navigation, go to next parent, child, what do people think?
HB: like concept of walking tree, but breaks in tables,
JG: covered in table
HB: tree walking
JG: want several checkpoints related to waling functions or one checkpoint that says walk the tree?
CMN: one check point - naviagate whole document tree allow specific types of navigation. Checkpoint that states moving from active element to active element is not walking the document tree
JG: Is not moving from active element to active element just a searching function of the dcoument tree
CMN: This funtion does not need the document tree to be implemented, the function could search a linear object of elements and get the same results
JG: need check points that specify specific navigation commands?
CMN: nav whole document, then need convient/specific access
MN: need general then specific implementations
JG: Do we need a checkpoint that says view this node
CMN: no
JG: functional checkpoints are necessary, there is a fundamental level of navigation commands for dom nav
JG: what is check point to allow user to nav doc tree
CMN: tree is only one represenation, possible to show doc as linear object, goes down wire a serial object, navigate the document navigate the doc tree because of dom
JG: Navigating the document tree is a big check point, don't we need little checkpoints related to: nav to next child, next sibling view all elements on node
CMN: don't need alot of checkpoints, just one, need to walk around tree
JG: need more specifics, foward and backward
CMN: just one checkpoint mn: major heading
CMN: guildine say navigate document tree, guideline should say nav the document. Checkpoint nav the tree. Elaborate on navigation of the document tree in techniques
MN: convient checkpoint cmn: nav doc sequentially first nav doc as tree then move element to element, serial nav mn: convience function
CMN: then nav list of links.
JA: yes, agree with cmn and mn, we all want the same thing, words are getting in the way.
CMN: add one checkpoint action item
RESOLVED: check point to nav docu tree
JG: Then searching is not tree navigation,
HB: seperate content from attribute
JG: may be other representation other than tree, what does lynx use cmn: serial document **
ACTION: JG rewrite proposal , add walking the tree, based on todays discussion
JG: people need to think about it, if you are walking tree in speech, what to tell people at each node, need to convey to developer,
JG: Need to get navigation finished by next week tohave any hopw of moving to recommendation in the fall, imperative, please try to think about this issue this week so we can come to resolution next week
JG: new issue from IG, may be outside charter, authors tools,
CMN: XFO flow object description, structure stripped,
JG: outside our scope, only authoring tools
CMN: potential issue, read ?? ways of dealing with it, useragent not accept XFO
JG: how will ua know cmn: xfo formating of xml, for xml ua, new tags
JG: is there any thing we should implement
CMN: ua should implement styling -xsl not xfo
JG: xsl still in development cmn: let xsl group deal with it, maybe invite Hakon Lie to join the group
JG: cmn please write and ask Hakon Lie to join
JG: If we have some statement about XFO-the only thing that ua could do would be implementation of xml markup
CMN: dont know how the issuue be handled
JG: RESOLUTON won't address XFO at the moment, will wait until other working groups have tme to process.