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

 
8.  Frames:

I like Alan's addition of "meaningful"  

    PROPOSAL:
8.  Frames. Meaningful Title frames, and provide _NOFRAMES_ equivalent.

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


____________________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