Comments of AUTrialRecs.html (May 28)

>    * providing guidance and information in help files and documentation

I'd move this one at the end of the list.

> The remaining recommendations have been listed in abbreviated form.

Should say if it's a permanent status of just an issue with the
current version here rather than later on.

>   1. IMG Element
>   2. Special Case: Server-Side Image Map
>   3. INPUT Element of type Image
>   4. Suggested Tools and Utilities

I think ALT for AREA in Client-Side Image Map should be mentioned here 
as well.
 
> 1. IMG Element
> 
>    * Wherever they appear, the ALT text and LONGDESC attributes will be
>      emphasized

It's unclear what "appear" means here.

The usual situation is one of a page author dropping an image from the 
desktop onto her HTML editor.

How does this first guideline match this situation ?

>    * If the ALT attribute remains either empty or default-valued after
>      insertion or editing, then: EITHER (1) an application dialog warning
>      will be displayed and acknowledged before authoring can continue OR (2)
>      a conspicuous underlining, outlining, or other identification of the
>      offending element will be rendered in the document. Both methods must
>      provide the following functionality: a short description of the
>      problem, a link to a longer description in the Help area, and a link
>      either to the image attributes, properties dialog or correcting
>      utility.

Yes.
 
> Sample Warning Text
> 
> "HTML Syntax Error: Images must include ALT text.  Descriptive Text may also
> be used to increase universal accessibility."

I'd still like to add a couple of specific examples to increase the
interest of the author.
   "... universal accessibility (screen reader, web phone, etc)" 

> Important Points for Help File Text
> 
>    * Use of the ALT text attribute is required.

maybe add "is required in HTML4"

>    * Images are the most common inaccessible elements on the web
>    * Screen readers, used by people with different visual disabilities,
>      often cannot access the image content including any words.

definitively talk about web phone here.

>   3. If the image is placed within an anchor, then the destination of the
>      anchor is important. For example, using a label such as "home" or
>      "help" would be more informative than a description of the button's
>      visual appearance.

How about in that case having the authoring tool "fetch" the ALT from
the TITLE element (not attribute) of the target HREF ?

>   4. If the image is an empty space-holder that provides no information to a
>      sighted user, then empty quotation marks should be entered as
>      ALT text.

Let's make clear we want to end up with ALT="" and not """".

ALT should be the empty string might be better phrased.

>   7. In situations where a longer description is required (charts,
>      illustrations and other vital information), a short ALT text
>      description should still be included with the image along with a long
>      descriptive text link. This description is usually placed in a separate
>      file which is identified by the LONGDESC attribute of HTML 4.0 or by a
>      small D-link anchor or graphic following the image.

I think the D-link should be handled by the author herself, and the
guideline here should only mention LONGDESC.

> 2. Special Case: Server-Side Image Map
> 
>    * Wherever it appears, the ALT text attribute will be emphasized.

same remark, "appear" is kind of vague.
 
>    * If the ALT attribute for a ISMAP IMG remains either empty or
>      default-valued after insertion or editing, then: EITHER (1) an
>      application dialog warning will be displayed and acknowledged before
>      authoring can continue OR (2) a conspicuous underlining, outlining, or
>      other identification of the offending element will be rendered in the
>      document. Both methods must provide the following functionality: a
>      short description of the problem, a link to a longer description in the
>      Help area, and a link either to the image attributes, properties dialog
>      or correcting utility.
>    * A brief warning should state that Client-Side Image Maps are considered
>      more universally accessible.

Authors do not know what client-side vs server-side means.

Again, the usual scenario is one of an author making "sensitive" an
image in her HTML document by selecting the image and then clicking on 
"make a map" or something like that.

Then the authors goes into creation sensitive zones: rectangles,
circles, etc.

At that point, client-side map should be generated, and not
server-side.

That's the guideline.

If the author overrides this tool policy, then it is assumed that she
knows what client/server means and the warning should be presented.

> 1. Style and Structure
> 
>    * Editor  includes HTML 4.0 and CSS1 syntax validation capability.
>      (Deprecated elements will not be produced or validated.)

I'm afraid this is too strict. Authors cannot rely on CSS1 being
everywhere and they will have to use deprecated presentational markup
if they feel it's necessary for their business.

If they was a priority scheme, this could be a recommended.

> 4. Tables
> 
>    * Implement a TABLE editor with built in accessibility support.
>      Emphasize semantic structure.
>    * Ensure table cells are explicitly associated with row and column
>      labels.
>    * Ensure tables are not used to arrange text documents in columns.
>    * Ensure tables are not used merely for the purposes of page layout (use
>      style sheets instead).

This is going to be a hard-sell, they almost all use table for layout
today...



Can you remind why there is no prioritization scheme in this guideline 
while there is one in UA and GL ?

Received on Friday, 5 June 1998 08:54:53 UTC