W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 1998

Techniques Document

From: Daniel Dardailler <danield@w3.org>
Date: Fri, 04 Sep 1998 13:38:33 +0200
Message-Id: <199809041138.NAA18512@www47.inria.fr>
To: w3c-wai-gl@w3.org

>      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.
>      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.
>      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

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

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

> <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>

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
> 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

[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

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:27 UTC