Techniques Document

> [PRIORITY 1]
>      This technique must be implemented by an author, or one or more groups
>      of users will find it impossible to access information in the document.
>      Implementing this technique is a basic requirement for some groups to
>      be able to use WWW documents.
> [PRIORITY 2]
>      This technique should be implemented by an author, or one or more
>      groups of users will find it difficult to access information in the
>      document. Implementing this technique will significantly improve access
>      to WWW documents.
> [PRIORITY 3]
>      This technique should be implemented by an author to make it easier for
>      one or more groups of users to access information in the document.
>      Implementing this technique will improve access to WWW documents.

I think the priority wording should be different than for Guidelines. 

In fact, it is confusing to use the same term (Priority) as for the
guidelines.

I'd prefer if we use [1st Choice] or [Preferred] [Advised].


> Structure vs. Presentation
> 
> Distinguishing the structure of a document from how the content is presented
> offers a number of advantages, including improved accessibility,
> manageability, and scalability. The next two sections identify (by theme)
> precisely those elements and attributes considered structural (and some of
> their uses) and those that are considered to control presentation. The
> section on style and style sheets discusses how to use CSS to accomplish the
> same tasks as the presentation elements and attributes.

If this is a tutorial that can help with techniques, but not
techniques, we should consider moving it in Annex.
 
> Elements and attributes that are deprecated in HTML 4.0 are marked up in
> this document and followed by an asterisk (*).

We could say that most presentational elements are deprecated in 4.0.

> 
> Structural elements

I would carry the attributes under the same section.
  Structural elements and attributes

> Presentation elements
> 
> Style sheets
>      STYLE

If the message is that presentation element is bad, we should consider 
moving this one in structure, which it is, considered under the angle
where it *announces* style.

> To implement long descriptions, use the "longdesc" attribute
>      In HTML 4.0, applies to almost every element

Cut&paste typo here I guess.

> In the next example, we specify a tabbing order among elements (in order,
> "field1", "field2", "submit"):
> 
> Example.
> 
>    <INPUT tabindex="1" type="text" name="field1">
>    <INPUT tabindex="2" type="text" name="field2">
>    <INPUT tabindex="3" type="submit" name="submit">

better use an example that's not the default behavior.

> Deprecated example.
> 
> <DL>
>    <DD><IMG src="star.gif" alt="Item">Audrey
>    <DD><IMG src="star.gif" alt="Item">Laurie
>    <DD><IMG src="star.gif" alt="Item">Alice
> </DL>

Is alt="*" OK ?

> <UL>
>    <LI class="newbullet">Roth IRA <SPAN class="newtext">New</SPAN>
>    <LI 401(k)
> </UL>

unfinished markup
 
> Tables
> 
> Users may make tables more accessible in a number of ways:

Page authors is better than Users.

> Example.
> 
>    <OBJECT data="97sales.gif" type="image/gif">
>           Sales in 1997 were down subsequent to our
>           anticipated blah blah blah...
>    </OBJECT>

Also show the example where the longdesc is a dlink within the
content.

    <OBJECT data="97sales.gif" type="image/gif">
           Chart of our Sales in 1997. 
           A <A HREF="desc.htm">textual description</A> is available.
    </OBJECT>

> <SPAN alt="smile" title="smiley in ascii art">:-)</SPAN>

No ALT on SPAN, can use class=smile instead.
 
> Server-side image maps
> 
> When a server-side image map must be used, authors should provide an
> alternative list of image map choices. There are three techniques:
> 
>    * If an alternative list of links follows the image map, authors should
>      indicate the existence and location of the alternative list. If IMG is
>      used to insert the image, provide this information in the "alt"
>      attribute. If OBJECT is used, provide it in the "title" attribute.

Mention that INPUT image are server side image map as well.

>   <STYLE type="text/css">
>         HR.redline { color : red }
>    </STYLE>
>    <IMG class="redline" title="End of Chapter 7 - Visual Displays">
>    <H1>Chapter 8 - Auditory and Tactile Displays</H1>

You mean HR, not IMG

> For reasons of orientation, frames should all be named (with the "name"
> attribute) even if they are not potential targets for updated content.
> 
> Example.
> 
> <FRAMESET cols="10%,90%"
>           title="Our library of electronic documents">
>     <FRAME src="nav.html" name="navbar" title="Navigation bar">
>     <FRAME src="doc.html" name="doc"    title="Documents">
>     <NOFRAMES>
>        <A href="lib.html" title="library link">
>              Select to go to the electronic library</A>
>     </NOFRAMES>
> </FRAMESET>

Is the FRAME name an abbreviation of its title ?
 

> and the user agent is not displaying frames, the user will have access (via
> a link) to a non-frames version of the same information. Furthermore, we can
> build main.html so that if frames are being supported, main.html does not
> show a table of contents (since top.html does), and if frames aren't being
> supported, it does not:
> 
>    <!-- This is main.html -->
>    <HTML>
>      <HEAD>...</HEAD>
>      <BODY>
>      <NOFRAMES>
>            ...the table of contents when frames not supported...
>      </NOFRAMES>
>           ...the rest of the document, always available...
>      </BODY>
>    </HTML>

When I read that I thought, this is bogus, NOFRAMES can only be used
in the FRAMESET section of a frameset document. 
But when I checked the HTML4.0 DTD, I found that the Transitional DTD
support NOFRAMES as a regular block.

I wonder where are described the semantics that you present here
(HTML 4 only mentions the frameset case), but I guess they are
correct. 
 
> the initial title of the frame ("Apples") will no longer match the current
> content of the frame ("Oranges").

How is this different from saying "Frame title=TOC" and later on
loading an index in the frame ?

I guess my point is we should recommend that frame title/name are
stable and that we should drop this guidelines specific to images
(but mentions longdesc support when we talk about image longdesc)
 
> Authors should not open windows or change active windows (e.g., by
> specifying a new window as the target of a frame with target="_blank")
> unless the user is aware that this is happening.

Actually, anything that is not a known target will create a new
window.

[I already raised this bug in HTML before: UI effect should not be
specified in the markup (this is similar in nature to saying Button2
spawns a new window, which has nothing to do with HTML)]

Received on Friday, 4 September 1998 07:38:12 UTC