W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for May 5th, 1999


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


Agenda

Update on Outstanding Action Items

Discussion

Navigation checkpoints


Attendance

Chair: Jon Gunderson (JG)

Scribe: Jim Allan (JA)

Regrets


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

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:

Initial list of Attributes of Elements

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:

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

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

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

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

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

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

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

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

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

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:

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:

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


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.