WCAG 2.0 Criteria Review For checkpoints up to 2.7

Here is what I have so far on the Criteria and Examples Review

Have gotten up to checkpoint 2.7

Items needed action are marked with three asterisks  ***

Gregg



  1) Normative

*** At the last telecon we decided to label the Normative and
Non-normative sections specifically in each checkpoint.  We decided that
describing the normative and non-normative sections in the introduction
was not sufficient.   I don’t see that in the current draft.

*** We also decided to use some type of outlining to break the two types
of content apart.  A box or background color around the non-normative
information to go along with the text cues.

-------------------------------------------
Check Point 1.1
Provide a text equivalent for all non-text content.
--------------------------------------------

-  SUCCESS CRITERIA -
the success criteria in the draft ARE necessary and sufficient to meet
the stated 1.1 checkpoint.    So OK as is.

There will be some controversy however over the fact that this
checkpoint requires a full text script (all dialog and all visuals in a
text document) for every piece of video on a site.   If this is a
priority 1 checkpoint, which it always has been,  this will be a
required item for all movies in addition to captions and audio
descriptions.

----
- DEFINITION -

*** There is a bug in the last line of the definition.  The MAY needs to
be changed to CAN.
- CAN be easily converted to braille or speech, or displayed in a larger
font or different colors.
It is not a permission but a requirement that it can be easily
converted.

-----
The following sentence is in the definitions section.
"Depending on the purpose and content of the non-text content, a short
label may be appropriate, or a more thorough explanation may be
required."

*** It seems like guidance, not a definition.  Also seems to contradict
the success criteria.  It should be removed or added to the success
criteria.

-----
EXAMPLES
-- good examples.   All are examples of sufficient solutions that would
satisfy the success criteria.



------------------------------------------
Checkpoint 1.2
Synchronize media equivalents with time-dependent presentations.
--------------------------------------------

This checkpoint is currently broken as written

The checkpoint asks for Equivalents to be Synchronized  -- but it does
not require that any be provided other than what is required in 1.1.
"Synchronize media equivalents with time-dependent presentations."

The first CRITERIA however requires audio equivalents be provided.  It
doesn’t say anything about synchronization.

*** A FIX -- Change the checkpoint to read
"PROVIDE AND sychronize media equivalents with time-dependent
presentations" OR "PROVIDE sychronized media equivalents with
time-dependent presentations"

IF THE CHANGE IS MADE THEN
Then the success criteria WOULD PASS the test for Necessary and
Sufficient to meet the new checkpoint.   And audio description would be
required.


>>There will be controversy however around the following points.
1)  This requires that all live broadcasts be captioned and described
either in real time or after-the-fact.  Some may object to the
'after-the-fact" part but more likely the requirement for all live
material to be described will be a problem.    Since this guidelines
also covers audio description and captioning of professional videos and
movies, it is likely to have a high priority (P1?) .  thus the
requirement that all live broadcasts be captioned and described would be
a stiff mountain.

*** Suggestion:
- that the fourth criteria which gives an exception to the first
criteria be placed either just below the first or indented underneath
it.


DEFINITIONS

*** Suggest adding "FOR THE OTHER MEDIA TRACK' at the end of:

"Multimedia presentations include both audio and video tracks. During
the time that one of the tracks does not present any significant
information, there is opportunity to include a synchronized equivalent
FOR THE OTHER MEDIA TRACK."

Otherwise it doesn’t quite make sense.


EXAMPLES ARE GOOD
All examples are sufficient examples in that they satisfy all the
criteria for that checkpoint


-------------------------------------------
Checkpoint 1.3
Use markup or a data model to provide the logical structure of content.
--------------------------------------------

SUCCESS CRITERIA

This is a tough one.   But what we have looks good.  The criteria appear
to be both necessary and sufficient.  I say we call these as GOOD unless
someone can think of how you could do these two and not have satisfied
the checkpoint.    My only problem in saying BINGO right out, is that
this is checkpoint covers a lot of ground.

Lets say it is good for this draft and see if we find any exceptions as
we do technology specific points.

BENEFITS

*** The word MAY should be replaced with the word CAN.  It is their
ability that is provided, not permission.


