- From: Kynn Bartlett <kynn-edapta@idyllmtn.com>
- Date: Tue, 15 Aug 2000 15:04:50 -0700
- To: Wendy A Chisholm <wendy@w3.org>
- Cc: w3c-wai-gl@w3.org
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