Re: About WAI Accessibility Guidelines

Review of 
  http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19980825-txt.html


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)


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

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.

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.


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

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

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

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

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

>   2. For all applets (APPLET) provide alt-text (via the "alt"
>      attribute) and content. [Priority 1]  

I suggest "and content (OBJECT)".

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

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


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

If someone puts some audio music in the background, I just need to
know that with a title or some label. If someone is asking me to click
here to hear their last new song for appreciation, getting a
transcript of the song words in not going to help, although it could
be helpful for some other reasons.

On the other hand, if a video of the rep from Swissair is the only
media used to get some news about a crash, then it better be provided
as text as well.

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

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

> Techniques:
> 
>   1. Ensure that the source of each frame is an HTML file. [Priority 1]

I'd remove this one and move the Frame technique in the technique
document by itself (see my comments there)
 
> 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.
 
> Rationale:
> 
> Otherwise, if color is used to convey information, users who cannot
> differentiate between certain colors (and users with devices that have
> non-color or non-visual displays) will not receive the information.
> When foreground and background colors are too close to the same hue, they
> may not provide sufficient contrast when viewed using monochrome displays or
> by people with different types of color blindness.
> 
> Techniques:
> 
>   1. Don't use color to convey information unless the information is also
>      clear from the markup and/or text. [Priority 1]
>   2. Use foreground and background color combinations that provide
>      sufficient contrast when viewed by someone with color blindness or when
>      viewed on a black and white screen. [Priority 1]

There are two different issue here.

Using color instead of markup is one, and should be a structural item,
folded into the next guideline in fact, and avoid poor contrast is a
different thing altogether, and should be put in C, with things that
make sense, but that UA - and most UA do - can help with, so it's less
important.


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

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

>      then, tables (to control layout) and bitmap text with alt-text

I'd add "simple table"

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

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

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

>   2. Avoid phrases that are not meaningful on their own such as "click
>      here." [Priority 2]

A P1.

>   1. Use Bobby, an automated accessibility, browser and HTML validation
>      tool, available at http://www.cast.org/bobby/ [Priority 3]

A P1 or P2.

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

P1

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

P1

>   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



Coming up some comments on the Techniques.

Received on Friday, 4 September 1998 06:05:24 UTC