Re: Kynn's Feedback on AERT 26 April 2000 Draft

I'm going to try to remember to preface my comments with KB::.

At 12:24 PM 8/22/2000 , Wendy A Chisholm wrote:
>I responded to part of this message on 23 May 2000 [1]. (how time flies....)
>Kynn, thank you so much for the thorough comments!!
KB:::

No prob.  That's what happens when I have a long train trip and
too much time with a laptop.


>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.

KB::

It might be a good thing, if we've started doing recommendations,
to consider these kinds of usability/standardization issues relating
to link text in WCAG techniques.  (Naturally, such specific words
may be English-centric, so we will need to word carefully.)  WCAG
makes recommendations that link text be "meaningful" and D-links
are a specific kind of link text as well, so there is precedent for
this kind of suggestion.

>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::

We probably need to consider XSL here.  XSL would allow us to create
XML that doesn't validate to a public DTD, and yet may be accessible
(say, in IE 5.5 with JAWS) if an XSLT stylesheet is applied that
transforms it into XHTML or another public specification.  Maybe we
just need "Documents styled with XSL should produce result trees which
validate to a public DTD."

Also, should we be careful about locking into DTDs if there's the
possibility that schemas may replace them?  (I haven't kept up on
the XML schema work myself.)  DTD is one specific way to publish a
language's specs, but not the only one.

>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::

If Q worked correctly on current browsers you will still encounter
backwards-compatibility problems with older browsers which will
not recognize this tag.  Q was a very poorly thought-out addition
to HTML as it breaks backwards-compatibility, which as we know can
cause accessibility problems for some people who are unable to
upgrade easily.

>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::

Any attempt to draw a distinction between ABBR and ACRONYM, I feel,
is a lost cause.  We should consider them to be equivalent tags
at this point and just leave it at that.

>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::

I'm very sorry.  That was my perverse sense of humor at work.  There
is no INLAD reference anywhere.  That's merely a way of saying "you
can identify abbreviated forms just fine by putting them in
parentheses after the main text; this is common written language
(English at least) and we shouldn't discount that in favor of a
poorly supported, mostly-invisible tag."  It's clear without markup
that INLAD is an abbreviation for Inline Natural Language Abbreviation
Definitions -- and of course that's just a bit of warped irony at
work there.

Again, sorry, I will be a little more clear when I'm joking.

>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. 

KB::

Okay.  However, some tools -- such as Opera -- will display a
version of the page with all formatting instructions removed.
This could be a useful thing to suggest along with the manual
evaluation strategy.

>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::

But file extensions break on things such as, for example, the W3C's
graphics.  If possible, the information should first be drawn from
the MIME content-type as provided by the server.  I think we should
at least put a warning in place if we are going to recommend the use
of file extensions as a semi-reliable way of determining content
type.

>WC::  Added the following repair: Allow the author to replace MARQUEE elements with a script that creates scrolling text.

KB::

Add on here "...which follows <the rules about scrolling text>." :)

>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::

I dunno.  Five, seven, ten?

>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.

Agreed.

>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:

KB::
I stand corrected; I dunno what I was thinking.

I agree with (or can live with) everything else you wrote so I will
stop replying ... NOW!

-- 
Kynn Bartlett  <kynn@idyllmtn.com>                       http://kynn.com/
Director of Accessibility, Edapta                  http://www.edapta.com/
Chief Technologist, Idyll Mountain Internet      http://www.idyllmtn.com/
AWARE Center Director                         http://www.awarecenter.org/
Vote for Liz for N. Am. ICANN Nominee!        http://www.khyri.com/icann/

Received on Tuesday, 22 August 2000 15:56:30 UTC