- From: Judy Brewer <jbrewer@w3.org>
- Date: Fri, 16 Jul 1999 01:19:53 -0400
- To: w3c-wai-eo@w3.org
- Cc: w3c-wai-gl@w3.org
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