- From: Nick Kew <nick@webthing.com>
- Date: Sat, 30 Dec 2000 20:51:07 +0000 (GMT)
- To: w3c-wai-er-ig@w3.org
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