REF Editorial Suggestions for Guidelines.

 

In order to move the guidelines along, I did a review from front to back.  I
came up with a list of suggestions that ranged from editorial to conceptual.
This e-mail contains the items that I think are largely editorial in nature.
I am just enclosing them in this e-mail so that everyone can take a quick
look and see if there's anything they have a concern with before it's made.
The more conceptual items and substantial items, I will put in separate
e-mails.

 

 


Item 1  - REFERENCE 1.1


 The note under the second success criteria actually refers to the first
success criteria and should be moved.

 

It's also written as "should" which should be changed to the right form.  It
would then read "text equivalent fulfills the same function as the author
intended for the non-text content." (i.e. presents all of the intended
information and/or achieves the same function as the non-text content)

 


Item 2  - REFERENCE 1.1 Non-text content definition


 

Create a new paragraph from the last sentence which begins "scripts,
applets, and programmatic objects."    Perhaps this should be a NOTE:

 


 Item 3  -  REFERENCE:  ALL provisions


 Suggest bolding each of the disabilities in the "Benefits" of each
checkpoint.  There are still many who miss the fact that each checkpoint
deals with many different disabilities.  Bolding them will make it easier to
both notice all of the different disabilities addressed by each checkpoint
and to locate checkpoints dealing with specific disabilities.

 


Item 4  -REFERENCE Checkpoint 1.2


 1.2 needs to be seriously reworked.  It is not clear at all how it should
be exactly applied.  The exception on item 2 actually also applies to item
3.

 

Item 4 is not clear.

 

Best practice item 1 is actually required by checkpoint 1.1 and should be
deleted here. 

 


Item 5  -  REFERENCE 1.2 Best Practice Item number 2


 

Delete the phrase "which provides the same information" from number 2 which
reads "captions and audio descriptions are provided for all live broadcasts
which provide the same information".

 


Item 6  - REFERENCE 1.3


 Per decision at the face to face, 1.3 should be edited to read

 

"1.3 [Core] information, functionality, and structure are separable from
presentation".

 


Item 7  - REFERENCE 1.3 Success criteria number 1.


 Suggest putting the word "user" in front of interpretation so that this
item ends with "..without requiring user interpretation of presentation".

 

The reason is you should not preclude the ability of user agents to clearly
derive of some of these items programmatically if they are done properly.

 


Item 8  - REFERENCE 1.3


 There is no definition for functionality.  Suggest adding one to the
informative section that would read:

 

Functionality

Functionality is the function or purpose of the content.  The functionality
or purpose of content can include presentation of information, as well as
any other functionality such as data collection, securing a response from
the user, providing user experience, testing, confirmation, purchasing, etc.

 


Item 9 - REFERENCE 1.3 Definitions


 

I suggest that we delete the definition of content.  We have definitions of
content at the end and it is a tricky item.  We don't use the content
anywhere in this item anymore so there's no need to define it here.   We
have a better one someplace.  And it needs to agree with the UAAG definition
(if it is not identical). 

 


Item 10 - REFERENCE Benefits of Checkpoint 1.3


 

Suggest adding two more paragraphs.

 

It can also facilitate automatic emphasis of structure or more efficient
navigation.

 

All of these can benefit people with cognitive, physical, hearing, and
visual disabilities.

 


Item 11 - REFERENCE 1.4 Best Practice #1


 

We currently say that abbreviations and acronyms should be clearly
identified each time they occur.  I would suggest that this not be
necessary, that they identify each time they occur if they collide with a
word in the language.  If they are unique, then I think if they are
identified once in a document, user agents should be able to, like people,
identify them because they look just like the previous occurrence in the
document.

 

"if they collide with a word in the standard language that would also
logically appear in the same case (e.g. all caps)".

 

 


Item 12 - REFERENCE 1.5 Best Practice Techniques


 

Delete item number 5 since it is a duplication of something which is listed
as a checkpoint in 2.4.

 


Item 13 - REFERENCE 1.5


 

The best practice items 2 and 3 are almost exactly the same.  Suggest they
be combined into one which reads:

 

#2 Content is constructed such that users can control the presentation of
the structural elements individually and/or as part of alternate
presentation formats.

 

This combination is important because it is a checkpoint and two items
overlap, so it is confusing to have them separate.

 


Item 14 - REFERENCE 1.6 Best Practice #4


 

Suggest that this one be shortened so that it looks like #2.  For now, since
we haven't worked out the exact the wording for the second required
checkpoint, I think we should replace #4 with the following parenthetical
phrase.

 

(This item should read identically to the required item #2, except that it
should say "in default presentation mode".)

 


Item 15 - REFERENCE Definitions for Checkpoint 2.1


 

Delete the editorial note add a definition which says what the editorial
note asks for.  For example:

 

Operable

The term operable includes the concept of efficiency.  That is, it implies
that the device can be operated from the keyboard in a reasonably efficient
fashion.  Using MouseKeys or having to tab dozens of times to move through a
small section of a document or page, or other unreasonably inefficient
keyboard access would not qualify.  If a document has a very large number of
links, some mechanism other than tabbing through them one at a time needs to
be provided.  This might include provision of headers (for header
navigation), the use of skip navigation, links, etc.

 


Item 16 - REFERENCE 2.2


 

The second bullet under the first success criteria should have the words
"default setting or" added to it so that it reads:

*         Or the user is allowed to adjust the time limit over a wide range
which is at least ten times or default setting or average user's preference.

 

 


Item 17 - REFERENCE 2.2 Examples


 

The checkpoint actually deals not just with responses, but also with the
time it takes somebody to read something.  Therefore, suggest that the word
"comprehension or" be added to the following sentence.

 

*         Examples of content that requires COMPREHENSION OR a response
within a timed interval.

o        Automatic refresh

o        Redirection

o        ..

 


Item 18 - REFERENCE 2.5 Success Criteria #1


 

It currently says if an error is detected, feedback is provided.  

Recommend that we add a parenthetical to make sure that that feedback is
accessible so that it reads: 

 

1.       If an error is detected, feedback is provided to the user
identifying the error (in accessible form that meets core checkpoints.)