Re: last (fast) gasp for waicard10, closing Thursday a.m.

Latest summary of comments:

Note another comment we have received from Michael Muller of Lotus:

>1.  On Frames, I suggest:
>     "Frames. Label each frame with a unique and descriptive title or name
>attribute."

Item currently reads "Frames. Label with title or name attribute." 

We have a space constraint here, but could do this: "Frames. Label with
unique title or name attribute." 

Reactions? I will use this unless disagreement.


>> 1.) image map comment...
>
>I suggest we use this sentence with alt not in bold.

Here is the latest proposal from Wendy:

>>Discussion on image map item follows. Statement on waicard10 currently
reads:
>>
>>"Image maps. Use client-side MAP and text links for hotspots."
>>
>this is better, 

This is actually what the card already said...

>although people may interpret it to mean "provide separate
>text links elsewhere on the page" unless they read the GL Techniques
document.
>
>How about the following: 
>Use client-side MAP and provide text for each hotspot.
>
>too cryptic?

Yes I think this risks being misunderstood; I could image someone putting
bit-mapped text on the hot-spots and not realizing it is a problem.


>> 2) Also please look at Wendy's image & animations comment. This gets back
>> to the awkwardness of "function," however I am not sure that her proposed
>> alternatives "replaces" or "provides" don't invite other kinds of
>> confusion. So, unless there is agreement from the list on either of these
>> alternatives, we will leave as is.
>
>Agreed.

Will leave as is.


>> 3) Page organization. I thought our last version had "where possible" after
>> "Use CSS for layout and style." I cannot find the reference on EOWG list
>> for dropping the "where possible" following CSS. While I do feel strongly
>> that we should mention CSS here, I also feel that the caution is necessary.
>> I will add "where possible" back in unless someone clarifies a resounding
>> reason to leave those two words out.
>
>my mistake probably, we had "wherever possible" and it was never my
>intent to remove it.

Will add back in, but as "where possible" due to space.


>> 4) "For Complete..." Gregg Vanderheiden has expressed additional concern
>> about people thinking that the Quick Tips are the final say in Web
>> accessibility, based on his observations of how people respond to the pilot
>> version when visitors come in to Trace. He requested that we move the URL
>> back to the bottom of the back and label it "For the rest of the guidelines
>> and checkpoints..." However given our discussions about people never
>> noticing the URL at the bottom of the back, and based on space constraints,
>> I have recommended the following, which the designer has been able to fit
>> in nicely: "FOR COMPLETE GUIDELINES & CHECKLIST; WWW.W3.ORG/WAI"  This is
>> in caps, set in an inverted band below the title & logos. Looks good;
>> stands out well; should entice people with the thought of a handy
checklist.
>
>is that a ; or a : ? I would prefer a :

Supposed to be ":"


>I guess it's too much asking to see a image of the preprint ?

Yes, sorry given time constraints, but I've copied the latest version in
text below.


>> 5) Gregg also raised a concern that the second phrase of "multimedia"
>> doesn't make any sense ("provide... accessible versions in case
>> inaccessible formats are used). I am not sure what we can do to clarify
>> this, nor what we lose if we take this out, since this does not clearly
>> enough address the pdf-type file format issue which has come up repeatedly
>> & was sometimes mentioned in conjunction with this. If there are no
>> additional comments, I will leave as is. If someone can propose a simple &
>> non-controversial clarification without adding more than three additonal
>> words, kindly do so.
>
>how about re-adding "non-W3C inaccessible" ?

So then "Multimedia" would read: "Provide captioning and transcripts of
audio, descriptions of video, and accessible versions in case non-W3C
inaccessible formats are used."

Does this automatically equate non-W3C formats with inaccessible formats?
Is that always a valid statement?

Also, Gregg, can you re-state what was confusing about the "accessible
versions of inaccessible formats"? In your view is this (a)
incomprehensible; or (b) incorrect? And do you have a (short) proposal of
how to fix?

Without further proposal, I will leave as is.


LATEST CARD CURRENTLY READS:

Quick tips to make accessible Web sites

For complete guidelines & checklist: www.w3.org/WAI

- Images & animations. Use the alt attribute to describe the function of
all visuals.
- Image maps. Use client-side MAP and text links for hotspots.
- Multimedia. Provide captioning and transcripts of audio, descriptions of
video, and accessible versions in case inaccessible formats are used. [OR:
some change in last phrase?]
- Hypertext links. Use text that makes sense when read out of context. For
instance, do not use "click here."

- Page organization. Use headings, lists, and consistent structure. Use CSS
for layout and style where possible.
- Graphs & charts. Summarize or use the longdesc attribute.
- Scripts, applets, & plug-ins. Provide alternative content in case active
features are inaccessible or unsupported.
- Frames. Label with unique title or name attribute.
- Tables. Make line by line reading sensible. Summarize. Avoid using tables
for column layout.
- Check your work. Validate the HTML. Use evaluation tools and text-only
browsers to verify accessibility. 

1999/02


----------
Judy Brewer    jbrewer@w3.org    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI) International Program Office
World Wide Web Consortium (W3C)
MIT/LCS Room NE43-355, 545 Technology Square, Cambridge, MA,  02139,  USA

Received on Thursday, 11 February 1999 10:31:11 UTC