Re: Techniques Document

Daniel,

more great comments.  thanks!  we've got a few questions and comments.

>> 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.
> 
what do you mean by, "can help with techniques, but not techniques?"  are
you saying this will help you follow the techniques, but it is not actually
a technique to do anything in particular?  if so, while it could be put in
the back as an appendix, having it in front as part of the "accessibility
themes" acts as a nice introduction and helps to create an overall picture
for the guidelines.  It also acts as a type of table of contents for the
techniques (those related to structure vs those related to presentation).
further ideas?

>> 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.
>
in addition to the quoted statement?  all righty.

>> 
>> 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.
>
we don't understand this comment.

>> To implement long descriptions, use the "longdesc" attribute
>>      In HTML 4.0, applies to almost every element
>
>Cut&paste typo here I guess.
>
oops. thanks.

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

>> 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 ?
>
currently - no.  since it is considered punctuation, it might not be read
if someone has turned punctuation reading off or to a lower level in their
screen reader settings.  a "lower level" means that only some punctuation
is "read" or "paused for."  

anyone feel otherwise?

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

oops. thanks.

>> Tables
>> 
>> Users may make tables more accessible in a number of ways:
>
>Page authors is better than Users.
>
right-o.

>> 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>
>
good suggestion. will do.

>> <SPAN alt="smile" title="smiley in ascii art">:-)</SPAN>
>
>No ALT on SPAN, can use class=smile instead.
> 
ahh, right.

>> 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.
>
is in there, different place.  will move.  (see previous e-mail re:
guidelines)

>>   <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
>
yep.  thank you for your thoroughness!

>> 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 ?
> 
hmmm.  I think it should be frames ought to be "titled."  name is used
programatically rather than for the user to orient themselves.  

in this example, yes name it an abbreviation, but it should be whatever the
author wants to use it as.  it's title that we're concerned about.

>> 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. 
> 
will look into.

>> 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)
> 
o.k.

>> 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)]
>
damn.  ick.

thanks,
the editors and chairs.

Received on Friday, 4 September 1998 20:52:56 UTC