Lower priority of some checkpoints

Looking at the checkpoint list in
  http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19990104/full-checklist

I advise we lower the priority (from P1 to P2) of 

A.5.2
   Use foreground and background color combinations that provide
   sufficient contrast when viewed by someone with color deficits or
   when viewed on a black and white screen. 

A.10.1
   For auto-refreshing or timed response pages, provide a second copy
   of the page where refresh only happens after a link has been selected
   (until user agents provide this ability themselves). 
                                                                                 
A.10.2
  Avoid any blinking or updating of the screen that causes flicker.

A.9.1 
  For frames, provide a fallback page for pages that contain frames
  (e.g., by using NOFRAMES in HTML at the end of each frameset). 


That's on the basis that these can simply be (e.g. lynx does it)
handled by the User Agent.

I know, some UAs will not handle them and so some combinations of
these UA and AT will create inaccessible problems, but more or less
everything theorically fall in that area (i.e. a UA has to comprehend
it for the user to digest it, the ALT text for instance) and so this
is a judgment call on the face of what's happening in the field (which
is why I mentioned lynx), and this is my position.

                                                                                 
A.9.2 
  For frames, ensure that the source of each frame is a markup file,
  such as HTML. 

Isn't it why we added a longdesc attribute to FRAME in HTML4, so that
one can actually do that and be accessible ?

Maybe it should say "unless you provide a longdesc to what this non
markup file is about".



A.1.6 
  Replace ASCII art with an image and alternative text.  


I think this one is either poorly phrased or too strong.

One should be able to draw a cow in ascii art providing it describes
it while doing so (ala "this is a ascii-art cow, jump to the string
'end-of-cow' if you're not interested").

Also, am I wrong in saying that smileys are not more inaccessible when 
accessed visually than orally or braillely ?

Most sighted people, when they first see ":-)", do not understand what
that means, and then someone explains it to them and they start
parsing smileys naturally. I don't see what difference that would make
in Braille for instance.

With voice output, one can also gets used to hearing ":","-",")",
and map it to the concept of smiley, right ? I can understand it might 
be inconvenient to to hear this stuff all the time, but is that a real 
inaccessible issue or a usability one ?

In addition, a UA can, without much technical difficulty, recognize
the various smileys (they are smiley database available) and replace
by the proper semantics.



Note that 
 A.1.3 
   For all image map links, provide alternative text for each link 
                                                                                 
 A.12.1
   For image maps, provide alternative text for links. 

look the same in the checklist

Received on Wednesday, 6 January 1999 09:19:16 UTC