-------------------------------------------
Checkpoint 1.4
Identify the primary natural language of text and text equivalents and
all changes in natural language
--------------------------------------------

SUCCESS CRITERIA

*** These look good except that the words "SHOULD" and 'WILL BE" should
be remove and replaces with ARE.   Also it should be made into bullets
or numbered list like the other success criteria. So it reads

1.  Changes in language ARE identified at the level the changes occur.

2.  If there is never a change throughout a whole site, then
identification can occur at the highest level (usually at a page or
document level).

3.  If changes occur at the word or phrase level, then changes ARE
identified at the word or phrase level using the markup appropriate to
the markup language in use.

QUESTION:  Why mention no change throughout whole site -- and then say
highest level is the page?  Could it be the site?    Wording is a bit
ambiguous but workable as is.


BENEFITS

*** Suggest adding "WHICH CAN MAKE THE PHRASE UNINTELLIGIBLE" to the end
of
When they are not identified, the speech synthesizer will use the
default accent and pronunciation dictionary WHICH CAN MAKE THE PHRASE
UNINTELLIGIBLE

EXAMPLE - is good and sufficient


-------------------------------------------
Checkpoint 1.5 Separate content and structure from presentation
--------------------------------------------

CRITERIA
The second criteria is basically a restatement of the checkpoint with an
exception.

"To the extent that the technology allows (see checkpoint solutions) the
markup or data model representing the structure of the content, must be
logically separated from the presentation, either in separate data
structures or in a style sheet"

It is clearly necessary -- but with the exception.  So it is in fact
LESS than the checkpoint and not sufficient

If the "where technology allows' is intended to be part of the
criterion, then it should be in the checkpoint.  The checkpoint should
NOT be more severe than the criteria for success.

*** We need to remove the exception from the criteria or add it to the
checkpoint.

The FIRST criteria is
"There must be sufficient markup or a sufficient data model to ensure
that a logical, linear reading order can be derived from the content."
This seems to be MORE than the checkpoint.  Separating content and
structure from presentation does NOT imply a linear presentation.

I can show you many structures that cannot be presented logically in a
linear order.   Hmmmm   Do we mean "Text" content?

*** I do not recommend a change on this one at this time.    We should
just log it into an issues list to discuss later.   it may not be a
direct criterion of the checkpoint -- but we should capture the idea
somewhere.

EXAMPLES
examples are good and sufficient


-------------------------------------------
Checkpoint 2.1 Provide multiple site navigation mechanisms.
--------------------------------------------

SUCCESS CRITERIA
The criteria for 2.1 read as follows
1- One or more navigation mechanisms are provided which cover all or
selected portions of the content comprising a web site.
2- Search functions report errors and may attempt to correct mistakes in
user input. (refer to checkpoint 2.7)
3- The site navigation mechanisms are clearly distinguished from the
main content and can be easily located.

