Re: Please review: Techniques For Evaluation And Implementation Of Web Content Accessibility Guidelines

----- Original Message -----
From: "Wendy A Chisholm" <wendy@w3.org>
To: <w3c-wai-au@w3.org>; <w3c-wai-gl@w3.org>; <w3c-wai-ig@w3.org>
Cc: <w3c-wai-er-ig@w3.org>
Sent: Wednesday, March 15, 2000 8:04 PM
Subject: Please review: Techniques For Evaluation And Implementation Of
Web Content Accessibility Guidelines


> This review period will end Thursday, April 6 2000.  Please send
review
> comments before that date to w3c-wai-er-ig@w3.org.  Archives for this
list
> are at http://lists.w3.org/Archives/Public/w3c-wai-er-ig/.

Here's my comments:

> Technique 1.1.1 [priority 1] Check IMG elements for valid "alt"
attribute
> Suggested repair:
>
> If the image is assumed to be a bullet, suggested text should be
"bullet".
> If the image is assumed to be a horizontal rule, suggested
> text should be "horizontal rule".

If the image is assumed to be a bullet, one should suggest the author to
use 'ul' and 'li' with style sheets.
If the image is assumed to be a horizontal rule, one should of course
suggest the author to use the 'hr' element (see <URL
http://ppewww.ph.gla.ac.uk/%7Eflavell/www/hrstyle.html >).
Not doing this, would violate Guideline 3 -- "Use markup and style
sheets and do so properly".

> Technique 1.1.7 [priority 1] Verify that text equivalents are
> provided for embedded audio files where necessary

Is this really *always* necessary? If someone uses background music
(e.g. some piano music) on their site (which of course is a *Bad Idea*),
IMHO there's no reason to provide a text equivalent, since the
background music would degrade very gracefully.

The technique says "where necessary", but suggested message is "Audio
and video files *require* [my emphasis] a text equivalent."

> Technique 1.1.12 [priority 1] Verify that valid text equivalents are
> provided for PRE and XMP elements used to create ASCII art.

For detecting ASCII art, you might be interested in reading this
Bugzilla report <URL: http://bugzilla.mozilla.org/show_bug.cgi?id=20195
>. And perhaps this <URL:
http://bugzilla.mozilla.org/show_bug.cgi?id=16507 > too.

> Technique 2.2.1 [priority 3] Test the color attributes of the
> following elements for visibility:

Should also check if a background colour is defined when text colour is
(for cascading to work with user style sheets). And if one or more of
'vlink', 'alink', 'link' exists, 'bgcolor' and 'color' should also be
used.

> Technique 3.1.1 [priority 2] Verify that elements do not need
> to be converted to an appropriate markup language.
> Suggested message:

There's one extra (empty) bullet here.

> Technique 3.7.1 [priority 2] Verify instances where quote markup
should be used.
> Discussion Status:
> Q is not supported in today's browsers, thus converting quotes
> marks to Q will basically delete the quote marks for all users.
> what do we suggest in the meantime?

I've used the CSS rule 'q { color: #color; background: #color; }' on
some of my pages. IE supports CSS on Q elements (but doesn't display the
quote marks).

> Requirement: quote should be marked up with Q or
> BLOCKQUOTE. Potential quotes can be identified by:
> Any text that is enclosed by quote marks (" " or ' ').

And other quotation marks, e.g. 66s, 99s and guillemets (french
quotation marks).

Quotation marks in Unicode are U+2018-U+201F, U+2039-U+203A,
U+275B-U+275E, U+301D-U+301F, U+FF02, U+00AB and U+00BB -- possible some
more.

The algorithm must be able to deal with nested quotes, e.g. "outside
quote 'inside quote' outside quote" and «outside quote <inside quote>
outside quote» (where <> isn't <> but U+2039 and U+203A (these arent
available in iso-8859-1).

It should also be able to deal with french quotation marks where there
is a small space (not a normal space) between the text and the enclosed
quotation marks («»).

> Technique 3.7.2 [priority 2] Verify that Q and BLOCKQUOTE are used
properly
> Requirement:
> Inline quotes (marked with Q) have at least one word in front of,
> or behind, the quote text and are less than 10 words
> Long quotes (marked with BLOCKQUOTE) are greater than 10 words.

An inline quote will often contain more than 10 words. And I'm pretty
sure that

<blockquote>...</blockquote>

has a sementically different meaning from

<p><q>...</q></blockquote>

The latter can be used when marking up a novel. Even when an entire
paragraph contain a person's line, 'blockquote' should not be used.

> Technique 3.7.3 [priority 2] Verify that BLOCKQUOTE is not used for
formatting
> Evaluation:
> Element: BLOCKQUOTE unless text content has quote marks ("" or '').

If the 'blockquote' has a 'p' child, we can be pretty sure that it's a
real quote, right? Most people just write

<blockquote>Indented text</blockquote>

('blockquote' *must* contain a block element (or 'script') to be valid
HTML.)

> Technique 4.3.1 [priority 3] Verify the primary language of the
document
> Must be one of the ISO 639 language codes.

And sub-codes, e.g. en-UK and no-NYN should not be flagged as errors.

> Technique 5.6.1 [priority 3] Check table for header abbreviations
> Discussion Status:
> How determine if an abbreviation is pronounceable? ASCII characters
only?

NO! If you do that, then 'Låvedør' would be unprouncable, which it isn't
(in Norwegian). Unicode 3 contains almost 50 000 characters, most are
pronouncable, not just ~96 of them!

> Checkpoint 7.2 - Until user agents allow users to control blinking,
avoid causing content to blink

Should also check for 'text-decoration: blink'.

> Checkpoint 12.3 - Divide large blocks of information into
> more manageable groups where natural and appropriate
> @@Any suggestions??

A paragraph with more than 200 words should be divided into two or more
paragraphs?

Three or more (following) paragraphs with less than 20 words each should
be converted into lists?

-- 
Regards,
Karl Ove Hufthammer

Received on Thursday, 16 March 2000 10:42:28 UTC