Chair: Jon Gunderson
Date: Wednesday, May 5th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000
Navigation checkpoints
Chair: Jon Gunderson (JG)
Scribe: Jim Allan (JA)
CANCELED RR: Rewrite 7.2.2 as you want it (centered around information). we will use current checkpoints, will discuss any new checkpoint after next working draft (issue is not relevent for resolution of guideline 7.2 anymore)
JA: look at nav stuff and propose checkpoints and techniques, by Monday (maybe) techniques what attributes are important to search for group to review and assign more tasks at next meeting. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0081.html
CMN: Will write techniques section for the checkpoint on navigating the document tree, will include eamples of speech rendering of the walking structures http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0077.html
JG: rewrite navigation proposal , add walking the tree, based on todays discussion . http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0072.html
HB: checkpoint for metadata search
JA check guidelines for information about tooltip control
Editor: Group navigation checkpoints by function (searching, sequential/list, ..)
JG: Add issue to the issue list related to access to keys labeled with ACCESSKEY
MG: Propose navigation checkpoint to time dependent items on the page, (smil - seperate from pause, stop), include techiques-scenario to help working group undertsand what this checkpoint would mean to a user
JG: Contact T.V. Raman and other experts to participate in Math navigation discussions for May 19th meeting
Accept proposed checkpoint: Sequential access to active elements, P1, subgroup: both
Accept proposed checkpoint: Search for an element based on its text content, P1, subgroup: both
Add checkpoint: search for content based on attribute value [metadata information (class, etc.)], P3, subgroup:both
Accept proposed checkpoint: Sequential access to all elements, P2, subgroup: DUA
Accept proposed checkpoint: Allow the user to access the text information of an element, P1, subgroup: DUA
Accept proposed checkpoint: Allow the user to move the focus to a frame from a list, P1, subgroup: both
Accept proposed checkpoint: Search for a link based on its text content, P3, subgroup: DUA
Accept proposed checkpoint: Allow the user to move to a header from a list, P2, subgroup: DUA
Accept proposed checkpoint: Allow the user to select a link from a list, P2, subgroup: DUA
Do not include proposed checkpoint: Direct access to a link from a list of visited links (put as part of access to links checkpoint)
Do not include proposed checkpoint: Direct access to a link from a list of unvisited links (put as part of access to links checkpoint)
Accept proposed checkpoint: Allow the use to move the focus to the first control of a form from a list, P2, subgroup: DUA
Accept proposed checkpoint: Allow the user to move the focus to a form control from a list, P2, subgroup: DUA
Accept modified proposed checkpoint: Allow the user to select a alternative content from a list of alternative content, P2, subgroup: DUA
Accept proposed checkpoint: Allow the user to move the selection to a table from a list, P3, subgroup: DUA
Accept proposed checkpoint: Search for the next element with the same attributes as the current element, P3, subgroup: DUA
Accept proposed checkpoint: Allow the user to navigate the Document Object Model (DOM), P1, subgroup: DUA
jg: reivew his proposal,
Sub-groups: Both
Priority: 1
Technique
Allow the user to sequentially move the focus of the user agent to each of the active elements of a document. The active elements include links, form controls and long descriptions.
hb: active element, something script generated,
jg: basic access, don't include scripting, bubbling, etc.
*Resolved*
Sub groups: Both
Priority: 1
Techniques
If text is found in the document the selection moves to the matching text and element. The text content of form controls and the text attributes of elements can optionally be included in the search and if a match is found the focus is moved to the control with the matching text.
Control elements with text content:
Initial list of Attributes of Elements
jg: similar to find function
hb: should be P1, its most inclusive element
jg: inportant to search in
mg: P1
cmn: important but would not be stuck with out it
mn: abstain, if we have too many P1 then nock to a P2
hb: discuss techiques, need to expand list to include class, mapping of
digital talking book, class differentiates chapter from sub chapter,
jg: need new check point, different search function
hb: searching on metadata
jg: text content of attribute is information that appears on the screen
hb: happy with new check point for search on metadata
cmn: would be a lesser prioity
jg: need a new check point for searching for metadata
hb: meta information is very idiosyncratic in html 4
jg: what is the group dependent? or both?
jg: pri 3
ja: agree
cmn: agree
mg: pri 2
hb: pri 2
mn: any single attribe that exists on all tags
hb: style, i18n, title, name,
mn: put priority on the most common attrib.
mn: pri 3 (very techy, low use)
cmn: ok with styles, implement css 2 selectors, based on attrib presense or absense
jg: who would use it, vi, or motor, non-diabled person
mg: motor impairments
jg: class name not related to function
hb: dom gives access, useful in xml application
mg: is alt part of the content of the document
jg: add alt to list
hb: generic thing called type
ja: turn off tool tips
jg: do we have info about this in guidelines?
cmn: falls under control alternative content rendering (normative requirment)
jg: if its really important need a new checkpoint
**Action hb: checkpoint for metadata search
**Action: ja check guidelines for information about tooltip control
*resolved: new checkpoint: search for content based on attribute value
[metadata information (class, etc.)], P3, subgroup:both
*Resolved P1 (for now)*
Sub groups: Dependent user agents
Priority: 1
Techniques:
Allow the user to sequentially move through all block (paragraph) level elements in a document. The current element is selected as the user navigates between blocks. A initial list of block (paragraph) level elements:
cmn: part of dom navigation, provide an alternative dom (outline) for
navigation. Delete check point, technique for navigation dom
jg: need to be checkpoint and pri 1 for dependent ua, left "block" out intentially
hb: step through element by element
mn: how is technique different from dom
jg: 2 models , list of all elements (flat), hierarchical list
cnm: if you use deapth of 1 hierachical list you get flat outline
jg: flat list ignores span items
cmn: particular instance of dom navigation,
jg: this would be a tech for dom nav
ja: agreee
hb: agree
jg: don't agree, need this function, need to elevate to checkpoint because it is so important
cmn: important to have general ability, provide examples of
jg: getting feedback as not important
mn: subset of nav the dom, yes it is important for vi to navigate in a specific way, different from mobility, can't accomodate all specific instances, want to make sure it is spelled out. how do we put this in the document.
Example-ability to know when you cross paragraph boundries, in an audible sense, when you are in a paragraph an move to the next one how do you know
cmn: then leave it in for now,
jg: we won't change it until proposed req.
cmn: leave as open
jg: can't
mn: priority is too high, may get
cmn: see it as a p2 and perhaps a p3
mn: pri depends on which block
cmn: need general ability nav whole tree, nav specifics instances is user specific
mg: question
jg: different models of document for nav
mg: sequential nav
cmn: structure of amaya, allows diffenent views, then skip specific items
hb: another set of structuring elements, would expect people to stop at,
jg: would say ordered list 18 items then move into list, or nav in table, not just reading text, but give orientaion inforation.
cmn: this checkpoint is just block nav, review css for examplesblock elements, allows to navigate and read content,
jg: this is only one techique,
cmn: already require walking the document, this is a specific instance of walking, and should be less import,
ja: reivewed e-mail
jg: we want specific important instances to be techniques
hb: conceptually generic case is a solution, depends on browser implementation
jg: what about browsers that don't have a dom, opera
jg: deapth search items, stop talking about it, everything is navigating the tree.
hb: there are a set of elents that are displayed visually, others are suppressable
cmn: thought we were leaving it in as open issue
jg: need to thrash it out now.
cmn: put in wd and discuss it. propose_ put it in, discuss prioity
jg: thught discussing wheterh to put it in or out, as a generic instancce
cmn: just drop pri and leave it in
ja: agree with cmn
mn: agree
mg: agree, important enough to leave it in, unsure of priority, perhaps leave it at P1
hb: no strong opinion
*Resolved: drop to P2
Sub groups: Dependent user agents
Priority: 1
Technique
Allow the user to view the text content of an element including the viewing of single characters, words and sentences with in the element.
CMN: This is obvious one
*resolve: ok
Sub groups: Both
Priority: 1
Techniques
The user can access a list of frame elements in the current document.
Implementation Idea #1 (basic)
There is command that allows a user to move the focus to the next or the previous frame in the document sequentially. Only frames are traversed by the command.
Implementation Idea #2 (advanced)
The user agent generates a list of frames. The text items in the list are based on the NAME attribute or physical position on the screen. The user can use cursor keys or the first letter to move through the list of frames.
The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a control moves the focus to that frame in the document.
cmn: a list that includes all items
jg: list of specific elements
mg: list of frames
jg: like lynx, list of links, broaden implementation,
mn/ja: can we generic this and make them all p1
jg: no, they are different pri, in techiques point to same large group of techniques, leave as seperate checkpoint, highlight those elements as "special"
mn: will this box us in when guidelines don't change but techniques dont
jg: checkpoints stick out, techniques may get washed, an editorial thing, work with Ian, id key issues, not wordsmith, resolve issues,
jg: general sense, move focus between frames a list is one way
*Resolved: ok
Sub groups: Dependent user agents
Priority: 2
Techniques
Allow the user to search for a link based on the text contents of the links in a document. Images that are part of the links the text content will be considered the ALT text. If the text is found in a link the focus is moved to that link.
cmn: pri 3
ja: agree
jg: can live with this
mg: search for text
jg: only link text, skip other text, skip other links
mg: can you search other things
jg: implementation, search-limit to links or text or headers or whatever,
useful for navigation
mg: explained group search checkpoints together
jg: put in techiques document, a section dealing with searching, turning things on and off, now we have one to one correspondence this is a checkpoint we want to have
mg: checkpoints will stay in this order
jg: group by pri, or we can group differently ie audio, how to group
editorial
**Action editor, group check point by function (movement nav, seaching nav)
*resolved: move to p3
Sub groups: Dependent user agents
Priority: 2
The user can access a list of only header elements.
Implementation Idea #1 (basic)
There is command that allows a person to move the selection to the text content of each header in the document sequentially. Only headers are traversed by the command.
Implementation Idea #2 (advanced)
The user agent generates a list of headers in the document. The user can use cursor keys or the first letter to move through the list of headers. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a link moves the selection to the header in the document.
cmn: don't remove, note that it is related to dom naviagation and move on
*resolved: p2
Sub groups: Dependent user agents
Priority: 2
The user can access a list of only link (anchor) elements. Links that are part of images will use the ALT text for the text content of the link.
Implementation Idea #1 (basic)
There is command that allows a person to move the focus to each link in the document sequentially. Only links are traversed by the command.
Implementation Idea #2 (advanced)
The user agent generates a list based on the text content of each link in the document. The text content could include additional information on whether the link is registered with the user agent as being visited or unvisited. The user can use cursor keys or the first letter to move through the list of links. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a link moves the focus to that link in the document.
cmn: p3 because we already have generic case of moving between actvie elements
mg: P2
ja: P2
hg: P2
*resolved: p2
Sub groups: Dependent user agents
Priority: 3
The user can access a list of only link (anchor) elements that are currently registered as being visited by the user agent. Links that are part of images will use the ALT text for the text content of the link.
Implementation Idea #1 (basic)
There is command that allows a person to move the focus to each visited link in the document sequentially. Only visited links are traversed by the command.
Implementation Idea #2 (advanced)
The user agent generates a list of visited links. The user can use cursor keys or the first letter to move through the list of visited links. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a link moves the focus to that link in the document.
cmn: sorting the list, move to techniques
ja: agree
mg: agree
*Resolved: remove this checkpoing, include as a techniques to generic link nav
Sub groups: Dependent user agents
Priority: 3
The user can access a list of only link (anchor) elements that are currently registered as being unvisited by the user agent. Links that are part of images will use the ALT text for the text content of the link.
Implementation Idea #1 (basic)
There is command that allows a user to move the focus to each unvisited link in the document sequentially. Only unvisited links are traversed by the command.
Implementation Idea #2 (advanced)
The user agent generates a list of unvisited links. The user can use cursor keys or the first letter to move through the list of unvisited links. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a link moves the focus to that unvisited link in the document.
*Resolved: remove this checkpoing, include as a techniques to generic link nav
Sub groups: Dependent user agent
Priority: 3
The user can access a list of forms on a page and move the focus to the first control in the form.
Implementation Idea #1 (basic)
There is command that allows a user to move the focus to the first form control in the next or previos form in the document sequentially. Only the first form control in each form are traversed by this command.
Implementation Idea #2 (advanced)
The user agent generates a list of forms. The text items in the list represent the TITLE or document order position of the form. The user can use cursor keys or the first letter to move through the list of form controls. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a control moves the focus to that form control in the document.
cmn: moving between forms, should be a p2
ja: agree
mn agree
*resolved P2
Sub groups: Dependent user agents
Priority: 2
The user can access a list of only form control elements.
Implementation Idea #1 (basic)
There is command that allows a user to move the focus to the next or the previous form control in the document sequentially. Only form controls are traversed by the command.
Implementation Idea #2 (advanced)
The user agent generates a list of form controls. The text items in the list represent the all the form controls in the document. The text items are based on the form label or the type of control with additional information on which form the control is associated with if there is more than one form in the document. The user can use cursor keys or the first letter to move through the list of form controls. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a control moves the focus to that form control in the document.
cmn: should be p3, specific instance of generic case
ja: agree
*resolved P3
Sub groups: Dependent user agents
Priority: 2
The user can access a list of only long descriptions from images.
Implementation Idea #1 (basic)
There is command that allows a user to move the focus to the next or the previous long description link for an image or object in the document sequentially. Only images and objects with long descriptions information are traversed by the command.
Implementation Idea #2 (advanced)
The user agent generates a list of long descriptions links available for images and objects in the document. The text items in the list are based on the ALT text for the image or object. The user can use cursor keys or the first letter to move through the list of long description links. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Common cursor keys
Selecting a long description label moves the focus to long description link in the document.
cmn: reword access alternative content from a list, if object hierarchy gets inteesting
jg: include object as part of object
jg: proposal: Allow the user to select alternative content from a list
no desention
*resolved: change to Allow the user to select alternative content from a list
**action: mg: nav to time dependent items on the page, (smil - seperate from pause, stop), include techiques-scenario
Sub groups: dependent user agents
Priority: 2
Techniques
The user can access a list of table elements in the current document.
Implementation Idea #1 (basic)
There is command that allows a user to move the selection to the next or the previous table in the document sequentially. Only tables are traversed by the command. If tables are imbedded, then the next or previous table is determined by depth first ordering of tables in the DOM.
Implementation Idea #2 (advanced)
The user agent generates a list of tables in the document. The text items in the list are based on the CAPTION element or the physical dimensions of the table. Information is also included on whether a table is embedded in another table. The user can use cursor keys or the first letter to move through the list of tables. The cursor keys allow for moving one or multiple items in the list depending on the cursor key pressed:
Selecting a control moves the focus to that frame in the document.
cmn p3
hb: p3
mn: p2
ja: p3
*resolved: p3
Sub groups: Dependent user agents
Priority: 2 or 3
Allow the user to move to the next or previous element of the same element type and attributes. If an author used poor formatting methods this provides a means to navigate the structures of a document using the authors representation of the informaiton.
cmn: p3, general take me to the next thing like this
ja: p3
*resolved: p3
Sub groups: Dependent user agents
Priority: 2
Navigating the document tree (as defined in the DOM level 1 specification) provides access to the contents of every element in the document. This technique is designed to meet the needs of the users who require access to individual elements and their attributes to determine the document contents or prefers the tree metaphor for navigating the document.
Every node in the Document Object Model tree represents an element and its associated elements. Every node has a parent node and potentially siblings, children and text content. There are three basic navigation commands for navigating the document tree:
Moving to children or siblings could accomplished using the list techniques described for other checkpoints. At each node the user should be oriented to the type of element the node represents.
The types of user commands that need to be available at each node include:
hb: p1
cmn: getting w3 dom, getting other dom, we require w3 dom to imlemented,
then implementing nav w3 dom is easy, other outline views may be more
difficult (headers checkpoint)
jg: tree rendering of doc, base on technique cmn described,
cmn: implementation specifice, important case to nav othe doms, may need 2 check points-nave w3 dom, and p3 nav other type of dom, ideas are there is a more user friendly model like using the headers as an outline of document sections. In the current dom there is no forced relationships betwwen H1-H6.
jg: sounds like something that should be put int he in the techniques document
cmn: agree
ja: agree
hb: agree
jg: p1
cmn ok
mn: ok if w3 dom
ja: ok
hb: ok
*resolved: p1
hb: keyboard nav up right down is redundent, may want to use thos keys for something else
cmn: this is a technique
jg: agree
no formal meeting next week, may have an informational meeting on Math navigation
math nav in two week,
hb: wants raman on list, raman is happy with mathml
jg: two camps, raman-tree, gardner diffent group, Tom W. wgbh
cmn: id meeting as informal, and keep careful notes, not make it a regular
meeting, discuss on list,
jg: proposal on list by end of week,
cmn: need open meeting, and discussion on list
jg: proposal as a starting point
cmn: want all details that went into proposal, all discussion to be
documented and published
hb: agree,
hb: don't have any thing on accesskey,
jg: no check point,
Open issue: nav access key, also queury assesskey
nextmetting on May 19th mathml nav