Comments and edits for the DRAFT WCAG 2.0

Once again, every time I work on WCAG 2.0 it feels good.  I think this
format really moves us forward in the fundamental changes and modifications
to the guidelines to make them better and simpler and more straightforward.

With that introduction  --  my first point is that many of our principles
are way too academic.  In some respects it is important to be academic in
order to capture the underlying essence.  On the other hand, if we can't
figure out how to make them more readable, people will just bounce off of
them and head in some other direction again,  and create their own
guidelines.  We have to figure out how to make these real.

I have a friend who is very good at writing in very fundamental or essential
terms but it takes a second paragraph with an example before you really
catch on.

In the spirit of Ian's comments  (about making things longer if necessary to
make them understandable) , I would like to suggest that we make some of
these a little longer if we need to in order to make them more discernable.

More specifics on this are below.


ITEM 1
WORDING IN THE INTRODUCTION

Some edits in order are:

1. In the introduction we have a sentence that says, "if the checkpoint for
a technology are met, then the guideline and principle would also have been
satisfied".  I don't think that this is true.  In many cases we will not
have checkpoints which completely cover the guideline.  The checkpoints
might partially address the topic - but not completely.   If they completely
cover, then it seems that checkpoints in some ways would be the fundamental
statement.  I suggest that we remove this item or at least put it in square
brackets with three question marks after it so that we come back and check
to make sure in deed this is true when we are finished.  I'm afraid it won't
be and would hate to see this sentence accidentally remain in the final
draft if it is not.
2. There is also a phrase "and guidelines should be easiest to meet by
following the checkpoints".  I would probably suggest changing that to "and
the checkpoints are provided to present strategies for addressing each of
the checkpoints within the different technologies.
3. A final point on this introduction is that we have to be careful not to
imply that someone needs to follow all of the checkpoints in order to
satisfy the guideline.  If the checkpoints give alternatives, we somehow
should combine them and word them so that it's clear that when you do one of
the two alternatives you have satisfied the issue.  Again, we can talk about
this more when we talk about specific checkpoints.


ITEM 2

Principle 1 currently talks about all contents being presented in any medium
or combination of media.  When I read this I'm thinking of cd-roms versus
floppy disks versus ???.  In the interest of making this easier to
understand I would suggest rewording.

"Principle 1:  Ensure that all content can be presented through any single
sensory channel or a combination of sensory channels that may be required by
the user (e.g. all information only through vision or only through hearing,
etc.)"


ITEM 3

Under Guideline 1.1 we talk about talking about a text equivalent for all
non-text.  I would like to somehow get in here the idea that this needs to
be electronic text.  Text by itself cannot be translated into any form but
electronic text can.  Again, since we are talking about very general
principles, I would like to eliminate right off the bat anyone thinking that
putting a painted image of text on the screen solves the problem.  Remember
that we are talking about many different formats and not just talking about
html.  There maybe a wide variety of technologies in the future used to
representative information.  The key here is that it be electronically
readable.  Therefore, suggest that 1.1 be changed to.

"1.1 provide (an electronically readable) text equivalent for every non-text
(auditory or graphical) component or multi-media presentation".


ITEM  4

1.2 talks about providing an auditory description of the visual track.  We
just got through (in 1.1) requiring that they have a text description of the
visual track.  This, therefore, looks like it's one of those "until"
category items.  This leaves me in a dilemma.

First, audio descriptions of the video track are the preferred approach to
providing access.  The text approach is really only preferred by individuals
who are deaf/blind and can't use the audio description.  Thus, saying that
the preferred approach is with text and this is a secondary approach seems
counter productive.  Also given the rulings that are coming down around
providing audio description, it appears that this should be required.

On the other hand, we are talking about fundamental concepts here.  If we
are then 1.2 is really redundant with 1.1.  Are we saying that 1 plus 2 must
be provided theoretically?

My final outcome on this is that we should leave 1.2 as it is as a
requirement since that's really what's needed today.  If, in the future, 1.2
turns out to not be needed anymore, then we can simply remove the
requirement.  I doubt if anybody will complain if at some point in the
future a requirement is removed.


ITEM  5

1.3 handles time based multi-media presentation but it drops the timed
interaction component.  It should probably be part of 1.3 or a separate 1.4.

Since it is really the same concept and they maybe intermixed, I think it
should probably be part of 1.3.  The wording might be:

"1.3 for any time based multi-media presentation (e.g. movie or animation)
or any single media presentation which requires time synchronized action by
the user (e.g. for xyz press the button now).  Synchronize any equivalent
alternatives (e.g. captions or auditory descriptions of the visual track)
with the presentation.


ITEM  6