These criteria are neither necessary or sufficient as written.  In this
case they fail both tests
- the first one is basically a restatement of the checkpoint except that
it says that only part of a site needs to have multiple navigation
mechanisms so it is not sufficient (or the checkpoint needs to be
changed to say full or partial site navigation.
- the second criteria is a technique but is not required so cannot be a
criteria.  It should be moved to techniques. (it is not an example
because it does not meet the criteria)
- the third criteria is ok.
- but the set is not ok unless the qualification is removed from the
first (or added to the guideline)  in this case, the criteria are almost
identicle to the checkpoint.

*** Suggest that we remove #2.  that # 1 be changed to remove the
partial site as good enough, unless we want to add partial to the
checkpoint.

EXAMPLES
There are no examples.



-------------------------------------------
Checkpoint 2.2 Provide consistent and predictable responses to user
actions.
--------------------------------------------

SUCCESS CRITERIA

These all seem to be good advice.   And it seems to be a good
collection.  Good coverage.  Can't think of anything missing -- but we
should examine that after TR.

 I wonder though about requiring them for a whole site.   What if a site
has documents or sections by different authors.  Or sections for
advanced physicists and sections for children.   Do they have to have
the same type of interface?

If someone creates special versions of info for people with cognitive
disabilities, do they then have to use those interfaces approaches
throughout their site to comply with this guideline?

Because we use "SIMILAR"  and not "SAME"  we leave a fair amount of room
for different versions for different cognitive levels.

***  If we changed  "SITE" to  " SITE, SECTIONS OR PAGES MEANT TO BE
USED TOGETHER"  then I think these could meet the SUCCESS CRITERIA
tests.   We should come back to these later though and make sure that we
have everything we want here.   (e.g.  will meeting ONLY these be
sufficient. )
But the look good to me.

*** Oh,  one more point.   How do we handle joke sites or mystery games
etc.   it may be appropriate to sometimes break rules on purpose.  How
do you demonstrate bad design on a site and still have the site comply?

We should have add an exception statement for situations where the goal
is specifically to have controls that do not act like one would think
they should.  How about if we add one more criteria that reads
" - if controls are purposefully made to behave in unexpected or
irregular fashion for a specific purpose (demonstration, humor, mystery,
etc) then this is so stated on the pages or intro to the pages."

EXAMPLES
I presume these are not examples but simply notes that we should add
examples.   If they are examples of places where we should do this, I
would move that text up to the BENEFITS section.  Otherwise I suggest we
change the EXAMPLES text so that they are examples of conformance.



-------------------------------------------
Checkpoint 2.3
Give users control of mechanisms that cause extreme changes in context.
--------------------------------------------

SUCCESS CRITERIA

Seem to be both necessary an sufficient except that the criteria are to
give control or to warn and the guideline is that you must give control.


*** To use these criteria we would need to modify the checkpoint to say

Warn or give users control of mechanisms that cause extreme changes in
context.
OR
Give users control of mechanisms that cause extreme changes in context -
or warn them in advance of triggering changes.

One could argue that warning someone of something was giving them
control but that argument could be applied in many places resulting in
inaccessible interfaces that people are just warned of.

**** also suggest we add the phrase "OR SO THEY CAN BE PREPARED FOR THE
CHANGE' to the end of:
"....or identify extreme changes in context before they occur so the
user may determine if they wish to proceed OR SO THEY CAN BE PREPARED
FOR THE CHANGE.

-------------------------------------------
Checkpoint 2.4 Either give the user control over how long they can
interact with content that requires a timed response or give them as
much time as possible.
--------------------------------------------

SUCCESS CRITERIA
The criteria require that the user have control but the Checkpoint does
not
The criteria are therefore more strict than the checkpoint
They therefore fail the necessary Test.

Other than that they are well written and appear sufficient.

**** We need to either add the exception to the criteria or remove it
from the checkpoint.
We should also define what the maximum possible means -- or at least
what is reasonable.

EXAMPLES
Are good and sufficient


-------------------------------------------
Checkpoint 2.5 Use device-independent event handlers.
--------------------------------------------

SUCCESS CRITERIA

This looks like it has two different sets of Success Criteria.   It
doesn’t but it looks that way.
***We need to format it so that it is clear if you have to do all three
parts,
or   1 and 2  OR  3,
Or what.

Otherwise looks good.

EXAMPLE
The Example is good and sufficient

-------------------------------------------
Checkpoint 2.6 Avoid causing the screen to flicker.
--------------------------------------------

SUCCESS CRITERIA

The success criteria just ends mid-sentence.
"You will have successfully avoided causing the screen to flicker if
you:"

****  we should just remove the fragment and the "success criteria"
title
or we should add something to the end like
" do not include content that will flicker between the frequencies of 3
and 54 hz. "

-------------------------------------------
Checkpoint 2.7 Handle input errors, such as misspellings
--------------------------------------------

SUCCESS CRITERIA

The success criteria currently reads
You will have successfully provided more than one path or method to find
content if you:
  -  check for misspelled words and suggest correct spellings when text
entry is required.
  -  where possible, let the user select from a list of options rather
than generate text.

**** as per previous discussion - we need to fix the lead in to reflect
the new checkpoint.

**** we should remove these as checkpoints and put them down below ---
or just label them as "strategies for addressing this item"

The intro paragraph makes it clear this is new and in discussion.  We
should keep the content looking like ideas and discussion rather than
having things labeled as compliance criteria.


EXAMPLE
Example is hard to evaluate til we work on this item more.

Received on Thursday, 9 August 2001 14:36:14 UTC