W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 1999

MINUTES: W3C WAI User Agent Telecon 5 May 1999

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Wed, 05 May 1999 16:30:19 -0500
Message-Id: <199905052125.QAA25047@staff1.cso.uiuc.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:48:57 GMT