Quick Tips revision: summary comments & proposal

EOWG:
and cc: Guidelines WG:

For discussion at Friday July 16 EOWG meeting, 8:30 a.m. US EDT, 1 617 252
1038.

Purpose of discussion: consider edits needed to correct or clarify existing
text, before reprinting large quantity.

Constraints: 
- very very small space; 
- agree on text by Friday about 3:00 p.m. US EDT.; 
- text cannot differ from messages or priorities of WCAG 1.0.

The following section summarizes all comments received by Thursday night,
and proposes a resolution for each item. Comments are (roughly) attributed
to individuals and you can look for their rationales in the EOWG mailing
list archive at
<http://lists.w3.org/Archives/Public/w3c-wai-eo/1999JulSep/>. I've added a
few additional replies.

At EOWG meeting on Friday we will go through this line-by-line for agreement.

I have numbered the tips in this message for easier reference, although
they are not numbered on the card, and will not be.

Comments & proposal on card:

Quick tips to make accessible Web sites 
JB leave as is.

FOR COMPLETE GUIDELINES & CHECKLIST: WWW.W3.ORG/WAI 
JB leave as is.

1. Images & animations. Use the alt attribute to describe the function of
all visuals. 
HB change "all visuals" to "each visual".
DD make "alt" boldface.
RN "alt" should be in caps
JB other attributes aren't.
MM replace "the function" with "both content and function"
HB "function or content" but not both.
JB as I recall, the Guidelines WG gave us a mandate to use "function" here,
e.g., the purpose that the visual serves on a Web page; in some cases it's
the same as the content. I looked at the discussion of text equivalents in
guideline one of WCAG, it says "The equivalent information must serve the
same purpose as the visual or auditory content." so I think "function" wins.
PROPOSAL: "Images & animations. Use the _alt_ attribute to describe the
function of each visual." 

2. Image maps. Use client-side MAP and text for hotspots. 
JB Make "MAP" lowercase but keep bold.
RN Require redundant text links. add "and alternate text links"
JT: Alt text for client side maps (areas) is priority 1. Alternative text
links
is priority 3 because those areas are generally accessible today. Look at
www.ibm.com/sns which has a map across the top. All alt text is displayed
in IE
with images off, and spoken with screen readers and text browsers. Even
without
alt text, Lynx, HPR, and others will at least expose the URL's.  Your comment
seems to be talking about server-side maps - where you would get one alt text.
Not using these or providing alterntive text links is priority 1.
AG "Use client-side _map_ with text for hotspots." to clarify that the text
is in the map.
JB originally we put "and" here so it could be interpreted either way (in
the map, or as redundant text links). Crude, but that's what I recall as
the outcome of an excruciatingly long thread. Looking at the text of 1.5,
"Until user agents render text equivalents for client-side image map links,
provide redundant text links for each active region of a client-side image
map," keeping "and" actually looks truer to the intent.
RN Add "links" as follows: "and text links for hotspots."
AG Since redundancy is required for the interim, "Use a client-side
<em>map</em>, and text links as well as image hotspots."
JB Seems that adding "links" would clarify things. Unfortunately it also
blows the line-length, wrapping onto the next line, and thereby displacing
something else from the card. Is the additional clarity on this sufficient
to justify removing something else? If so, what should go...?
IJ In all the specs I've worked on, we've adoped the convention that
element names are in caps and attributes in small letters (and quoted). 
JB MAP was looking lonely as the only capitalized element or attribute on
the front; but you're right. However, if that means we've got to put little
quote marks around all the attributes, hmmm...?
AG doesn't have to be true to specification conventions, just needs to be
set off.
PROPOSAL: "Image maps. Use client-side _map_ and text for hotspots."

3. Multimedia. Provide captioning and transcripts of audio, descriptions of
video, and accessible versions in case inaccessible formats are used. 
JB drop "accessible versions in case inaccessible formats are used", add
"and" before "descriptions, drop that comma, shift the period.
RN "Multimedia. Provide captioning or text transcripts of audio.
Descriptions of video may be provided."
AG  "Provide captions and transcripts, and descriptions of video."
JB I think it's important to emphasize audio-- many people don't think in
terms of deaf access.
PROPOSAL: "Multimedia. Provide captioning and transcripts of audio, and
descriptions of video."

4. Hypertext links. Use text that makes sense when read out of context. For
instance, do not use "click here." 
WL Remove "For instance, do not use "click here."
HBj Yes on remove, but "include non-link printable characters between
adjacent links"
AG "Use text that makes sense when read out of context, not 'click here.'"
PROPOSAL: "Hypertext links. Use text that makes sense when read out of
context, not 'click here.'"
     
5. Page organization. Use headings, lists, and consistent structure. Use
CSS for layout and style where possible. 
DD Make CSS bold.
PROPOSAL: "Page organization. Use headings, lists, and consistent
structure. Use _CSS_ for layout and style where possible."

6. Graphs & charts. Summarize or use the longdesc attribute. 
HBj Why is "longdesc" in bold?  All attribute names should be the same. See
also "title"  and "name" under Frames.
JB ?they are the same; they're all in bold, no?
PROPOSAL: "Graphs & charts. Summarize or use the _longdesc_ attribute."

7. Scripts, applets, & plug-ins. Provide alternative content in case active
features are inaccessible or unsupported. 
PROPOSAL: "Scripts, applets, & plug-ins. Provide alternative content in
case active features are inaccessible or unsupported."

8. Frames. Label with the title or name attribute. 
PROPOSAL: "Frames. Label with the _title_ or _name_ attribute."

9. Tables. Make line by line reading sensible. Summarize. Avoid using
tables for column layout. 
JB drop "avoid using tables for column layout" and add hyphens to
"line-by-line."
RN how does this impact "colgroup"
PROPOSAL: "Tables. Make line by line reading sensible. Summarize."

10. Check your work. Validate the HTML. Use evaluation tools and text-only
browsers to verify accessibility. 
JB add more incentive for them to go to the source: add "against complete
guidelines" and then the URI for the guidelines following "check your work."
HBj good idea to add URL, but why just mention text browsers?
JB because that's all we had room for on the card.
MM add "navigate using mouse only"
HB No. "Mouse only" is no less significant than "voice command only" or
"keyboard only" for navigation.
MM Perhaps further append "If you can't validate with a screen reader, ask
your colleague to play the role of screen reader software and operate with
your eyes closed." 
HB don't add it...
PROPOSAL: "Check work against complete guidelines
www.w3.org/TR/WAI-WEBCONTENT. Validate HTML. Use evaluation tools and
text-only browsers to verify accessibility." [this may not fit...!]

11. Additions?
HBj Guideline 7 "Ensure user control of time-sensitive content change"
JB There are several guidelines (as opposed to checkpoints) that we don't
get near on the Quick Tips card: color, language, time-sensitivity, interim
solutions, W3C technologies, keep it clear & simple. While these don't all
directly intersect with priority one, some do. Really hard to know where to
start & stop. If we take one phrase off of tables & one off multi-media,
but don't add too much to "check your work" then we _might_ have space for
a short additional item--if we can agree on  which one it is, and agree on
the wording.
PROPOSAL: No additions.

cW3C (MIT, INRIA, Keio)
[no change]

1999/02
[change to 1999/07]

- Judy
----------
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 Friday, 16 July 1999 01:20:37 UTC