Re: Investigating terminology & structure with HTML examples

This is Wendy's strawman.  I'll try to tell you what I like, and
also what I don't like.

At 02:56 PM 8/15/2000 , Wendy A Chisholm wrote:
>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.

I've always hated "Ensure".  This is weak English construction
and doesn't stand alone.  I'd rather we state things in a more
direct manner.

Also, I suggest that this guideline alone is absurd, as it
places illogical implications on what should be provided.
 From reading that "guideline" I have no idea what is expected
of me, but it certainly sounds weighty.  Apparently I have to
provide my context in video, sound files, pictures, foreign
languages, and more, even if I'm just making a normal text
page.

Right?

If rewritten this might be what I would consider a "Principle" and
could be included in a Principles document.

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

Is this checkable?  Is it sufficient?  I worry about the use of
"checkpoints" when clearly _this_ is not intended to be the thing
checked.

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

See, this is good, but _these_ are the actual checkpoint.  The vague
"checkpoint" above is not a real checkpoint.  It's not something
that you can check or not check, it's just a general rule to follow.

>1. [...] 5.

Those are checkable, kinda.

BTW, something went wacky with your return key, I think, the rest
of this reads as one huge paragraph.

>  Examples and Discussion for Checkpoint 1.1 HTML 1 ... Examples and Discussion for Checkpoint 1.1 HTML 2 ... 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.

I agree that renaming or reusing terminology is bad.

>In other words, I tend to agree that the proposed Principles are similar to the current WCAG 1.0 Guidelines.

Disagree on this.  The Guidelines as such aren't really Principles,
they're a meta-step down in the hierarchy of ideas.

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

Oh dear.  Do now have at least 5 layers that we're talking about?
I think we need to consider everything as a whole -- and create
new terminology if necessary (without recycling old terms) --
and in that context it makes no sense to have both "checkpoints"
and something called "<X> check[points]".

In my opinion, before we start naming things, we need to define
things and come to a consensus on how many layers (and thus
complexity) we need to have, how many _documents_ we will produce,
and what each one should consist of.  Then we can launch into
terminology.


-- 
Kynn Bartlett  <kynn@idyllmtn.com>                       http://kynn.com/
Director of Accessibility, Edapta                  http://www.edapta.com/
Chief Technologist, Idyll Mountain Internet      http://www.idyllmtn.com/
AWARE Center Director                         http://www.awarecenter.org/
Vote for Liz for N. Am. ICANN Nominee!             http://kynn.com/+icann

Received on Tuesday, 15 August 2000 18:15:19 UTC