- From: Ben Caldwell <caldwell@trace.wisc.edu>
- Date: Mon, 23 Dec 2002 08:17:41 -0600
- To: <w3c-wai-gl@w3.org>
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