Re: Comments on AERT (longish)

At 08:51 PM 2000-12-30 +0000, Nick Kew wrote:
>
>I have recently been looking through AERT
>(<URL:<http://www.w3.org/WAI/ER/WD-AERT/>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.
>

AG::

[more orientation to what gets done where among the WAI groups.]

[general comment: the techniques in the document are a mix of automatic,
automated/interactive, and purely manual techniques.  Your comments sometimes
err by assuming that only fully automatic checks are under discussion.]


This is where the static text of the document doesn't always cope with the
dynamic status of the document.

[correct me if I'm wrong, Len]  The AERT has been "sold off" to the Authoring
Tools Working Group and they are merging the contents into their Techniques
document.  So currently it would appear that issues with the techniques
discussed in AERT should be raised in that group, because they are maintaining
the version that is currently open for edits.  The ER group is not making
further changes within the scope of what the AU group is working on.

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

AG:: Clarifying "where necessary" is a question for clarification of the WCAG
1.0 and should be directed to the Web Content Accessiblity Working Group
<w3c-wai-gl@w3.org>.

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

AG:: Good to follow up this thought in ATAG.

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

AG:: This is a WCAG comment, not an AERT comment.

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

AG::

Recommended next steps:

Conditions under which SYSTEM DTDs are fit to use should be considered for web
content techniques for WCAG 1.0.

Follow up to see how to reflect same reasoning in WCAG 2.0.

Corresponding mods to evaluation and repair methods inserted in authoring
techniques after consensus reached in content guidelines group.

[second pass]

This is a deeper issue than I thought.  The WCAG 1.0 simply assumed that the
DTDs in the W3C Recommendation were the way to go.  The idea of floating a WAI
DTD that is stricter than the W3C Recommendation is an interesting technique I
am not sure we understand the pros and cons of yet.  On first look, it sounds
like a GL issue (Web content guidelines, <http://www.w3.org/WAI/GL/>). 
Although it may ricochet around a bit if it goes anywhere. 

>----------------------
>3.3 - Use style sheets to control layout and presentation
>
>Isn't this simply a statement of Strict vs Transitional?
>

AG:: No, it's a running flamewar in GL and IG.  Is in GL scope (i.e. is a WCAG
comment).

>----------------------
>3.4.1 [priority 2] Check document for relative units of measure
>
>Pedantic point: good relative units include "bigger" and "smaller".
>

AG:: to authoring tool techniques.

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

AG:: to content guidelines 2.0

>----------------------
>3.5.1 [priority 2] Check document for header nesting
>
>Note: The ISO/IEC DTD enforces this strictly.
>

AG:: Is that true?  I thought it took a clause that was above and beyond
_validation to DTD_ to enforce this.

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

AG:: to authoring tools techniques

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

AG:: to content guidelines 2.0

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

AG:: Have to read the language of the prior applicability clause more
strictly.  All this says is that if you are nesting blockquotes, that there
should be quotation marks in the text.

But the acceptability of nested blockquotes, and how they should be checked
for, is now a matter for GL:AU coordination and out of here.

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

AG:: The recommended technique is clearly manual.  All the tool does is warn
the author.

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

AG:: This is an under-developed area where I just recommended that GL ask for
ER help.

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

AG:: This is a content technique.  To content guidelines group.

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

AG:: To authoring tools.

>--------------------------
>5.5.1 Check TABLE elements for valid "summary" attribute
>
>1. This is trivially enforced by DTD.

AG:: except that an absent SUMMARY is functionally equivalent to an empty one
so your second point invalidates your first.

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

AG:: Yes.  See thread on GL.

SUMMARY expands on CAPTION or TITLE _as required_  
http://lists.w3.org/Archives/Public/w3c-wai-gl/2000OctDec/0858.html

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

AG:: earlier, I advocated dictionary matching as a technique to discover what
words needed pronunciation assistance.  The group did not include this.  This
is probably a slight misinterpretation of scope, colored by the fact that the
editor didn't want to have to promise a dictionary as part of an
implementation.

Scrubbing texts to be truly TTS-ready, and making sure that the SSML format
has
all the capabilities required to encode high grade TTS-ready texts, is an open
area [unfinished business IMHO] shared between ER and PF.

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

AG:: yes, actual source content, as stated in the language of the AERT
document.  Not the string value of the SRC attribute, the 'source' code i.e.
recovered contents of the referenced resource.

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

AG:: No, of course not.  Read the technique recommended.

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

AG:: Is a content guidelines comment.

>----------------------------
>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/>http://www.htmlhelp.org/design/dtd/>
for my analysis. 
>

AG:: Is a content guidelines comment.

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

AG:: it would be good to expand on how the proxy is used and how it repairs
the
dynamic characteristics of the dialog.  The correct allocation of requirements
among author and user tools may not have been reached in WCAG 1.0 because it
came out first an had no peer guidelines to rely on.

The User Agent guidelines do address this; but this does not mean there is
nothing that the author should take responsibility for.

Answer: TBD; Process: dialog between content and user agent guidelines groups.

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

AG:: No.  The phototropic epileptic sensitivity of the user is not that device
specific.  And what the content is being checked for is that the dynamic
behavior of the content does not force flicker when used with a "perfectly
flicker-free" device.

>
>----------------------------
>7.3.3 CANDIDATE (and pet hate)
>
>Banish animated GIFs!
>

AG:: to content guidelines.

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

AG:: This is more complicated than you think.  The user should be in control. 
If all user agents gave the user the level of control that the UAAG draft
calls
for, the author would not have to worry.  Until user agents provide this level
of control, it is a valid content issue.  For all time this is a content
issue,
not a "how to evaluate the content" issue.

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

AG:: To read clearly, hyphenate logical-event handlers.

These are handlers assigned to logical events.  Not logically constructed
handlers for events.

Talk to Charles for an orientation to device-independent events.  onMouseOver
and onMouseDown are device-specific, not device-independent events.

See DOM2 for a model of device-independent UI events.

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

AG:: is_a content issue.

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

AG:: Within document text does not suffice in speech environment.  See
discussion of warnings and configuration of control over window proliferation
in UA group.

"Is an existing frame" requires that the whole state trace graph of the
frameset be expanded at once for the purposes of checking.  That is to say,
the
frame may be created by another file into which the current file is inserted
within a frame.  Doing the whole thing is a more powerful check but you may
not
get the author tool vendors to agree to it.  Is an author tool issue, now.

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

AG:: same comment as above.  User Agent guideline is more effective than
content guideline on this point.  Good reason may still not be good enough,
keep user in control of the bottom line.  [see UAAG on this.]

>-----------------------------
>10.2.1 [priority 2] Verify that LABEL elements are properly positioned
>
>Possibly some mention of TABLE to associate labels with form elements?
>

AG:: Web content techniques.

>-----------------------------
>10.4 Until user agents handle empty controls correctly,
>
>(what user agents have problems with empty controls?)
>

AG:: Is a content guidelines issue (but we don't have a working plan for
maintaining this information...).

Thank you very much for these comments.

Al

>-- 
>Nick Kew
>

Received on Saturday, 30 December 2000 17:41:53 UTC