- From: Leonard R. Kasday <kasday@acm.org>
- Date: Sun, 23 Jan 2000 18:57:56 -0500
- To: w3c-wai-er-ig@w3.org
- Message-Id: <4.2.2.20000123184830.00c386b0@pop3.concentric.net>
These excerpts from a text version of the guidelines. To aid visual
scanning, I've put a pipe symbol in the first column of the original text.
To aid auditory searching, I've preceded my comments with "LRK::", except
for a few places where the only correction is a typo. I've prefixed those
with the word "typo"
=======================
| Introduction
|
| The Web Accessibility Initiative (WAI) produced a foundation document, The
TYPO ^has
| WAI Web Content Accessibility Guidelines, that describes what must be done
| to make an HTML page accessible to all. This document trys to make clear
TYPO tries
| that the WWW should enable everyone, especially those with disabilities.
TYPO to do what? ^
| To determine if a web site is accessible to everyone, it is important to
| have functional, friendly and free tools for site evaluation and, if
| possible, repair of problems that may be uncovered. This document describes
TYPO omit "of"
| It is important that evaluation and repair tools themselves be accessible.
| Many people using these tools may be new to this technology and will
| require software programs that are easy to use while not condescending in
| tone. Is also important that the evaluation tool does not generate
| excessive warnings or false positive accessibility errors to avoid the 'cry
| wolf' syndrome.
LRK:: Issue. Should we be more specific about "cry wolf"? Perhaps in
contents?
| This document is based on The WAI Web Content Accessibility Guidelines. It
| examines each checkpoint in the guidelines and provides one or more
| techniques for the implementation of that checkpoint. Each implementation
| Technique contains the following items:
|
| Title:
| The WAI guidelines checkpoint
| Definition:
| A technique to check for checkpoint compliance
| Discussion Status:
| Awaiting discussion, under discussion, discussion complete
| Evaluation:
| The HTML element(s) that must be examined
LRK:: Add ", and algorithms and heuristics used to examine them"
| Example Language:
| Messages displayed to the author if a problem is found
LRK:: Change to "Example of a message displayed.
| Repair Techniques:
| Methods for repairing the HTML code
| Test Files:
| Used to test evaluation tools to see if they find the accessibility
| problem
| Discussion Files:
| Discussion and comments on the technique
LRK:: Add "Note that this document specifies only the function of
evaluation of repair tools. Nothing in this document should be taken to
imply a particular user interface."
LRK:: This is a cross group issue. We need a way for an author to indicate
that a warning has been checked. E.g. after the author has asserted that
no LONGDESC is needed for an image, the warning shouldn't pop up with every
subsequent use of the tool when that image is encountered. This could be
done, for example, with special comments inserted in the html, analogous to
the comments which turn off warning messages when a C program is run
through Lint.
==================
| Technique 1.1.B [priority 1] Check images for LONGDESC and descriptive link
|
| Discussion Status:
|
| * under discussion
|
| Evaluation:
|
| * IMG element should have a valid LONGDESC attribute and a descriptive
| link if the image is complex and is not described in the document.
LRK:: How do we check if image is "complex"?
|
| Images that do not require a LONGDESC or descriptive link:
|
| * bullets
LRK:: Add "See Appendix J"
| * horizontal rules
LRK:: Add "See Appendix K"
==================
| Technique 1.1.C [priority 1] Check input buttons that use an image for ALT
| text
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * If an INPUTelement has a TYPE attribute with a value of "image" then
TYPO: ^
| it must also have a valid ALT attribute.
LRK:: This mostly is same as 1.1.A. Instead of repeating it, just point
there and describe any differences (the only difference I can think of is
that the acceptability of null text when there is text next to image inside
anchor doesn't apply, i.e. <A ...> <IMG ALT=""> some text </A> which
should be OK in 1.1.A doesn't apply here. Other rules are same.
==================
| Technique 1.1.D [priority 1] Check applets for ALT text
|
|
| Evaluation:
|
| * APPLET element must have a valid ALT attribute.
LRK:: Is this needed if the user, in accordance with 1.1.E, has code
before </applet> that shows up when
user agent skips applets?
|
| Valid ALT attribute text:
LRK:: replace list with reference to 1.1.A
==================
| Technique 1.1.E [priority 1] Check Applets for alternative content
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Between the APPLET start element and APPLET end element must be a
| valid text element or a valid link to a URI.
LRK:: Replace with "Any HTML". However, tool must then (recursively) apply
all tests to that HTML.
==================
| Technique 1.1.F [priority 1] Check objects for alternative representation
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Between the OBJECT start element and OBJECT end element must be a
| valid alternative representation element.
|
| Valid alternative representation element:
LRK:: Same comment as for applets. Alternative content can be any HTML,
but all technique tests must recursively be applied.
==================
| Technique 1.1.G [priority 1] Check frames for an associated LONGDESC file
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * FRAME elements should have a valid LONGDESC attribute if the frame
| title does not completely describe the frame content.
LRK:: We can't automatically check if title "completely
describes...". This warning must always be offered. See issue above about
turning off the warning when the author has fixed it.
| * If FRAME does not have a LONGDESC attribute, ask user if frame
| contents are complex and requires one.
|
| Valid LONGDESC file name:
|
| * Must not be NULL
| * Must be a valid URI
LRK:: The tool should then check the file that is pointed to.
|
==================
| Technique 1.1.H [priority 1] Check AREA elements for ALT text
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * AREA elements must have a valid ALT attribute.
LRK:: refer to above discussion of ALT text in 1.1.E
|
|
==================
| Technique 1.1.I [priority 1] Check if audio files have an associated text
| transcript
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * If the target of an A element is a sound file then ask the user if
LRK:: shouldn't use word "target" since that has special meaning. Use "href".
| there is an existing text transcript file.
LRK:: it doesn't have to be a text transcript file. The text can be on the
page in which the A element resides.
==================
| Technique 1.1.J [priority 1] Check SCRIPT element for associated NOSCRIPT
| element
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Following a SCRIPT end element, there must be a NOSCRIPT element.
| * The NOSCRIPT start and end elements must contain at least one valid
| text element.
LRK:: must contain HTML which when rendered must produce at least one word
of text. This e.g. allows an image with ALT text. Also, the tool must
check the HTML per this document.
|
| Valid text element:
|
| * Must contain at least one word of text
| * Suspicious - ALT attribute value is placeholder NOSCRIPT text.
|
| Example Language:
|
| * Language for missing NOSCRIPT: Missing NOSCRIPT element for this
| SCRIPT element.
|
| Repair Technique:
|
| * Prompt user for text description of script. Insert a NOSCRIPT section
| after the SCRIPT with the script description text.
LRK:: Don't limit to text description. Prompt for HTML that is
functionally equivalent. This may be, for example, a list of links, form
input to CGI, etc.
==================
| Technique 1.1.K [priority 3] User notification for ASCII art
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| All BODY elements will generate a user notification.
|
| Note: We are still working on methods of determining if a document contains
| ASCII art. If we can't find a suitable algorithm that finds ASCII art then
| all pages will get a notification.
LRK:: cf. rules rules described in
http://www.w3.org/WAI/ER/IG/ert/AsciiArt.htm
And statistical tests mentioned in
http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Jan/0006.html
==================
| Technique 1.2.A [priority 1] Prompt user for text links if ISMAP used.
LRK:: There's also the case where the same map has a USEMAP, i.e. a client
side image map. If that's the case, just test for accessibility of the
client side map.
==================
| Technique 1.3.A [priority 1] User Notification for audio description.
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Any multimedia object will generate a user notification
LRK:: define multimedia.
|
| Example Language:
|
| * Multimedia presentations should have an associated audio description.
LRK:: Audio description not always necessary for multimedia. What if the
multimedia object can be fully described with ALT text or text in the document?
|
==================
| Technique 2.1.A [priority 1] User notification for color use
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| Display a user notification if the document contains any of the following
| elements:
|
| * IMG
| * APPLET
| * OBJECT
| * SCRIPT
| * INPUT
LRK:: Also generate if text color is controlled by FONT or CSS.
LRK:: Also generate if text contains any color names.
|
==================
| Technique 3.1.A [priority 2] User notification for appropriate markup
| language
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * All BODY elements will generate a user notification.
LRK:: since this checkpoint only refers to images, why notify for all BODY
Elements? Why not just Images?
Also, I don't understand what "All body elements" mean. There is just one
"Body Element" since that term means the start tag, end tag, and everything
in between. Do you mean all elements that are part of the Body Element's
content?
==================
| Technique 3.2.A [priority 2] Check document for public text identifier
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * The first line of the document must be a valid public text identifier
| if the document being validated is an HTML document.
| * A valid public text identifier is... (Haven't got precise definition.
| Anybody know for sure?)
| * The document is an HTML document if there is an HTML element near the
| start of the document and there is an HTML end element as the last
| non-whitespace text in the document.
LRK:: (minor language thing) you mean HTML TAG, not element. The "element"
includes the start tag end tag, and everything in between. At least, that
what it is in XML...
LRK:: the HTML start and end tags are optional. See
http://www.w3.org/TR/html4/struct/global.html#h-7.1
So, hmmm, what do we do? Perhaps check MIME type off the server where it
will be used.
|
=======================
| Checkpoint 3.3 - Use style sheets to control layout and presentation
| Technique 3.3.A [priority 2] Check document for use of style sheets. Notify
| user if they are not used.
LRK:: only notify user if color or font attributes appear somewhere, to
avoid crying wolf to someone wants to just present classic unadorned page.
==================
| Technique 3.4.A [priority 2] Check document for relative or absolute units.
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * [incomplete]
|
| Example Language:
|
| * This element uses absolute units of measure rather than relative units
| of measure.
|
| Repair Technique:
|
| * Allow user to change the units of measure.
LRK:: what if the absolute units are in a style sheet?
|
==================
| Technique 3.5.A [priority 2] Check document for header nesting
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Header elements (H1-H6) should be checked to ensure they are neste
| according to the following rules
| 1. The first header element in the document must be H1
| 2. There must be only one H1 element in the document
LRK:: Why only one H1? It isn't part of the HTML4 spec , as far as I can
see in http://www.w3.org/TR/html4/struct/global.html#h-7.5.5
LRK:: HTML4 also allows skipped levels. The spec merely says
"Some people consider skipping heading levels to be bad practice. They
accept H1 H2 H1 while they do not accept H1 H3 H1 since the heading level
H2 is skipped."
We should point out that we don't skip levels because of accessibility reasons.
So actually we have a problem with WCAG: it doesn't define "and use them
according to specification".
==================
| Technique 3.5.C [priority 2] User notification of improper header use
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * If the document contains any Header elements (H1- H6) that contain a
| text string longer than 20 words then a user notification is
| presented.
|
| Example Language:
|
| * Header elements (H1 - H6) should be used to define headers and should
| not be used for formatting text.
|
| Repair Technique:
|
| * Allow the user to convert any header text to another type. Possible
| types are:
| 1. Paragraph
| 2. Blockquote
|
| ------------------------------------------------------------------------
|
| Checkpoint 3.6 - Mark up lists and list items properly
LRK:: what does WCAG's "properly" mean, beyond passing HTML validity?
|
| Checkpoint 3.7 - Mark up quotations. Do not use quotation markup for
| formatting effects such as indentation
|
==================
| Technique 3.7.A [priority 2] Check document for missing quote markup
LRK:: Unfortunately, all major browsers, NN, MSIE, and Opera, ignore the
rendering spec in HTML4:
Visual user agents must ensure that the content of the Q element is
rendered with delimiting quotation marks.
(cf http://www.w3.org/TR/html4/struct/text.html#h-9.2.2)
So if you follow the command in HTML4 to not put quotation marks at the
beginning and end of the content of a Q element.
Then the poor visually oriented user sees no quote marks.
And the user with a screen reader gets no quote marks either, and there's
less chance that it will recognize <Q> than quote marks.
So in practice <Q> is not presently usable per spec. This rule may be OK
from a pure HTML point of view but it isn't really practical given the
state of browsers today.
|
| Checkpoint 5.2 - For data tables that have two or more logical levels of
| row or column headers, use markup to associate data cells and header cells
LRK:: not needed if the HTML4 Algorithm
http://www.w3.org/TR/html4/struct/tables.html#h-11.4.3
can identify the headers. This is a WCAG issue.
|
| Technique 5.3.A [priority 2] User notification of using tables for layout
|
| Discussion Status:
|
| * under discussion
|
| Evaluation:
|
| * A TABLE element will trigger this evaluation.
| * The table must have more than one column.
| * This technique applies only to tables used for layout purposes, not to
| data tables.
|
| Example Language:
|
| * Tables used for layout should make sense when linearized.
| * When a table is 'linearized' the cells are usually read a row at a
| time, starting at the left and moving to the right.
LRK:: use definition: Linearization means reading the cells in the order
they appear in the HTML source.
|
==================
| Technique 5.5.A [priority 3] Check table for valid SUMMARY
|
| Discussion Status:
|
| * discussion complete
LRK:: I don't understand this guideline. Isn't a caption enough and Table
headers enough, at least if it's a simple table? A summary would merely
recite what's in the caption and headers anyway. This is a WCAG issue.
==================
| Technique 5.6.A [priority 3] Check table for header abbreviations
|
| Discussion Status:
|
| * under discussion
|
| Evaluation:
|
| * TH elements should have a valid ABBR attribute if the header name is
| greater than 15 characters.
|
| Valid ABBR attributes:
|
| * Not allowed - NULL ABBR value ("")
| * Not allowed - ABBR value of spaces (" ")
| * Suspicious - ABBR value of placeholder ABBR values
| * ABBR values should be shorter than 15 characters.
LRK:: The ABBR should be pronounceable, since the purpose is to be read by
speech technology in the future
(cf. http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#data-tables )
==================
| Technique 6.1.A [priority 1] User notification of style sheet use.
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * A LINK element with a REL attribute set to 'stylesheet' will generate
| this notification.
LRK:: Also: if tags have style attribute set, or <STYLE> element is
used. (WCAG issue)
==================
| Technique 6.2.B [priority 1] User notification of dynamic content changes
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * SCRIPT elements will generate this user notification
LRK:: also, any Javascript, e.g. onmouseover=".... code which changes
something somewhere..."
==================
| Technique 6.3.A [priority 1] User notification of usability when
| programatic objects are disabled.
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Any programatic object will generate this user notification.
| * Programatic objects are: scripts, objects, or embeds
LRK:: or any javascript e.g. attached to onclick, onmouseover, etc.
==================
| Technique 6.4.A [priority 2] User notification of device independent event
| handlers.
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Any programatic object will generate this user notification.
| * Programatic objects are: applets, scripts, objects, or embeds
LRK:: or any javascript attached to onclick etc...
|
==================
| Technique 6.5.A [priority 2] Check if there is a NOFRAMES section after a
| FRAMES section.
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Immediately following a FRAME end element must be a NOFRAMES element.
|
| Example Language:
|
| * No NOFRAMES section following a FRAME section.
|
| Repair Technique:
|
| * Allow user to construct a NOFRAMES version of the document.
LRK:: content of the NOFRAME must be checked.
|
==================
| Technique 7.1.A [priority 1] User notification of potential screen flicker
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Any of the following elements will generate this user notice:
| o APPLET
| o OBJECT
| o SCRIPT
| o EMBED
| * IMG elements will generate this user notice if they are of the type
| 'animated gif'.
LRK:: Desirable to actually measure flicker. This could be done e.g. by
software that renders, takes screenshots and compares. Note that this is
not a requirement for release one of APROMPT .. nor is anything else in
this document <smile>
|
| Example Language:
|
| * Display flicker is distracting and may be dangerous to some users.
| Please ensure this element does not cause the display to flicker.
LRK:: how do we quantitatively distinguish between flicker and slow changes
in images? Is it the 4-59 hz in wcag? What does "quick changes"
mean? Would "quick changes" mean that you can't bring up a new screen,
which is a quick change? How big does the area have to be to cause
trouble? (WCAG issue)
==================
| Technique 7.3.B [priority 1] Remove any scripts that cause text to scroll
|
| Discussion Status:
|
| * under discussion
|
| Evaluation:
|
| * Find any SCRIPTS that cause text to scroll. These scripts can be
| distinguished by (see discussion)??
LRK:: see above remark about software that renders, takes screenshots, and
compares.
==================
| Technique 7.4.A [priority 2] Remove auto-refresh attributes from META
| elements
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * If a META element has a HTTP-EQUIV attribute and the value of that
| attribute is "refresh" then check if the element has a 'CONTENT'
| attribute.
| * If the META element has a CONTENT attribute then check if the value of
| that attribute is a URL.
| * If the CONTENT attribute does not have a value of a URL (will contain
| the string "URL=") then it is an auto-refresh page and the HTTP-EQUIV
| and CONTENT attributes should be removed from the META element.
|
| Example Language:
|
| * This page uses auto-refresh which can make the page difficult to read
| for some people.
|
| Repair Technique:
|
| * Allow user to remove the auto-refresh from the document.
|
| Test Files and Discussion Files:
|
| * Link to test file for this technique.
LRK:: another ditto on remark about software that renders, screenshots, and
compares...
==================
| Technique 8.1.A [priority 1 if functionality is important and not presented
| elsewhere, otherwise Priority 2] User notification if programmatic elements
| used
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Search the document for any of the following elements: OBJECT, APPLET,
| EMBED or SCRIPT.
|
| Example Language:
|
| * This element may not be accessible to all users. Please ensure there
| is an accessible interface to this object.
|
| Repair Technique:
|
| * If any programmatic elements are found in the document, provide a user
| notification:
LRK:: tool should include means to test the embedded technologies, e.g.
java, at least by running them, preferably by including any test software
supplied for the technology.
|
| ------------------------------------------------------------------------
|
| Guideline 9. Design for device-independence
|
| Checkpoint 9.1 - Provide client-side image maps instead of server-side
| image maps except where the regions cannot be defined with an available
| geometric shape
LRK:: or combinations of shapes pointing to same URL (WCAG issue)
|
==================
| Technique 9.1.A [priority 1] User notification of server-side image map use
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * IMG element is a server-side image map if it contains an ISMAP
| attribute.
|
| Example Language:
|
| * Use client-side image maps instead of server-side maps.
|
| Repair Technique
|
| * Allow the user to convert the server-side image map to a client-side
| image map.
|
| Test Files and Discussion Files:
|
| * Link to test file for this technique.
LRK:: are there any common formats for the server side information? If so,
provide means to convert to client side image map.
==================
| Technique 9.3.A [priority 2] User notification of logical event handlers
| for scripts
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * Any SCRIPT element will generate this user notification
LRK:: also attributes such as "onclick" ?
|
| Example Language:
|
| * For scripts, specify logical event handlers rather than
| device-dependent event handlers.
|
| Repair Technique
|
| * None
|
| Test Files and Discussion Files:
|
| ------------------------------------------------------------------------
|
======================
| Checkpoint 9.4 - Create a logical tab order through links, form controls,
| and objects
LRK:: always shown?
|
| ------------------------------------------------------------------------
|
=====================
| Checkpoint 9.5 - Provide keyboard shortcuts to important links
LRK:: always shown?
|
| ------------------------------------------------------------------------
====================
| Guideline 10. Use interim solutions
|
| Checkpoint 10.1 - Until user agents allow users to turn off spawned
| windows, do not cause pop-ups or other windows to appear and do not change
| the current window without informing the user
|
==================
| Technique 10.1.A [priority 1] Check anchors for 'new window' attributes
|
| Discussion Status:
|
| * awaiting discussion
|
| Evaluation:
|
| * A element opens a new window if it has a TARGET attribute with a value
| of "_blank" or "_new".
LRK:: actually, any target attribute will create window with that name if
it doesn't already exist.
|
| Example Language:
|
| * This Anchor element [anchor text] will open a new window that can be
| disorienting for some users.
|
| Repair Technique:
|
| * Allow the user to remove the 'new window' attribute from the anchor.
|
| Test Files and Discussion Files:
|
| * Link to test file for this technique.
| * Link to discussion on this technique.
|
| ------------------------------------------------------------------------
|
========================
| Checkpoint 10.2 - Until user agents support explicit associations between
| labels and form controls, for all form controls with implicitly associated
| labels, ensure that the label is properly positioned
LRK:: what are positions?
Suggestion: labels for radio buttons and checkboxes appear after
labels for text fields appear in front.
Putting labels for radio buttons and checkboxes first may seem
inconsistent, but it's needed for reasonable visual rendering, it's the
most common, and it's more important to stay with what a blind user expects
than to change it in just a few places.
|
=====================
| Checkpoint 11.1 - Use W3C technologies when they are available and
| appropriate for a task and use the latest versions when supported
LRK:: This is a wcag issue. Must we insist on W3C technologies if there
are other standards with good accessibility?
AFter all in the authoring guidelines we ask for accessibility in the
non-w3c technologies implementing the editor.
======================
| Checkpoint 11.4 - If, after best efforts, you cannot create an accessible
| page, provide a link to an alternative page that uses W3C technologies, is
| accessible, has equivalent information (or functionality), and is updated
| as often as the inaccessible (original) page
|
| (Should we notify user of this? For every page?)
LRK:: again, why insist on W3C?
====================
|
| Checkpoint 13.1 - Clearly identify the target of each link
|
| (Search for text string 'click here'? Perhaps display all the anchor text
| and ask user if they are all clear?)
LRK:: I like that
=======================
|
| Checkpoint 14.3 - Create a style of presentation that is consistent across
| pages
|
| (Can't be machine checked. User notification?)
|
| ------------------------------------------------------------------------
|
| Document Rating
|
| After evaluating a document, an evaluation and/or repair tool should
| provide the user with a document rating. The rating is based on conformance
| to the WAI Page Authoring Guidelines and will be:
|
| * Level "A": all Priority 1 checkpoints are satisfied;
| * Level "Double-A": all Priority 1 and 2 checkpoints are satisfied;
| * Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied;
|
| Some checkpoints can not be checked by a software program and will require
| user evaluation. The user must be informed of the items that they must
| check.
LRK:: Link to or incorporate algorithm at
http://www.w3.org/WAI/ER/IG/rating/
========================
|
| Appendix L - Links To Associated Sites
|
| * Bobby - Accessibility evaluator tool
| * Lynx Viewer - Displays a text-only view of web pages
| * A-Prompt - Accessibility evaluator and repair tool
LRK:: The Wave (when LRK puts it on the web)
|
| ------------------------------------------------------------------------
|
-------
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University
423 Ritter Annex, Philadelphia, PA 19122
kasday@acm.org
http://astro.temple.edu/~kasday
(215) 204-2247 (voice)
(800) 750-7428 (TTY)
Received on Sunday, 23 January 2000 18:54:25 UTC