Comments on AERT (longish)

I have recently been looking through AERT
(<URL:http://www.w3.org/WAI/ER/WD-AERT/>)
with a view to incorporating its recommendations into future
developments of the Site Valet tools.

I note that the document invites comment, and I have several.
To start with, a number of specific comments.  I shall try and hold
back on more general overview comments until and unless I find time
to review the background in the mailing list archive and working group
minutes in more detail.


----------------------
1.1.1 [priority 1] Check IMG elements for valid "alt" attribute

ALT is of course enforced by DTD.  But I disagree profoundly with
several of the guidelines (is everyone familiar with Alan Flavell's
excellent essay on ALT texts)?

1. alt="" may often be correct: for example in a purely decorative
   image, or one that is immediately followed by a descriptive
   title in the document text.
2. Ending with "bytes" may be reasonable.  Example: a form inviting
   the user to enter geographical coordinates, and offering the
   option of clicking on a map to do so, might use (in context)
   alt="[Map (12345 bytes)]".

----------------------
1.1.2 [priority 1] Verify that valid IMG element descriptions ("longdesc"
attribute or d-link) are provided where necessary.

The meaning of "where necessary" is totally unclear to me.

----------------------
1.1.10 [priority 1] Check SCRIPT elements for valid equivalents where
necessary

This may be a little more complex than your text suggests:
1. Use of scripting events _might_ trigger a requirement for a
   NOSCRIPT element(?)
2. A single NOSCRIPT element can reasonably complement an arbitrary
   number of SCRIPT elements in a page.

----------------------
1.2 - Provide redundant text links for each active region of a
server-side image map

This doesn't make sense.  Except by coincidence, there is no such thing
as an "active region" of a server-side image map.  In cases where an
imagemap is divided into regions, it is best handled on the client
side, as discussed elsewhere in this document.

----------------------
3.2.1 [priority 2] Check document for public text identifier

I disagree about the list of public text identifiers.  There are
valid reasons for using a custom DTD, and an author capable of doing
so will presumably also be aware of the implications.  SYSTEM
DTDs should be allowed, provided they are referenced in such a manner
that they are available to user agents.

----------------------
3.3 - Use style sheets to control layout and presentation

Isn't this simply a statement of Strict vs Transitional?

----------------------
3.4.1 [priority 2] Check document for relative units of measure

Pedantic point: good relative units include "bigger" and "smaller".

SUGGESTED COROLLARY

Check for extended passages of text in anything other than default
presentation.  Particularly whole documents in smallprint.

----------------------
3.5.1 [priority 2] Check document for header nesting

Note: The ISO/IEC DTD enforces this strictly.

----------------------
3.5.2 [priority 2] Check document for missing header markup

Under evaluation, note that a very common error is the use of a large
<FONT> to present a header.

----------------------
3.7.3 Verify that BLOCKQUOTE is not used for formatting

1. I have adopted the approach of making CITE a mandatory attribute:
   it impresses on an author the purpose of the BLOCKQUOTE element.
2. I don't think disallowing nested blockquotes is really practical.
   For an example, consider the deep levels of nested quotes
   seen occasionally in email and routinely in Usenet news.

-----------------------
4.1.1 Verify changes in the natural language of document

I don't understand.  Surely this is a rather deep AI problem, unless we
expect a simplistic and probably counterproductive dictionary lookup?

-----------------------
4.2.1

"Potential Acronym or Abbreviation"
   Shouldn't dictionary lookup be allowed - or indeed encouraged - here?

"Do no worry about words followed by a potential abbreviation or acronym
in parentheses."
   <p>.... bla bla Worldwide Web Consortium (W3C) bla bla ...</p>
   <p> ... here is another reference to the W3C, along with a reference
   to the WAI.  The former has been properly introduced in this
   document, whereas the latter has not.</p> 

------------------------
CANDIDATE 4.4

Should we consider use of the LANG (and HREFLANG) attribute in links,
so that user agents can cross-check against user preferences before
following a link?

--------------------------
5.1.2 Check data table for row and column headers

Repair tools should consider introducing explicit THEAD/TBODY/TFOOT
if the author has not done so.

--------------------------
5.5.1 Check TABLE elements for valid "summary" attribute

1. This is trivially enforced by DTD.
2. I disagree with disallowing a null summary.  In the first place,
   a table for layout may well not merit a summary.  In the second
   place, a CAPTION element may duplicate the purpose of a summary.

----------------------------
5.5.2 Check TABLE elements for valid CAPTION element

See above.

----------------------------
5.6.1 [priority 3] Check table for header abbreviations

"How determine if an abbreviation is pronounceable? ASCII characters
only?"

For non-English documents this is nonsense.

----------------------------
6.2.1 [priority 1] Check the source of FRAME and IFRAME elements for valid
markup files

The suffix of a SRC attribute (as for, for example, an IMG) is irrelevant!
If you wish to constrain the contents of FRAME element, then make the
TYPE attribute mandatory, and/or use a spider to check the actual content.

----------------------------
6.2.2 [priority 1] Verify that equivalents of dynamic content are updated
and available as often as the dynamic content.

Surely you don't expect to determine this by analysing markup?  HTTP
header information is useful here: my own tools highlight interesting
values of headers including Last-Modified and Vary.

----------------------------
6.4.1 [priority 2] Check for device independent event handlers

Two points:
1. Provided 6.3.1 is satisfied, this requirement should be redundant.
2. Isn't this more properly an issue for the user agent?  Aren't events
   inherently device-independent, provided a device supports them?

----------------------------
6.5.1 [priority 2] Check that a NOFRAMES element exists within each
FRAMESET.

This is trivial to enforce with a DTD.  The W3C DTDs seem to me misguided.
See <URL:http://www.htmlhelp.org/design/dtd/> for my analysis. 

----------------------------
7. Ensure user control of time-sensitive content changes

Surely the issues discussed in this section should apply to user agents
more than to authors or authoring tools?  I use a proxy (wwwoffle) to
enforce those guidelines that bother me in my own browsing.

----------------------------
7.1.1 [priority 1] Verify that the page does not cause flicker.

I don't understand the suggested repair.  Surely flicker is far too
device-dependent to be assessed by displaying it on a single device?

----------------------------
7.3.3 CANDIDATE (and pet hate)

Banish animated GIFs!

----------------------------
7.4.1 [priority 2] Remove auto-refresh attributes from META elements

This appears to be calling for the banishment of a legitimate technique.
Example: if the server is undertaking a long job on behalf of the user,
then a META REFRESH to redisplay the job log every 60 seconds, alongside
a brief explanation and a direct link, seems totally reasonable
(I've done it myself in the past :-)

A reasonable requirement is that wherever meta refresh is used, an
equivalent link be provided in the document body.

----------------------------
7.5.1 [priority 2] Check auto-redirect attributes on META elements

See above.

----------------------------
9.3.1 [priority 2] Check scripts for logical event handlers

Pardon?

*  "onMouseDown" add or replace with "onKeyDown"
... etc

Just a minute!

There is no onKeyDown attribute in any W3C DTD for HTML or XHTML, so
this appears to be calling for invalid markup.  In any case, it should
be up to a non-mouse-based user agent to map this event to its own
capabilities, or to rely on Guideline 6.3.1.

-----------------------------
9.4.1 [priority 3] Check for "tabindex" attribute

This can easily be done by DTD.  But surely there must be many - maybe
most - cases where the order in which elements are presented is also
the most logical tabbing order.

-----------------------------
10.1.1 [priority 2] Check A and AREA elements for valid
"target" attributes

"Requirements: Should not have "target" attributes of "_blank" or "_new"."

Should perhaps be strengthened to check target is an existing frame.
And on the open issues, we should not disallow a valid technique (opening
multiple windows), so informing the user within the document text
should suffice.

-----------------------------
10.1.2 [priority 2] Verify that scripts do not spawn new windows.

Open issues: yes, any APPLET or SCRIPT can spawn a new window (and
so could an OBJECT).  Once again, they may have good reasons for it,
so a warning to the reader should suffice.

-----------------------------
10.2.1 [priority 2] Verify that LABEL elements are properly positioned

Possibly some mention of TABLE to associate labels with form elements?

-----------------------------
10.4 Until user agents handle empty controls correctly,

(what user agents have problems with empty controls?)

-- 
Nick Kew

Received on Saturday, 30 December 2000 15:52:55 UTC