Re: Comments on WD-WAI-PAGEAUTH-19980908

thanks for your comments, Harvey.  our responses follow.

>Abstract:
>P1 S1 
>This document is a list of guidelines that page authors 
>[HB: What are "page authors?"  We presume much.]
>
we will define.

>P1 S2 
>Tools that generate documents in HTML (authoring tools, file conversion
>packages, or other products) should produce documents that _make it easy
>for authors to_ follow these guidelines. 
>
>[HB: Do you include HTML 2.0, HTML 3.2, HTML 4.0? Do you intend these to
>apply for text delivery documents produced in XML applications?]
>
addition made.

>A. Make sure pages transform gracefully across users, techniques, and
>situations
>
>A.1. Provide alternative text for all images, _scripting objects_
>XappletsX, and image maps. [Priority 1]
>
>[HB: Strict HTML 4.0 eliminates applet, by generalizing to objects that
>provide scripting. The Applet element type remains in transitional HTML 4.0.]
>
what do you mean by "scripting object?"
while the applet element is deprecated, applets themselves can still be
embedded in a page using OBJECT.  also, applets aren't necessarily
"scripted" since some form of "compilation" occurs.  Per previous comments
from Daniel, we have defined our use of image, image map, and applet in a
way that will allow us to use these terms in the guidelines, even as
technologies change.

>A.2.
>Techniques: 
>LI1, bulleted LI2  
>
>[HB: ... what are "(or invisible d-links)"? Those without
>the "d"? or one pixel color same as text ones positioned over text, or
>colored same as background placed where background is? Page authors
>have many choices. Or is your intent that we shouldn't suggest to page
>authors ways to hack?
>
we have had many questions about invisible d-links.  We will include
further discussion in the techniques document.  Basically, it is a small
image (1 pixel) or transparent image used as a link whose alt-text is
"D-link" or "D."  It is an attempt to solve the issue of people not wanting
to use d-links because having a "D" next to a graphic disrupts the visual
presentation.  If images are not loaded, the "invisible d-link" is now
visable.  (Note.  the alt-text could be anything you wish, we have used it
several different ways...just as it is with "visible d-links" it depends on
the author's preferences.)

>A.4.
>P1 S1: If the visual presentation is associated with an auditory
>presentation (e.g., for a movie), synchronize the audio
>version of the descriptions with the existing auditory presentation and
>collate the text version of the
>descriptions with the text transcript (captions) of the primary audio
>track. _Synchronization depends on references to unique ID values on
>elements (at least for SMIL 1.0) so provide them on all significant
elements._
>
>P1 I believe you should supply a reference on the color-blindness. 
>The following by Greg Lowney "But can they read it?" is buried in a 
>frame but is a good start.
>
>http://msdn.microsoft.com/developer/news/devnews/julaug98/access7.htm
>
this is something for the techniques document, since we can not link to
non-normative references from the guidelines.

>A.11.
>P1 S1: Someone who is using the page without sight, with voice input, or
>with a keyboard (or input device other than a

>mouse _or other pointing device_) will have a difficult time navigating a
>page if operation requires a pointing device.
>[aside: I use a touch pad or accupoint button.]
>
how about, "(or input device other than a pointing device, e.g., a mouse)
will have a difficult time navigating a page if operation requires a
pointing device."

>A.12. _LI6_
>_6. Enable audible icons (earcons) from a user profile to denote 
>significant items of information or events._
>
is this a user agent issue?
what assistive technology or browser shortcoming does this temporarily fix?

>B.1.
>LI2 Singular "longdesc" but plural "d-links or invisible d-links"
>Suggest the latter be "d-link or invisible d-link." 
>
done.

>[HB: Here again the "invisible d-link" appears. Tabbing to an invisible 
>d-link would seem to leave any user, not just low-vision or blind user, 
>clueless about the link.]
>
well, with alt-text associated with it they will be as clueless as they are
with "visible" d-links.  <grin> since, as is the case with all d-links,
there is no clear indication which image the d-link is attached to.

>B.3. Ensure that tables (not used for layout) have necessary markup to be
>properly
>  restructured or presented by accessible browsers and other user agents.
>[Priority 1]
>
>[HB: (not used for layout) above suggests that tables used for layout
>needn't use markup (attributes) to be properly restructured or presented.
>The words in A.6. permit layout tables. Nothing is said about using
>or describing parent table structure as metadata about a table nested
>in another one.]
>
how would you mark up a table used for layout to make it more accessible?

>P2 These guidelines benefit users that are accessing the table through
>auditory means or viewing only a portion of
>the page at a time (e.g., users with blindness or low vision, users with an
>auto-pc or using devices with small
>displays, etc.). 
>
>[HB: What is an auto-pc? one in a car? one that is just an audio connection?
>an automatic-pc? Do you mean a device that uses text to speech?]
>
the Auto PC is a Microsoft product.  it uses speech input and output for
hands and eyes free "in-vehicle computing."

>C.1.
>LI3: [HB: Applet is a deprecated element type.]
>
correct. what are you suggesting?

>C.3.
>LI2: 2. Create a bundled version of all pages that _comprise_ XcomposeX the
>document. [Priority 3] 
>
good fix, done.

>C.4. 1.Use an automated accessibility, browser and HTML validation tool,
>such as Bobby_, available at http://www.cast.org/bobby/_. [Priority 3] 
>
this URL and specific reference to Bobby are found in the techniques.

--the editors

Received on Thursday, 17 September 1998 14:09:32 UTC