- From: Wendy A Chisholm <wendy@w3.org>
- Date: Tue, 22 Aug 2000 15:24:19 -0400
- To: Kynn Bartlett <kynn@idyllmtn.com>, w3c-wai-er-ig@w3.org
Hello,
I responded to part of this message on 23 May 2000 [1]. (how time flies....)
Kynn, thank you so much for the thorough comments!!
I had originally said that "author" and "developer" can often mean
different things and I wasn't sure which to go with. Kynn suggested
"author." I like "author" better than "user" and went with that.
Kynn had several comments on the "Suggested message" language. Several of
the "Suggested message" sections have been deleted as we move towards
linking to examples rather than writing our own suggested language.
My responses (WC::) are interspersed with Kynn's comments (KB::).
--wendy
[1] http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000May/0071.html
KB::
>Technique 1.1.6:
>
> 1. It may be helpful to search for link text containing the
> word "transcript"?
WC::
I added this as an open issue because I would like to see what others think
about this. The link may or may not contain the word "transcript". Are
there other words that the link may contain? In WCAG we do not recommend
what the link should say. Also, what about proximity to the link to the
audio? What if there are several audio and transcript links on a page?
It now reads:
<blockquote>
Requirement: Audio file must be described within the document or document
must contain a link to a text equivalent file. @@Search for link text
containing the word "transcript?"
</blockquote>
KB::
>Technique 1.1.7:
>
> 1. An additional repair option would be to allow the user to
> reference an outside page that contains the text
> transcript, rather than embedding the text equivalent;
> this reference would then be embedded as a link within
> the OBJECT element.
WC::
Agreed. It now reads:
<blockquote>
Prompt user for text transcript or link to a text transcript of audio/video
file and embed it between start and end tag.
</blockquote>
KB::
>Technique 1.1.8:
>
> 1. How is it determined if "the relationships between the
> frames are apparent"?
WC::
This is pretty much taken from WCAG, but I tried to make it clearer by saying,
<blockquote>
If a FRAMESET has three or more frames and at least one of the frames does
not have a "longdesc" attribute, ask the user to determine if the
relationship between frames is obvious (from the titles of each frame) or
if the relationship(s) need to be described.
</blockquote>
KB::
>Technique 1.2.1:
>
> 1. If the hotspots on an image map can be determined, the
> TITLE attributes of pages referenced by the hotspots *may*
> provide useful suggestions for "alt" text.
WC::
Added:
<blockquote>
If possible, fetch the TITLE of the link target.
</blockquote>
KB::
> 2. Bouncing requests off a server should be avoided unless
> requested by the author, because overuse of this technique
> may lead to traffic problems. (An image that is 468 by
> 60 pixels in size could generate up to 28,080 requests if
> this technique is misapplied.) Spacing of at least 5-10
> pixels apart in a grid pattern may be more useful; if a
> hotspot is missed, this may indicate a different accessibility
> problem related to users without fine motor control.
WC::
deleted the suggestion to ping the server randomly for coordinates.
KB::
>Technique 2.1.1:
>
> 1. A tool may be able to generate a "monochrome" version of the
> page with all color formatting removed (and possibly images
> converted according to a set of filters) -- this would be
> useful for visual inspection by the author.
WC::
added "Display the page without color formatting so the author can see what
the page looks like without color."
KB::
>Technique 3.2.1:
>
> 1. An XML document may not require a !DOCTYPE statement.
WC:: It now reads:
<blockquote>
HTML/XHTML documents must contain a !DOCTYPE ... declaration before the
root element.
A valid XML document must contain a !DOCTYPE ... declaration before the
root element, although a well-formed XML document does not have to have a
!DOCTYPE ... declaration.
Documents of type HTMLmust conform to the HTML specification and the list
of public text identifiers
Documents of type XHTML must conform to the XHTML 1.0 specification.
Documents of type XML must be well-formed and should validate to a public DTD.
</blockquote>
KB::
>Technique 3.3.1:
>
> 1. Should the CSS be validated if identified?
WC:: added, "If CSS is used, validate it (refer to the W3C CSS Validator)."
KB::
>Technique 3.6.1:
>
> 1. DL tags are not followed by LI elements, they are followed
> by DT and DD. Proper use of these elements can be checked
> for, and irregular use of DT/DD can be flagged.
WC:: reworded this to read, "Each UL/OL tag must be followed by at least
one LI, while each DL must be followed by at least one DT/DD pair. (This
avoids the use of lists to create formatting e.g. via UL UL UL... )"
KB::
>Technique 3.7.1:
>
> 1. Suggesting Q will always be disaster. Why does this
> element even exist?
WC:: Note sure. have left this as an open issue.
KB::
> 2. The suggested identification #1 is problematic because
> not everything inside quotes should be marked up with
> Q/BLOCKQUOTE.
WC:: Since Q does not work correctly, I can see your point. What if Q did
work correctly, why wouldn't you put text in a Q/BLOCKQUOTE element?
KB::
> 3. For suggested identification #2 -- what defines "indented
> text"?
WC:: I've added, "Indented text - text that begins with a tab character or
style sheets have been used to create a wider left margin and possibly a
wider right margin."
KB::
>Technique 3.7.2:
>
> 1. Not all quotes longer than 10 words should be marked up
> with BLOCKQUOTE; this metric does not make sense.
>
> 2. Even if it made sense in English -- what are the i18n
> issues connected to the use of quotations?
WC::
Good point. I've edited it to read:
<blockquote>
Inline quotes (marked with Q) have at least one word in front of, or
behind, the quote text.
The whole page or large sections of a page are not marked with
BLOCKQUOTE. If this is the case, it is a possible indication that the
author is using BLOCKQUOTE for formatting rather than to mark a quotation.
</blockquote>
KB::
>Technique 4.2.1:
>
> 1. Your understanding of abbreviation ("any word greater
> than 2 characters that is all capital letters") and of
> acronym ("starts with a capital letter, contains lower
> case characters and ends with a period") do not mesh
> with mine -- in fact, I consider your definitions to be
> reversed. However, much discussion on this topic has
> yielded the consensus that there is no consensus on the
> proper use of ABBR/ACRONYM! Thus, identification rules
> such as these should be avoided.
WC::
These definitions were reversed. I have left them in for now. Now reads:
<blockquote>
Potential acronym:A collection of 2 or more capitalized characters.
Potential abbreviation:
A collection of 2 or more characters where the first one is capitalized,
the rest are lower case, and the last character is a period.
</blockquote>
KB::
> 2. The first suggested repair seems to imply that a definition
> should be given on every use of the of the abbreviated form;
> this is not my understanding.
WC::
correct. I edited this to read, "Ask the author if the acronym or
abbreviation was defined elsewhere on the page and if so do nothing,
otherwise ask the author to enter a definition for the abbreviation of
acronym and attach it to the first instance."
KB::
> 3. It is possible to identify abbreviated forms through the
> use of Inline Natural Language Abbreviation Definitions
> (INLAD), and this should be accounted for in this technique.
> Abbreviated forms within parentheses should probably be
> ignored?
WC:: Is this reference online? If so can you give me an address? I've
looked but can't find one.
I've added the requirement, "Do no worry about words followed by a
potential abbreviation or acronym in parentheses."
KB::
>Technique 5.4.1:
>
> 1. An additional repair function would be to allow repositioning
> and reordering of tables.
WC:: I thought this fit better with 5.3.1 than 5.4.1. Thus I added the
following to 5.3.1, "Allow the author to reposition cells or reorder the
table."
KB::
>Technique 6.1.1:
>
> 1. Generate and/or display a version of the page without
> styles.
WC:: I think you are suggesting that this is the text of the technique. In
fact, this is a manual evaluation strategy. I did change the name of the
technique to be HTML/XHTML specific. It now reads:
<blockquote>
Technique 6.1.1 [priority 1] Verify that an HTML/XHTML document is readable
when style sheets are not applied.
Evaluation
Elements:
LINK rel="stylesheet"
STYLE
At least one "style" attribute used on any element.
Requirements: The author must verify if an HTML/XHTML page is readable
without style sheets. Generate and/or display a version of the page
without styles to help the author decide.
Repair
Display an author notification if any use of style sheets is detected.
</blockquote>
KB::
>Technique 6.2.1:
>
> 1. Relying upon a set of file extensions is a poor choice for
> this. There is no requirement that a file must have a particular
> name to be a valid markup file.
WC:: This is the best suggestion so far. If you look at how windows and
several windows programs handle file extensions they look for these. We
may get some false positives with this we may also miss some, but it is a
decent general rule of thumb.
KB::
>Technique 6.5.1:
>
> 2. It may be possible to check the NOFRAMES element a little better
> by comparing the number of links and their destination to the
> content of the various frames. All links accessible through
> the framed page should be accessible through the NOFRAMES
> section -- except that separate pages/URIs for framed/non-framed
> pages might prevent this. The numbers can be counted, however;
> a NOFRAMES section with only 3 links compared to a framed version
> with 30 links is a good sign that navigation links are not
> present. (Also, the text of the links, not just the destination,
> may be considered.)
WC:: Good suggestion. I have expanded the 2nd bullet to read:
<blockquote>
The contents of the NOFRAMES element must provide the necessary links to
navigate the site. One way to check is to compare the number of links and
their destinations in the NOFRAMES with the number of links and their
destinations in all of the FRAMES combined.
</blockquote>
KB::
>Technique 7.2.1:
>
> 1. An equivalent for BLINK is defined in CSS Level 2 -- as a
> substitute for BLINK, the following may be used as well as
> those listed in the repair suggestion:
>
> <SPAN STYLE="text-decoration: blink;">
>
> As this is part of an official W3C specification, it should
> not be ignored.
WC::
I made the example more specific to say, <Q>SPAN- allow the author to enter
attributes for the element, such as the CSS "text-decoration: blink;".</Q>
KB::
>Technique 7.3.1:
>
> 1. An alternative is to provide a scripted solution -- this has
> the advantage (as does the BLINK suggestion above) that it does
> not restrict the author's creative decisions. If they're
> using MARQUEE, it's not by accident -- it's because they want
> (or wanted) a scrolling text bar.
WC:: Added the following repair: Allow the author to replace MARQUEE
elements with a script that creates scrolling text.
KB::
>Technique 7.3.2:
>
> 1. Why is this presented as a Priority 1 checkpoint? WCAG 7.3 is
> Priority 2.
WC:: typo
KB::
>Technique 7.5.1:
>
> 1. The use of HTTP headers -- via web server configuration and/
> or server-side scripting -- should be presented to the author as
> an option.
WC::
Good suggestion. I've added a bullet that says, "Suggest that the author
use HTTP headers -- via web server configuration and/or server-side scripting."
KB::
>Technique 9.3.1:
>
> 1. Adding handlers should be suggested; replacing handlers should
> not, due to browser support issues. Changes should never be
> suggested that will break the user experience for the majority
> of site users!
WC:: ok, removed the words "or replace" from the Repair.
KB::
>Technique 9.4.1:
>
> 1. This check should likely be invoked only if there are more than
> a few links. There is little point in TABINDEX for pages with
> only a few tab-able elements.
WC:: I added a bullet to the list. How many links is "more than a few links?"
KB::
>Technique 9.5.1:
>
> 1. Likewise, there is not a need for ACCESSKEY on *every* page,
> just *most* pages.
WC:: add as open issues, <Q>@@Does every page require an "accesskey" or
only some of them? How does the author decide which ones?</Q>
KB::
> 2. If ACCESSKEY is used, the specific access keys need to be
> identified and instructions given on how to use them. This
> should be included as part of the evaluation -- "have you told
> your users how to access the ACCESSKEYs on this page?"
WC::
I added the following bullet to the evaluation:
<q>If accesskeys have been used, has the author identified which keys are
defined and how to use them?</q>
And this to the repair:
<q>If accesskeys are used, encourage the author to provide a description
that identifies which keys are defined and how to use them.</q>
KB::
>Technique 10.1.1:
>
> 1. We must not "completely avoid new windows" -- instead we must
> tell the author how to make them accessible.
WC:: I believe this is an issue for WCAG that needs to be clarified in a
Techniques document with examples.
KB::
> 2. Why is this Priority 1? WCAG 10.1 is Priority 2.
>
>Technique 10.1.2:
>
> 1. Why is this Priority 1? WCAG 10.1 is Priority 2.
WC:: typos
KB::
>Technique 10.2.1:
>
> 1. With the use of the LABEL element, is there a need for labels to
> be placed beside the associated form control? That is not
> obvious to me from reading WCAG/WCAGTECH. Is this addressing
> those LABEL elements?
WC:: Yes, because the LABEL "for" attribute may not be supported. LABEL
may not even be interpreted by some user agents/assistive technologies, but
it won't break anything marking it up as a label and will help those UAs
that do support it.
KB::
> 2. I don't recall seeing the "rules" associated with locating
> labels (as described in the repair suggestion) in WCAG/WCAGTECH
> -- if these are useful, then they should be folded back into
> WCAG and should not be accessibility guidelines spontaneously
> generated by this document.
WC:: good point. I'll pass by WCAG WG.
KB::
>Technique 10.4.1:
>
> 1. Why do "checkbox" or "radio" boxes require at least one word
> of text in "value" attributes? There is no need for such a
> restriction.
WC:: It's in the HTML 4.01 spec:
http://www.w3.org/TR/html4/interact/forms.html#adef-value-INPUT
<blockquote>
value = cdata [CA]
This attribute specifies the initial value of the control. It is optional
except when the type attribute has the value "radio" or "checkbox".
</blockquote>
KB::
> 2. "Radio" boxes should have at least one value that is CHECKED.
WC:: I added the bullet, <q>INPUT elements of type "radio" must have at
least one that is "checked".</q>
KB::
>Technique 10.5.1:
>
> 1. Does markup count as "non-whitespace"? Images, for example,
> may be used as separators. Can they have NULL "alt" text,
> which may render them as "whitespace" on some browsers? What
> about the following?
I edited the bullet to read, "Non-whitespace is any text character
including markup."
KB::
>Technique 11.1.1:
>
> 1. It may be irresponsible to simply present W3C technologies and
> imply that this will increase accessibility when in fact the end
> result will be denying access to 99.99% of the audience.
WC:: Note that this technique says "where appropriate." We aren't
suggesting a flat-out conversion to everything W3C.
KB::
>Technique 11.2.1:
>
> 1. Why would we want to suggest that IMG should be replaced with
> OBJECT? That falls under the category of "grossly irresponsible
> suggestions which work on paper but fail in practice."
WC::
Philsophically this is the direction we need to head. IMG is currently the
way to go, but OBJECT is cleaner in many ways. I agree that with today's
browser we don't want to suggest OBJECT instead of IMG. Thus, I have edited
this section to read:
<blockquote>
Allow the author to replace FONT with CSS.
Allow the author to embed IMG and APPLET within OBJECT or to replace them
with an OBJECT element.
Note. Before making these changes, the author should be made aware of the
current situation of browser support of CSS and the OBJECT element.
</blockquote>
KB::
>Technique 11.3.1:
>
> 1. Some of these suggestions may decrease accessibility if used
> irresponsibly.
WC:: True, as with most things on the Web. Do you have a suggested change?
KB::
>Checkpoint 12.3:
>
> 1. A possible technique would be to check to see if the size is
> over a certain limit -- say, 50K of text -- and then ask if the
> page should be split along lines inferred from H1..H6
> structure.
WC::
Six techniques for this checkpoint have been added since you wrote. The
last one looks at the amount of text (triggered if >1000 characters) and
suggests headers be used to break it up. Not sure how 1000 was reached...
KB::
>Technique 12.4.1:
>
> 1. Also there should be a check to ensure that the "id" value
> is unique. (This is part of having a valid "id" attribute,
> so perhaps it is assumed.)
WC:: to be safe I reworded this:
<q>Allow the author to set a unique "id" attribute for each INPUT element
in the document then set the "for" attribute of each LABEL element so it
matches an INPUT element.</q>
Also, I link to the HTML spec where it says that id must be unique.
KB::
>Technique 13.2.1:
>
> 1. Why are "more" and "follow this" considered suspicious?
WC:: You mean, 13.1.1.
Because oftentimes these are the only words in a link and appear several
times on the page but link to different items.
> 2. Article names -- especially academic articles -- may easily
> have anchor text that exceeds 60 characters. The phrasing
> "should be shortened" is too absolute in the suggested
> message.
WC:: True, but more than likely it is something that ought to be shortened.
Suspicious does not mean it is not allowed, just that it has
characteristics that are likely to be an issue.
KB::
>Document Rating:
>
> 1. Effective, worthwhile tools will not rely merely upon the
> WCAG conformance levels and should ideally provide several
> other optional methods of rating accessibility.
WC:: The point of this document is to provide strategies for tool
developers who want to help people determine if their web content conforms
to WCAG 1.0. Therefore, that's the only conformance scheme we are
concerned with in this document. If people want to develop other schemes,
that's their choice.
KB::
>Appendix B:
>
> 1. Images can have any suffix -- what matters is the mime type
> returned by the server, not the "file name" part of the
> URI. For example, http://www.kynn.com/+guilt is an image.
> Also, many image formats are not listed here.
>Appendix D:
>
> 1. See Appendix B comments.
WC:: Yes, I propose replacing these appendicies with a linkt to a list of
mime types.
--wendy
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--
Received on Tuesday, 22 August 2000 15:23:43 UTC