UAWG response to HTML WG review of UAAG 1.0

Steven,

On behalf of the UAWG, I would like to thank you for the HTML WG
review [1] of UAAG 1.0. Please review this email and let us know
whether you are satisfied with how the UAWG proposes to address
your issue. A response before 4 October would be appreciated; let
us know if you require extra time.

Thank you,

  - Ian

UAWG decisions were made at the 26 Sep 2002 teleconf:
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0173

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0149


===============================

The UAWG divided issues into substantive and editorial.

------------------
Substantive issues
------------------

You wrote:

   Guideline 2. Checkpoint 2.2

    "For the purposes of this checkpoint, a text format is any media
    object given an Internet media type of "text" (e.g., "text/
    plain", "text/html", or "text/*") as defined in RFC 2046
    [RFC2046], section 4.1."

   Therefore not XHTML, which has media type application/xhtml+xml. I
   would beef up this definition to at least include XML.

IJ response:

  The Sep 2001 CR draft of UAAG 1.0 included such language, but we
  deleted it. I believe now that we deleted it based on a
  misunderstanding of the reviewer's comment. I have therefore
  proposed to reinstate less ambiguous text that would also satisfy
  your request. There has been support for this proposal:

    http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0179

Thus, I believe that the revised draft will include language 
requiring a text view for content recognized as XML and SGML 
content, including application/xhtml+xml.

==

You wrote:

  Guideline 3. Checkpoint 3.3

    "Blinking text is text whose visual rendering alternates between
    visible and invisible, at any rate of change."

  And so not blinking between different colours?

UAWG reply to issue 549:
   http://www.w3.org/WAI/UA/issues/issues-linear-lc4#549

The UAWG agrees that rapidly changing text colors can be disorienting
to some users. However, the UAWG does not think that any substantive
change to the document is required because checkpoint 4.3 ensures 
that the user can override author-specified colors.

The UAWG suggests making your point in checkpoint 3.3, and adding a
cross reference from 3.3 to 4.3.

==

You wrote:

   Checkpoint 3.5

     "Authors (and Webmasters) should use the redirect mechanisms of
     HTTP instead of client-side redirects."

    I'm not sure what this means. is <meta http-equiv="..." /> a
    redirect mechanism of HTTP? What if I don't have access to HTTP
    redirects? Is that covered by the 'should'?

      "For example, if an HTML author has used a META element for
      automatic content retrieval, allow configuration to override
      the automatic behavior with manual confirmation."

    I don't understand this.

You elaborated in later email:
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JulSep/0160

   "So http-equiv is *intended* to affect how servers respond. In
   other words, according to HTML 4 <meta http-equiv ...> *is* "using
   the redirect mechanisms of HTTP"!

   So I think the wording needs to be tightened up to cover the real
   intention, and preferably without mention of the method used for
   the redirection (for instance HLink allows redirects without use
   of http-equiv).

   If I understand it, if a document is *immediately* redirected
   (because it has been moved or whatever) all is well; if a document
   is periodically refreshed, or redirected after a time delay, then
   the user needs to be consulted first.

   I think that this is a better approach also because HTTP redirects
   allow you to refresh periodically too, and the user needs a say
   then as well."

UAWG reply to issue 550
   http://www.w3.org/WAI/UA/issues/issues-linear-lc4#550

UAAG 1.0 used to have another checkpoint, with a lower priority,
requiring control over client-side redirects. There were two
checkpoints, one about refresh and one about redirects.

We deleted the redirect checkpoint for two reasons:

  a) We have no implementation experience.

  b) Even if disoriented temporarily by an intermediate,
     temporary page, a series of redirects ultimately
     converges on either stable content or refreshing
     content covered by this checkpoint.

The checkpoint requirement is independent of any particular
refresh/redirect mechanism. META/refresh is provided as
an example. It would be useful to include the HLink example
as well.

The UAWG believes that the normative wording of the checkpoint
expresses the real intention:

   "Allow configuration so that the user agent only retrieves content
   on explicit user request."

The UAWG proposes to change bullet two in the normative inclusions
as follows:

      "Authors (and Webmasters) should use the redirect mechanisms of
      HTTP instead of client-side redirects.

    to:

      "Authors (and Webmasters) should use server-side redirects
       instead of client-side redirects."

Of course, the author may not have control over the server,
but this is still recommended practice ("should") as it eliminates
potentially confusing intermediate pages.

The Techniques Document covers this issue in more detail.

As for this text:

  "For example, if an HTML author has used a META element for automatic
  content retrieval, allow configuration to override the automatic
  behavior with manual confirmation."

I suggest:

  "For example, if the user agent supports automatic content
   retrieval (e.g., via the HTML "meta" element), allow
   configurations such as "Never retrieve content automatically"
   and "Require confirmation before content retrieval."

==

You wrote:

   "For the purposes of satisfying this checkpoint, Cascading
   Style Sheets (CSS) are defined by either CSS Level 1 [CSS1] or
   CSS Level 2 [CSS2]."  Why not state "any level of CSS" so you
   don't have to republish when level 3 comes out?

UAWG reply:

   Open-ended and future references weaken the document, and the
   UAWG has chosen in the past to eliminate as many as
   possible. We do have some of these (e.g., "conform to operating
   environment conventions") when we cannot tighten the spec
   otherwise, but we have eliminated references to future
   Recommendations.

==

You wrote:

   Checkpoint 11.4: Would an emacs-like method of typing "escape"
   to go into single-key mode, and then letting you type a single
   single-key be allowable here? Or do you have to be able to
   toggle into and out of single-key mode explicitly? I couldn't
   tell.

You wrote in a later email:

   "Maybe the issue here is modifier keys, rather than number of
   key presses, but I leave it to you to describe."

UAWG reply to issue 551:
    http://www.w3.org/WAI/UA/issues/issues-linear-lc4#551

The UAWG agrees that the definition of "single-key mode" needs
clarification. The sufficient technique for this provision
currently reads:

   "The user agent may satisfy the requirements of provision two
   of this checkpoint with a "single-key mode" (i.e., a mode where
   the current bindings are replaced by a set of single-key
   bindings)."

This can be clarified to read:

   "The user agent may satisfy the requirements of provision two
   of this checkpoint with a "single-key mode". In a single-key
   mode, the set of required functionalities must be
   available through single-key bindings. The user must be able
   to remain in single-key mode until explicitly requesting
   to leave it."

------------------
Editorial issues
------------------

I will incorporate your editorial suggestions. We noted one as an
issue; it turns out to be just a bug in the spec.

You wrote:

   Guideline 1. Checkpoint 1.2

    "Allow the user to activate, through keyboard input alone, all
    event handlers that are explicitly associated with the element
    designated by the content focus."

   *all* is a bit overkill here. For instance XForms allows event
   handlers for events that are part of the processing model. These
   events are not caused by the user, and are not intended to be
   fired by the user, and Forms processing would be seriously
   disturbed if the user could activate handlers when these events
   had not been fired. I would specify here "all event handlers for
   events that could be caused by direct user interaction", or some
   such.

UAWG reply to issue 547:
   http://www.w3.org/WAI/UA/issues/issues-linear-lc4#547

   This is a bug in the spec. The checkpoint should read:

    "Allow the user to activate, through keyboard input alone, all
    input device event handlers that are explicitly associated with
    the element designated by the content focus."

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Monday, 30 September 2002 14:37:37 UTC