- From: Jon Gunderson <jongund@staff.uiuc.edu>
- Date: Wed, 05 May 1999 16:30:19 -0500
- To: w3c-wai-ua@w3.org
Minutes also can be found at: http://www.w3.org/WAI/UA/1999/05/wai-ua-telecon-19990505.html Attendance Chair: Jon Gunderson (JG) Scribe: Jim Allan (JA) Marja Koivunen (MK) Harvey Bingham (HB) Charles McCathieNevile (CMN) Mark Novak (MN) Regrets Dennis Anson Ian Jacobs ---------------------------------------------------------------------------- ---- Completed Action Items 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 Continued Action Items IJ: Write Danny Weitzner to find out of ecommerce folks (fee links) have requirements on UAs. IJ: Write Danny Weitzner an email about this. ii) Resolved: Make 6.1.11 a priority 2. Agenda Item 3) Navigation/Search Functionality review. Refer to list of checkpoints in the agenda [1] that involve navigation and searching. Editors: Add Cross link in 5.2.4 (and 5.2.6) to 7.3.3. CMN: 7.2.2, 7.2.6 write techniques JG: Techniques for 7.2.2 comment on MN previous work on this checkpoint JG : write checkpoint 7.2.1 techiques JG: contact rob (ms) about 724,5,6; contact rich s (ibm) and peter korn (sun) to get techniques also for checkpoint 7.2.4,5,6 New Action Items 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 Resolutions 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 ---------------------------------------------------------------------------- ---- Minutes jg: reivew his proposal, ---------------------------------------------------------------------------- ---- Checkpoint: Sequential access to active elements 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. Discusssion hb: active element, something script generated, jg: basic access, don't include scripting, bubbling, etc. *Resolved* ---------------------------------------------------------------------------- ---- Checkpoint: Search for an element based on its text content 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: Input Textarea Option Legend Initial list of Attributes of Elements Title Name Summary ALT Discusssion 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)* ---------------------------------------------------------------------------- ---- Checkpoint: Sequential access to all elements 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: DD Definition DIV Division DT Definition term H1-H6 Headers LI List elements P Paragraphs PRE Preformatted text TH Table header TD Table data INPUT Form controls TEXTAREA Form control LEGEND Form label FIELDSET Form divisions CITE Citation text CODE Code text SAMP KBD Keyboard text Discussion 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 ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to access the text information of an element 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. Discussion CMN: This is obvious one *resolve: ok ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to move the focus to a frame from a list 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 up or left arrow next frame in list down or right arrow previous frame in list home first frame in list end last frame in list number keys move to the Nth frame in list enter key move focus to frame in the document Selecting a control moves the focus to that frame in the document. Discussion 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 ---------------------------------------------------------------------------- ---- Checkpoint: Search for a link based on its text content 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. Discussion 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 ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to move to a header from a list Sub groups: Dependent user agents Priority: 2 Techniques 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 up or left arrow next header in list down or right arrow previous header in list home first header in list end last header in list page down move N header forward in the list page up move N header backwards in the list letter keys move to the next header that starts with that letter enter key move focus to header in the document Selecting a link moves the selection to the header in the document. Discussion cmn: don't remove, note that it is related to dom naviagation and move on *resolved: p2 ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to select a link from a list Sub groups: Dependent user agents Priority: 2 Techniques 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 up or left arrow next link in list down or right arrow previous link in list home first link in list end last link in list page down move N links forward in the list page up move N links backwards in the list letter keys move to the next link that starts with that letter enter key move focus to link in the document Selecting a link moves the focus to that link in the document. Discussion cmn: p3 because we already have generic case of moving between actvie elements mg: P2 ja: P2 hg: P2 *resolved: p2 ---------------------------------------------------------------------------- ---- Checkpoint: Direct access to a link from a list of visited links Sub groups: Dependent user agents Priority: 3 Techniques 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 up or left arrow next link in list down or right arrow previous link in list home first link in list end last link in list page down move N links forward in the list page up move N links backwards in the list letter keys move to the next link that starts with that letter enter key move focus to link in the document Selecting a link moves the focus to that link in the document. Discussion cmn: sorting the list, move to techniques ja: agree mg: agree *Resolved: remove this checkpoing, include as a techniques to generic link nav ---------------------------------------------------------------------------- ---- Checkpoint: Direct access to a link from a list of unvisited links Sub groups: Dependent user agents Priority: 3 Techniques 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 up or left arrow next unvisited link in list down or right arrow previous unvisited link in list home first unvisited link in list end last unvisited link in list page down move N unvisited links forward in the list page up move N unvisited links backwards in the list letter keys move to the next unvisited link that starts with that letter enter key move focus to unvisited link in the document Selecting a link moves the focus to that unvisited link in the document. Discussion *Resolved: remove this checkpoing, include as a techniques to generic link nav ---------------------------------------------------------------------------- ---- Checkpoint: Allow the use to move the focus to the first control of a form from a list Sub groups: Dependent user agent Priority: 3 Techniques 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 up or left arrow next next from in list down or right arrow previous previous form in list home first form in list end last form in list number keys move to the N form in list enter key move focus to control in the document Selecting a control moves the focus to that form control in the document. Discussion cmn: moving between forms, should be a p2 ja: agree mn agree *resolved P2 ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to move the focus to a form control from a list Sub groups: Dependent user agents Priority: 2 Techniques 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 up or left arrow next control in list down or right arrow previous control in list home first control in list end last control in list page down move N control forward in the list page up move N control backwards in the list letter keys move to the next control that starts with that letter enter key move focus to control in the document Selecting a control moves the focus to that form control in the document. Discussion cmn: should be p3, specific instance of generic case ja: agree *resolved P3 ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to select a long description of an image from a list Sub groups: Dependent user agents Priority: 2 Techniques 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 up or left arrow next long description links in list down or right arrow previous long links description links in list home first long description links in list end last long description links in list page down move N long description links forward in the list page up move N long description links backward in the list letter keys move to the next long description link that starts with that letter enter key move focus to long description link in the document Selecting a long description label moves the focus to long description link in the document. Discussuion 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 ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to move the selection to a table from a list 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: Common cursor keys up or left arrow next table in list down or right arrow previous table in list home first table in list end last table in list number keys move to the N table in list enter key move selection to table in the document Selecting a control moves the focus to that frame in the document. Discussion cmn p3 hb: p3 mn: p2 ja: p3 *resolved: p3 ---------------------------------------------------------------------------- ---- Checkpoint: Search for the next element with the same attributes as the current element Sub groups: Dependent user agents Priority: 2 or 3 Technique 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. Discussion cmn: p3, general take me to the next thing like this ja: p3 *resolved: p3 ---------------------------------------------------------------------------- ---- Checkpoint: Allow the user to navigate the Document Object Model (DOM) Sub groups: Dependent user agents Priority: 2 Technique 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: Move to the parent node Move to a sibling node Move to a child node 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: View text content of node (is this the same as view children?) View text content of children View text content of the siblings before or after this node in the tree View element attributes of the node View summary information on the number and element type of siblings View summary information on the number and element type of children View summary information on element location in the document tree Discussion 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 ---------------------------------------------------------------------------- ---- Other issues 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 Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess
Received on Wednesday, 5 May 1999 17:25:12 UTC