RE: Checkpoint 1.1 - handling the rest of the comments

Sorry to chime in late on this one, but here are two proposed revisions
(based on Gregg's comments) to the proposals Wendy sent on Checkpoint
1.1. 

I've pasted the relevant comments below followed by the [proposed
revisions].

-Ben

>>===========
>> 
>>Comment #4
>>Sun (via Earl Johnson), 27 Oct 2002 [11]
>>"Benefits" bullet #2: Suggest dropping this "or have it translated and
>>presented as sign language," the text "reading the text" makes the
point.
>>
>>Proposal #4
>>No change to the checkpoint.
>>Rationale:  reading text and viewing sign language are different.  In 
>>the previous bullet we say that a screen reader can read text 
>>aloud.  Translating text to sign language is a similar process that
ought 
>>to be specifically mentioned.  For more info, refer to an overview
from 
>>signingbooks.org [13].

BC: Note: Gregg's original reply to Wendy on this included the text of
comment and proposal #3. His comments, however, were in response to
proposal #4.

>GV:  Good. But we need to be sure it is clear that this will be done
>“automatically” at the users end – and is not a responsibility of the 
>author.  (Translating into sign language)

BC: Update the second bullet in the benefits section to read:

[proposed revision]

Individuals who are deaf, are hard of hearing or who are having trouble
understanding the audio information for any reason can read the text
presentation or have it translated and presented as sign language by
their assistive technology. 

[end proposed revision]
 
>>===========
>> 
>>Comment #5
>>Sun (via Earl Johnson), 27 Oct 2002 [11]
>>"Examples" #4: Change "described in words" to "read"
>> 
>>Proposal #5
>>Label the examples consistently throughout the guidelines.
>> 
>>Current wording:
>>Example 1: providing a short label for a button/link.
>>Example 2: providing a short label and a longer explanation of a data 
>>>>chart. Example 3: providing a short label and a longer explanation 
>>of an >>animation. Example 4: providing a short label and a transcript

>>for an audio file that can be described in words. Example 5: providing

>>a label for content that cannot be described in >>words.
 
>>Proposed wording:
>>Example 1: an image used as a button.
>>Example 2: a data chart.
>>Example 3: an animation.
>>Example 4: an audio file of a speech.
>>Example 5: an audio file of a symphony.
 
>>Rationale:  Primarily, this is a matter of style. It also improves the
>>consistency with the rest of the guidelines.  I prefer short labels 
>>followed by detailed explanation to help a reader quickly skim for an 
>>example that meets their needs.
 
 
>GV:   I like the short titles– but I think they should be followed with

>what you should do about them.   One of the purposes of the old 
>examples was to show that some types of information needed more text as

>an alternative than did others.  (Maybe that is what you intended 
>anyway)
 
BC: Modify the titles in the examples section to read:

[proposed revision]

Example 1: an image used as a button. (short description of function)
Example 2: a data chart. (short label + longer description) 
Example 3: an animation. (short label + longer description) 
Example 4: an audio file of a speech. (short label + transcript) 
Example 5: an audio file of a symphony. (short label)

[end proposed revision]

Rationale: This set of examples is somewhat unique in that it compares
how the checkpoint applies to different types of content. The
parenthetical additions to the titles should help bring attention to the
fact that different types of content should be addressed differently
under this checkpoint. As well, it will help authors who need to refer
back to them to more quickly identify which types of content require
which labeling strategies. 

Received on Monday, 23 December 2002 09:20:44 UTC