Investigating terminology & structure with HTML examples

Hello,

I think Kynn's and Marshall's points are very well made that we need clear 
technology-specific checkpoints (or whatever we call them). I also think 
that Charles'and Ian's points are well made that we do not want to break 
old terminology.

Therefore, I'm trying to imagine how the technology-specific checkpoints 
will fit in to the scheme of things.  I have drafted some HTML-specific 
checkpoints just to see how it works.  Note that these are really, really 
rough.  This was a quick pass.

I know this is going in the opposite direction of where William is pushing 
(to list only the principles and work from there) <grin>, but I am much 
more involved in Techniques and technology-specifics these days.  Thus, I 
need to appease that this level will work in some way before only focusing 
on principles, if in fact that is the best approach to take.

<imagining>
In the Guidelines document:

Guideline 1: Ensure that all content can be presented in any medium or 
combination of media that may be required by the user.

Checkpoints:
1.1 Provide a textual equivalent for every non-text (auditory or graphical) 
component or multimedia presentation.

In the HTML techniques document:

Checkpoint 1.1 Provide a textual equivalent for every non-text (auditory or 
graphical) component or multimedia presentation.
In HTML this means:
<HTML checklist>
1. Provide a short text equivalent via the "alt" attribute for every IMG 
element or in the content of every OBJECT element used to embed an image.
2. Provide a description of important visual features via the "longdesc" 
attribute for every complex IMG element or in the content of every OBJECT 
element used to embed a complex image. [ugh, used complex]
3. Provide a text equivalent for every programmatic object embedded with 
OBJECT, APPLET, or EMBED.  Note that APPLET and EMBED are 
deprecated.  Refer to the sections on auditory descriptions, captions, and 
making applets directly accessible.
4. Provide a text equivalent in the NOSCRIPT element for every scripting 
object that is necessary to accessing the page.  For example, if a rollover 
only causes the appearance of a button to change, a text equivalent is not 
necessary.  However, if a rollover causes further information about a 
button to display, a text equivalent is necessary.
5. Provide a link to a transcript for every audio file in the content of 
the OBJECT element if OBJECT is used to embed the audio file, in a P 
element if P is used to embed the audio file, in ...?? Refer to sections on 
how and when to caption audio files.
6. etc etc etc
</HTML checklist>

Examples and Discussion for Checkpoint 1.1 HTML 1
...

Examples and Discussion for Checkpoint 1.1 HTML 2
...

</imagining>

It would be easier to refer to the technology specifics if we had something 
specific to call them.  "Technology-specific checkpoints" seems long and it 
is a new term.  However, I would prefer to add a new term to what will 
actually be new than renaming something that exists already.

In other words, I tend to agree that the proposed Principles are similar to 
the current WCAG 1.0 Guidelines.  Proposed Guidelines and WCAG 1.0 
checkpoints also seem to have a similar feel.  I believe that what is new 
is the idea of technology-specific checks.  I don't care so much what we 
call them, but I agree that we do not want to break the old terminology.

Therefore, perhaps we could focus naming the newest layer.  I propose
a. "Technology specific checkpoints" or
b.  "HTML-specific checkpoints" then "CSS-specific checkpoints" etc. or
c. "HTML checks" "CSS checks" etc. or
d. "HTML tests" "CSS tests" etc.

thoughts?
--wendy
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Tuesday, 15 August 2000 17:54:38 UTC