W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > July to September 1999

Re:Updated Status of Quick Tips revisions: new 8, new

From: Judy Brewer <jbrewer@w3.org>
Date: Fri, 16 Jul 1999 16:55:02 -0400
Message-Id: <3.0.5.32.19990716165502.00ac1c80@localhost>
To: karl.hebenstreit@gsa.gov, w3c-wai-eo@w3.org
Cc: dd@w3.org, po@trace.wisc.edu, ij@w3.org, chisholm@trace.wisc.edu
At 04:39 PM 7/16/99 -0400, karl.hebenstreit@gsa.gov wrote:
> 
>8.  Frames:
>
>I like Alan's addition of "meaningful"  
>
>    PROPOSAL:
>8.  Frames. Meaningful Title frames, and provide _NOFRAMES_ equivalent.

JB: Meaningful doesn't fit on the line, see compiled thread in previous mail.


>10. Check your work:  
>
>I agree with Charles, the http:// should be there if there's room (must be
there
>in an online reference, so people who might copy and paste into a word
processor
>will get an active link).
>PROPOSAL:
>10. Check your work. Use evaluation tools, guidelines and checklist
>http://www.w3.org/TR/WAI-WEBCONTENT

JB: http:// doesn't fit either, although I will re-check since we've
changed one or two other things.

- Judy