Principle 2 is a good solid principle.  However, I believe it will be
indecipherable to 95% of the people that it is intended to reach.  Mostly I
find that the only people who already understand the concept can understand
the principle.  This is the exact opposite of everything that we've been
trying to work toward.  However, it is a very difficult one to figure out
how to express in simple terms.  The only thing I can think of is to add
some e.g.'s into it or something to make it more decipherable.  I do not
have an alternate wording for this one but it definitely needs to be an open
issue.


ITEM  7

2.1 again, I suggest that we add some e.g.'s in here so that people have an
idea for what a mark-up language is and what we mean by a data model.


ITEM  8

2.2 same thing with style languages.  People are going to be wondering, "Is
the style sheet the same as a style language?"


ITEM  9

Same thing for 2.3.  It really does need an example at the end of it so that
people have some idea what it means.


ITEM  10

2.4 seems pretty straightforward except the e.g. is capitalized and should
be lower case, I believe.


ITEM  11

2.5

Hey, I don't have comments on this one except to say that this is a very
good example of how an example at the end can render an abstract guideline
into something that is much easier to understand.


ITEM  12

Priorities.  Early in the document it states that one conforms with WCAG 2
if they conform with the guidelines.  However, none of the guidelines have
any priority on them.  We really need to do this.

If was interesting to even think about whether or not the principles have a
priority on them.  One of the interesting things about this reorganization
is that it groups things under the general concepts and the general concepts
themselves kind of reflect the priorities in some ways.


ITEM  13

3.2 is another example of something that is written almost entirely in
jargon.  "Transformal grammars", "Mark-up languages", etc.  This one
definitely needs to have a sentence added at the end of it that translates
it to English.  Alternatively, you could pepper the sentence with e.g.'s to
provide examples of what each of these different terms mean so that someone
has a chance of understanding them.  I am worrying more and more that we are
moving toward basic concepts and sinking into jargons at the same time.
Please note that jargon is not a bad thing.  Jargon terms are generally
developed because there are not good terms already in a language to express
a particular meeting.  The problem is that if you don't know the jargon,
then the sentences might as well be written in a foreign language.


ITEM  14

4.1 again I would fill this full of e.g.'s for the same reason discussed
above.  In reading this I know I'm supposed to use a consistent style of
presentation, but I'm not sure what a semantic distinction is or a
structural distinction nor am I sure what an appropriate formatting
convention means (I do, of course, but only because I've been working on the
mark-up languages for so long).


ITEM  15

4.3 has an e.g. at the end but it is not clear if the e.g. refers to the
split into multiple resources or to a technique for overview.  (Rather I
should say that I can decipher it but it is not clear from the structure of
the sentence).  I would suggest that 1 e.g. be put to explain what the
overview means and a second e.g. to explain what "split into multiple,
independent resources" means.


ITEM  16

4.6 I would probably add the following example to make this clear list items
as "Sanitation Department, Motor Vehicle Department, Revenue Department"
rather than "Department of Sanitation, Department of Motor Vehicles,
Department of Revenue".


ITEM  17

4.9 talks about providing an overview or summary of highly structured
materials such as tables.  Should we have some kind of a size on this?  If
you have a table that is 3X3 items, providing an overview is probably a
little overkill.


ITEM   18

5.4 is a big one.  We should think about if that can be made a little less
broad and vague.


ITEM  19

6.1 I think we should add something to the end to explain transform
gracefully a little better.  Perhaps something like

"6.1 Make sure that websites which use newer technologies transform
gracefully when browsers do not support the technology or it is turned off".


ITEM   20

6.2 Avoid causing content to blink or flicker.  This is a very absolute
statement to be in a guideline.  As stated, this looks like an absolute
prohibition.  Although I guess it depends on what the priority level would
be for it.  If it were a level three then it wouldn't be an absolute
prohibition.  Blinking or flickering in certain ranges, of course, can be
very bad.  If we make it a priority 1...I don't know it just seems pretty
absolute.


ITEM  21

6.3 Avoid causing pages to be refreshed or updated automatically.

Again, this depends on the priority level but if this is a 1 or a 2, this
could be a real problem for many pages and it would be a severe ban.  I
would suggest that at least we add, "Unless the user can freeze the action"
to the end of the sentence or something like that.


ITEM  22

Checkpoint 2.2 from WCAG seems to not fit anywhere.

It actually looks like it could fit into two or three places (which is
probably why we can't figure out where to put it).  The first half looks
like it deals with sensory.  The second part dealing with black and white
screens appears to be device independence.

On the other hand, it could also fit into principle 2 since color is a form
of presentation.  Perhaps that is a better home.




Gregg

Received on Friday, 11 August 2000 15:43:59 UTC