Re: About WAI Accessibility Guidelines

Daniel,
thanks for the comments.  you raised quite a few issues!  See our comments
interspersed throughout yours.
  
>I'll start with the overall sectioning.
>
>In  
>  http://lists.w3.org/Archives/Public/w3c-wai-gl/1998JulSep/0122.html
>
>I exposed ideas for a simpler structure, which I think had received
>some good backup on the list (from Nir, Charles).
>
>I notice in this version that things have changed toward a simplified
>organization, good, but I still have some issues.
>
>Since there was no discussion with the editors on the list about this
>issue, I wonder if there is agreement but misunderstanding (I doubt
>that, knowing Wendy :-), or a different opinion as to what should be
>used for section grouping (so let's talk about it)
>
thanks for your faith, Daniel.  <grin>
Yes, we agreed that the organization needed to be simplified.  We heard
that from a few people.  Thus, we took the suggestions we were given and
worked out what you have read in the most recent release.  We think it
works pretty well <grin>, and would like to comment further on your
suggestions for moving a few of the guidelines around.  More comments follow.

>
>>  A. Make sure pages transform gracefully across users, techniques,
>   and situations  
>
>A little too long for a section head IMHO, but the that's the idea.
>Maybe "A. Degrade gracefully" "A. Graceful Transformation" or just
>"A. Textual Equivalence"
>
We'll leave it for now.  Although it is a bit wordy, we hope it is clear
and can stand well on its own.

>More to the point, I think the following guidelines belong in a B
>extended to "Structural/Navication" issues.
>
>>  A.6. Ensure that text and graphics are perceivable and
>>       understandable when viewed without color 
>>  A.7. Indicate structure with structural elements, and control
>>        presentation with  presentation elements and style sheets 
>>  A.9. Provide supplemental information needed to pronounce or
>>       interpret abbreviated or foreign text.  
>>  A.12. Use features that enable activation of page elements via
>        input devices other than a pointing device 
>
>That's because these are not about degrading in text but adding
>semantics for a better understanding and easier navigation.

>
Hmm.  

The first section (A) is about "Graceful transformations."  A
transformation is not necessarily a textual representation of a graphical
or auditory element.  It could be a still image of a frame from a movie, or
auditory descriptions of the visual presentations within a movie.  So, our
definition of transform gracefully is, "a page remains usable despite user,
technological, or situational constraints."  Therefore, A.6, A.7, A.9, and
A.12 are definately guidelines for graceful transformation.

>and I think
>
>>  A.14. If, after all of your best efforts, any page is still not
>        accessible then you MUST provide a link to an alternative page 
>
>Should come last, so probably in C.
>
again, this is the last ditch way to make a page transform gracefully. so
we believe it should stay where it is in A.

>
>> [PRIORITY 3]
>>      This guideline should be followed by an author to make it easier for
>>      one or more groups of users to access information in the document.
>>      Implementing this guideline will improve access to WWW documents.
>
>For P3, I'd suggest using "may", not "should", so that it gives us a
>clean IETF look-alike must/should/may wording.
>
already done (Charles Mc. had the same comment).

>> Each Guideline and each Technique has a priority listed. For the
guidelines,
>> the priority refers to the importance of addressing the issue identified by
>> the guideline. For Techniques, the priority refers to which technique best
>> improves accessibility with respect to this guideline. For example, a
>> Priority 1 Guideline may have a Priority 1 Technique, which must be done to
>> provide accessibility, and a Priority 3 Technique, which may also be
done to
>> help address the issue.
>
>Meta-question: what is going to be the W3C Recommendation ? Just the
>guidelines document, or both the guidelines and the companion
>techniques document ? W3C has the notion of non-normative annexes, and 
>we could attach (even in a separate file, it doesn't matter) the
>techniques as such.
>
>What about the "leading" techniques section after each guideline, is
>that going to be normative ? I think it should stay in the main
>guideline document in any case, as they really help understand the
>issues. 
>
The recommendation will be just the linearized version of the guidelines
(to be posted after this is sent).  The techniques will be a separate
non-normative document.  However, links to the techniques document will
appear throughout the guidelines - as they appear now.  (The "leading"
techniques are the items in the techniques column?)

>> 1. Provide alternative text for all images, applets, and image
>> maps. This includes images used as submit buttons and all of the
>
>In the interest of genericity, that is, being able to reuse these
>guidelines for other markup language (in XML), we should abtract what
>we mean by image, imagemap, applet. I think providing a definition of
>it at the end is OK, we don't need to change the terms used (even if
>they are HTML specific).
>
so, if we leave this technique link as is, but include a definition in our
definitions, this will satisfy this concern?  How about:  
image:  a graphical element presenting information visually
image maps:  images that contain links
applets: applications that can not stand alone (i.e., a sub-process that
runs within a user agent process space). 

>> Otherwise, users who are blind, have low vision, or have chosen not to view
>> graphics will not know the purpose of the visual components on the page.

>
>Instead of "have chosen not to" I'd say "cannot view graphics"
>otherwise people might react "Oh, you don't *want* to see my
>graphics, then get lost".
>
how about "or any users who have chosen not to view graphics."  Some people
choose not to view graphics either because they can not due to a physical
disability, or they have chosen not to because it would take too long to
download.  

>>   1. For all images (IMG) provide alt-text (via the "alt"
>>      attribute). [Priority 1] 
>
>We should have a lead to spacer images, bullets and difference between
>pure decoration and functional images at that point, with pointer to
>more detailed techniques.
>
we think it best to leave the link as is, and provide the detail in the
techniques document.

>>   2. For all applets (APPLET) provide alt-text (via the "alt"
>>      attribute) and content. [Priority 1]  
>
>I suggest "and content (OBJECT)".
>
content may be provided using the APPLET element.  OBJECT is covered in
technique #7 ("If OBJECT is used...).  

>>   4. Don't use server-side image maps unless the same functionality or
>>      information is available in an alternative accessible format.
>>      [Priority 1]
>>   5. For all graphical buttons (INPUT type="image") provide alt-text (via
>>      the "alt" attribute) [Priority 1]
>
>INPUT image is a special case of server-side image, and alt-text alone 
>doesn't provide the necessary information in most case. There are to
>be avoided at all cost, since it's very unlikely that people will
>provice a list of text links next to an INPUT button (ISO HTML did not 
>retain INPUT image for instance).
>
exactly, which is why we have technique A.6.4 ("do not use an image map to
create a set of buttons...") and per the earlier e-mail response to
Marja-Ritta we are moving it into A.1

>>  7. If OBJECT is used to incorporate an image, applet, or script
>>     into a page, use any of the many ways to convey that 
>>     information in cases where the OBJECT cannot be
>>     perceived. [Priority 1]
>
>If we're going to have the techniques be non-normative, we need to be
>a little more careful and try to have sentence that stands by
>themselse, so when we say "use any of the many ways" is a too vague.
>
since this sentence appears in the guidelines (which will be normative) and
we aren't sure what all is possible or needed, we were purposefully vague
with this one.

>> 2. Provide descriptions for graphics, scripts, or applets that convey
>> important information unless they are already fully described (through
>> alt-text or in the document's content). [Priority1]
>
>This guideline has technique wording in it, I'd just remove these
>words " unless they are already fully described (through alt-text or
>in the document's content)." and add the document's content part as a
>technique as well.
> 
some of the technique type of wording is needed in order for an author to
determine if they need to follow this guideline.  alt-text is "a" technique
described under "alternative text."  How about we change this to, "2.
Provide descriptions for graphics, scripts, or applets that convey
important information unless they are already fully described (through

alternative text or in the document's content). [Priority1]"

>> 3. Provide textual equivalents (captions) for all audio information.
>
>I repeat what I have said before, I think captions/transcripts should
>only be required for *important* information, much like longdesc for
>image, and a clear definition of important should be provided, that is
>applicable to image, audio, video, etc: something is important if
>understanding it in details is necessary for the overal understanding
>of the document (thus the need for a longdesc, a complete transcript,
>etc)
>
hmmm, this sounds similar to: "If an image is decorative, what do we put
for the alt-text?"  because *something* is needed.  It's going to depend on
how the audio is incorporated into the page.  If someone provides a text
link to the audio clip, oftentimes the link phrase provides sufficient
information.  In your example, I would argue that a transcript *should* be
provided since there are many ways to appreciate a song.  If the artist is
not only a good guitar player but a poet as well, I'm gonna want to read
those lyrics.  However, if it's Beethoven's 9th, will I provide the score?
No, but the caption "Beethoven's 9th played by the Chicago Symphony
Orchestra" should be sufficient.  Therefore, all audio gets captioned.

>
>> Otherwise, users who are deaf, or hard of hearing, or who have sound turned
>> off cannot perceive the information presented through speech, sound
effects,
>> music, etc.
>
>Same remard, "people who have turned sound off" should be "people who
>do not have sound on their computer" for instance.
> 
not exactly, see comment re: images.

>>   1. For short animations such as animated "gif" images, provide alt-text
>>      (see A.1)and a short description (see A.2) if needed. [Priority 1]
>
>"short descrition" ? You mean "long" ?
>
oops. yep.

>> 5. Design documents in a way that allows alternative presentations to be
>> provided. [Priority 1]
>
>This one is far-fetched. Why would someone design document in a way
>that do not allow for alt presentation to be provided if she/he
>intends to provides them ?
>
yes, this one got stretched pretty thin to accomodate the technique.  We've
been wrestling with it for a while and earlier this week folded the
technique (source of a frame must be an HTML file) into frames transforming
gracefully (as you suggested, also).
  
>> 6. Ensure that text and graphics are perceivable and understandable when
>> viewed without color. [Priority 1]
>
>OK, that's a structural thing and should be in B.
> 
Well, it could fit into "separate structure from presentation" but we
thought it would be easier for an author to understand and find if we
grouped the two color techniques into one color guideline.  

<snip, snip> more about color and structure <snip, snip>

>>   3. Do not use an image map to create a set of buttons in a form. Instead,
>>      use separate buttons or images (accompanied by alt-text). [Priority 2]
>
>I don't understand this one.
>
see earlier discussion about image maps.

>>   4. Use style sheets to control layout and presentation wherever possible
>>      as soon as a majority of browsers in use support them (see

>
>I'd add "support them well".
>
agreed.  done.

>>      then, tables (to control layout) and bitmap text with alt-text
>
>I'd add "simple table"
>
o.k.  done.

>>   4. Avoid any blinking or updating of the screen that causes flicker
>>      between 4 and 59 Hertz. [Priority 1]
>
>Where the heck did I put my radio-frequency analyser ? Ah I know, it's 
>with Gramma' cold fusion reactor in the basement.
>
>Seriously, what do we expect people to do with that ?
>
tee-hee.  if we change Hertz to "flashes per second" does it still make you
want to dig out the analyser from the basement?  We can't provide a good
way to determine the high end (the low end is fairly simple), but know it
is an established set of limits.  any ideas?    

>> 14. If, after all of your best efforts, any page is still not accessible
>> then you MUST provide a link to an alternative page that:
>> 
>> Rationale:
>> 
>>   1. is accessible,
>>   2. has equivalent information,
>>   3. is updated as often as the inaccessible page.
>
>This is not a Rationale.
>
>Rationale is: it's bad to duplicate but it's better than being not
>accessible. 
>
hmmm. What you have as rationale is part of the guideline.  The rationale
is, "Some pages will be unable to transform gracefully at this time either
because the visual components are too complex, or because assistive
technologies or user agents (browsers) are lacking a specific feature.  For
example a complex table (e.g., of text and numbers) must be converted into
a linear version."
>> Techniques:
>> 
>>   1. Until user agents and screen readers are able to handle text presented
>>      side-by-side, all tables that lay out text in parallel, word-wrapped
>>      columns require a linear text alternative (on the current page or some
>>      other). [Priority 1]
>
>I was happy to see some good-sense coming in for using simple TABLE
>for layout above, but now that: requiring parallel text-only version
>of table. This is suicidal.
>
>I repeat my notes from before:
>  - it's a UA issue, and it's not specific to TABLE but to anything a
>    UA can only layout side-by-side.
>    Example: I can use CSS float instead of TABLE, but IE will not let 
>    the user override my float (turn off CSS completely that is) so
>    the problem remains.
>
>We, as a group, seriously need to draw the line between what's for UA
>to deal with, and what's for Authors to deal with.
>
>More or less everything can fit below or above the line we draw: ALT
>text for image for instance: a very sophisticated UA could use OCR
>technology to extract ALT text from any images. Of course, we don't
>want to say that, but we need to be realistic about what is common
>practice/doable in 1998. 
>
>Color contrast for instance is clearly for the UA to resolve, and so
>is linearization of simple TABLE.
>
yes, it is a UA issue and luckily a couple UAs have made some headway on
this (lynx and Jaws).  So, we are moving this to A.12 - "Use interim
accessibility solutions so that assistive technologies and older browsers
will operate correctly" and making it a Priority 2.


>>   2. Avoid phrases that are not meaningful on their own such as "click
>>      here." [Priority 2]
>
>A P1.
>
we continue to disagree with this one.  a series of "click here's" does not
make the page inaccessible.  Meaningful link phrases make the page easier
to use.  a p2.

>>   1. Use Bobby, an automated accessibility, browser and HTML validation
>>      tool, available at http://www.cast.org/bobby/ [Priority 3]
>
>A P1 or P2.
>
using bobby does not make a page accessible.  nor does it necessarily make
it easier to use.  we think this ought to remain a p3.

>>   2. Use the W3C HTML Validation Service, available at
>>      http://validator.w3.org/ [Priority 3]
>
>P1
>
see comment about bobby.  

>>   3. Use the W3C CSS Validation Service, available at
>>      http://jigsaw.w3.org/css-validator/ [Priority 3]
>
>P1
>
see comment about bobby.

>>   4. Test the site with at least:
>>         o a text-only browser (e.g., Lynx or a Lynx emulator such as Lynx
>>           Viewer or Lynx-me) [Priority 3]
>
>P2
>
still only a good practise.  does not necessarily increase the usability or
accessibility of the page.  we think it should remain p3.

--editors and chairs

Received on Friday, 4 September 1998 20:49:09 UTC