>
>
>____________________Reply Separator____________________
>Subject:    Updated Status of Quick Tips revisions: new 8, new
>Author: "judy brewer" <jbrewer@w3.org>
>Date:       07/16/1999 3:07 PM
>
>EOWG
>
>Thanks for all the good discussion. I've been reviewing & summarizing;
>let's see where we have resolution.
>
>No issues or corrections to my notes have been raised from the first item
>down through scripts, so those are resolved, and will appear as below.
>
>Two items to look at new solutions on; see compiled threads below for
>background.
>
>8. Frames. Meaningful Title frames, and provide _NOFRAMES_ equivalent.
>
>10. Check your work. Use evaluation tools, guidelines and checklist
>www.w3.org/TR/WAI-WEBCONTENT
>
>- Judy
>-----
>
>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
>each visual.
>
>Image maps. Use client-side _MAP_ and text for hotspots. (NB: _MAP_ is in
>small caps.)
>
>Multimedia. Provide captioning and transcripts of audio, and descriptions
>of video.
>
>Hypertext links. Use text that makes sense when read out of context. For
>example, avoid "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.
>
>-----
>
>OK, then we get to frames. More discussion, which I summarize/excerpt as
>follows:
>
>PROPOSAL: "Frames. Label with the _title_ or _name_ attribute."
>OR PROPOSAL: "Frames. Use _NOFRAME_, and _title_ or _name_ attribute. (NB:
>"noframe" would be in small caps)
>WL The argument that only priority 1 items can be on the card is already
>broken since "title" attribute is only ever given as an example and
>"name" not at all in the checkpoints, therefore "noframe" is just as
>permissible.
>WL Proposal: Frames. Use "noframe"[format shows it as an element]. Use
>_title_ or
>_name_ attribute.
>CMN "alt" is only an example. Drop "attribute" to fit the line if necessary.
>CMN Proposal: Frames: use _noframes_, and meaningful _title_ or _name_
>attribute.
>WL Drop attribute here & elsewhere.
>CMN NOFRAMES has an "s"
>JA element is "noframes" with an "s"
>I prefer Use _noframes_ at the end of #8
>I also like using _title_ "and" _name_ instead of "or"
>because of browser inconsistency in the implementation of what to display
>JA agree. drop attribute. If we are going to use "smallcap" bold for elements
>and lowercase bold for attributes, then using "attribute" is redundant and
>wastes space for more important material that is "written clearly"
>HB I note that FRAME and NOFRAMES are only in the transitional HTML, not part
>of the HTML4.0 strict.dtd. They are replaced there by the OBJECT
>generalization that can have as the "if all others fail" choice a text
>version equivalent to the NOFRAMES.
>HB PROPOSAL: "Frames and Objects. Use _title_ or _name_ attribute, give
>NOFRAMES content or text default."
>WC I like the second proposal [w/ noframes].  This technique is included in
>checkpoint
>6.5, which is P2.
>We've recently found that at least one browser for PalmOS acts like older
>text-based browsers: it give you a blank screen rather than a list of frame
>names.
>KH Proposal 2 (noframes)
>HB: Even if it is only in the transitional DTD. Are we continuing that
legacy?
>WC there are several things in the WCAG that are "legacy" caused by the
>widespread use of older user agents or lack of support for newer features.
>therefore, "until user agents" seems to apply here.
>CMN NOFRAMES is a fundamental requirement of the frameset DTD. It is not
>legacy,
>it is the correct way to provide access to the content of frames for non
>spatially based browsers, in the same way the the correct way to provide a
>full description of an image using the IMG element is to add a URI as a
>longdesc. It just so happens that there are emergency repair strategies for
>framesets, although in most cases they provide a poor form of access at best.
>This means that Noframes is not necessarily a P1 requirement for
>accessibility on desktop machines (it probably is on mobile machines at the
>moment), but does not mean it it is unnecssary. Second-class access is
>appropriate for second-class people, but there are none of those.
>CMN In fact there is a completely separate DTD for framesets...
>JB: "Meaningful" doesn't fit the line.
>IJ: Proposal: Frames. Title frames, and provide _NOFRAMES_ equivalent.
>NEED REACTIONS!!
>
>-----
>
>Tables. Make line-by-line reading sensible. Summarize.
>WC proposal:  Tables. Make line-by-line, single column reading sensible.
>Summarize.
>however, i don't feel strongly about this, because if the line-by-line
>reading is sensible, it is most likely in a single column.
>KH Tables:  Original proposal (I don't agree with an explicit restriction
of a
>single column; this is an issue that should be resolved by further
>developments
>in screen readers) For clarification purposes on Tables, what is your
>opinion of the use of tables
>in the Main Menu page of my site? I use multi-column tables at the top and
>bottom (with the top menu embedded in a subform if there's any difference)
>http://w3.gsa.gov/web/m/cita.nsf  FYI -- I haven't had a chance to look at
>Notes/Domino R5 yet, but I've seen demos where they are adding multiple
>options for tables, such as showing a row
>at a time.
>HB: Wendy: or any wrapping lengthy stuff is in the final column of the row,
>so there is no interrupted content in the earlier columns. [Note the
>writing direction sensitivity for tables in I18N, where left to right
>cannot be presumed, either for text wrapping, or for column order.
>WC [excerpted] ..."line-by-line, single column"  not because of the
>visual display but how my tools allow me to interact with it. we're really
>saying "make sure each cell is readable on its own."
>JB but that enters another level of confusion... I'd say based on this that
>we leave as is, e.g. "Tables. Make line-by-line reading sensible. Summarize."
>
>-----
>
>PROPOSAL??: Check your work. Validate. Use evaluation tools, WCAG
>guidelines and checklist www.w3.org/TR/WAI-WEBCONTENT.
>WL Add full URL for both the guidelines and the checkpoints. And get
>shorter URL's...
>WL Proposal: Check your work. Validate. Use evaluation tools to verify
>accessibility
>in accordance with http://www.w3c.org/TR/wai-webcontent. Check off all
>checkpoints at
>http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324/full-checklist.html
>JA Proposal. Check your work. Use content guidelines
>www.w3.org/TR/WAI-WEBCONTENT. Validate HTML. Use evaluation tools to verify
>accessibility.
>JB Proposal: Check your work. Validate. Use evaluation tools, WCAG
>guidelines and checklist www.w3.org/TR/WAI-WEBCONTENT.
>JA like it.
>WC like it.
>WL: I'd still like to add the checklist URL and find a way to shorten
>both it and the one for the guidelines. I think we made room by
>curtailing #9.  But the "short & sweet?" is a "definite maybe" as Sam
>Goldwyn used to say.
>JA centered on the top of the WCAG page is a link to the checklist page.
>following the WCAG link on the card puts you one "click" or 2 "tabs" away
>from checklist page. I think "short & sweet" works as is.
>HB like it.
>CMN I prefer just the guidelines URI, on teh basis that in the guidelines
>first
>line, and again in teh contents is a checklist... (Besides, the checklist
>URI is pretty horribly long and difficult. Hardly a good example of writing
>clearly.)
>Oh. I do prefer the full URI, including the http:// bit
>JB Update from the printer: the "short & sweet" barely fits, with truncated
>URL, let alone any of the longer ones, and the URL looks really lousy...
>JB PROPOSAL. Check your work. Use evaluation tools, guidelines and
>checklist w3.org/TR/WAI-WEBCONTENT
>
>
>-----
>
>cW3C (MIT, INRIA, Keio)
>
>1999/07
>
>[as is.]
>
>
>
>
>----------
>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
>
----------
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 16:59:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:25 GMT