W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for April 28th, 1999

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


Open Action Items


Discussion and resolution of navigation issues. The following issues related to navigation are currently on the issues list:

#3: Should user agents be able recognize markup for navigation bars (Open)
#11: Move to the next element with the same attributes and element type (Open)
#15: Sequentially navigate between active elements (Resolved)
#16: Sequentially navigate to only link elements (Open)
#17: Sequentially navigate to only form controls in a document (Open)
#18: Sequentailly navigate to only elements with long descriptions (longdesc attribute or OBJECT content) (Open)
#20: Sequentially navigate header elements (Open)
#21: Search for link based on its text content (Open)
#22: Sequentially navigate between forms in a document (Open)
#23: Search for a form control based on text content (Open)
#24: Search for a form control based on its attribute values (i.e. label or control type) (Open)
#25: Sequentially navigate to all elements (block level) (Open)
#26: Search for an element based on its text content (Open)
#27: Move to the next element in the document tree as defined by DOM (Open)
#28: Move to the child level element of the current element in the document tree (Open)
#29: Move to the next (or previous) sibling element in the document tree (Open)
#30: Move to the parent element of the current element in the document tree (Open)
#38: Search for a link based on its attribute value (Open)


Chair: JG-Jon Gunderson

Scribe: JA-Jim Allan

HB-Harvey Bingam

CMN-Charles MacCathieNevile

MN-Mark Novack


Ian Jacobs

Completed Action Items

Continued Action Items

New Action Items



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.

Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.