W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2002

Raw minutes of 26 Sep 2002 UAWG teleconf

From: Ian B. Jacobs <ij@w3.org>
Date: Thu, 26 Sep 2002 13:28:22 -0700
Message-ID: <3D936DE6.5090405@w3.org>
To: w3c-wai-ua@w3.org

UAWG teleconference, 26 Sep 2002

Agenda announcement:

Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe),
Harvey Bingham, Matt May, Tim Lacy, Rich Schwerdtfeger

Regrets: David Poehlman, Jim Allan, Eric Hansen

Previous meeting: 19 Sep 2002

Next meeting: 10 Oct, 2pm ET

Reference document 21 August 2002 Last Call draft


1. Announcements

  JG: The next UAWG FTF Meeting will take place during the first
  week of March 2003, during the all-Working Group Meeting in
  Boston (3-7 Mar 2003).

2. Open Last Call Issues

2.a Issue #545:
   6.5: Require DOM HTML to ensure that form values available
        through API

Proposed Resolution:
Refinements from Rich:
And from Jon:

/* Discussion about scope of "state" */

RS: Often, the API that would be used to do this would
be through an API that controls the user interface.

IJ: Yes, that's true, and that's a possible solution.
HTML DOM is another.

RS: Need to make the same kind of statement for current
state of UI controls (checkpoint 6.5).

IJ: You can kind of get everything 6.1.3 asks for through
the keyboard API (by following 1.1 an 9.3).

RS, JG: But that's not the best way to do this.


  * The UAWG agrees that the user must be able to make the
    same state changes (e.g., to form controls) programatically
    as can be done through the UI.

  * Adopt IJ proposal

  * Make same kind of change for checkpoint 6.5.

  * Use the terms "control state or value" and "content state
    or value".

    Example of content state: "checked" or "selected".
    Example of content value: value of a text area element
    Example of control state: button pressed

IJ: An implication is that we do not require write access
to the DOM at all. This is one way of doing this, but is
not required.

IJ: I'll also look at JG's text:

2.b Issue #547:
   Checkpoint 1.2: Limit events to what can be triggered
                   through user interface controls

Proposed Resolution:

Resolved: This is a bug that will be fixed to read "input
device event handler."


2.c Issue #548:

Checkpoint 2.2: Include the media type application/xhtml+xml to
provide access explicit access to the source of XML content


Proposed Resolution:
   Accept proposal from Steven to include application/xhtml+xml.

IJ: Do we have implementation experience for this?
JG: Yes, at least IE.
TL: Yes, IE shows the xml.

Resolved: Accept proposal to include application/xhtml+xml.

2.d Issue #549:
   Checkpoint 3.3: Clarify definition of blinking to include
                   alternating states of color

JG: Difficult to tell in markup the change rate of interpolated
colors. This to me is more of an animation.

IJ: See SVG:

IJ: I think you can detect the rate of change in markup.

JG: Could consider this covered by animations.

IJ: But it's overkill to turn off all animations.

JG: I hesitate to change the checkpoint at this point,
since we are not certain about the impact of changing
colors (rate of interpolation). I think we are covered
by other checkpoints (4.3).


  * No change since (1) we are uncertain of real effect
    on users and (2) checkpoint 4.3 ensures user control
    of text colors.

  * Add a Note to say that style control is covered by other
    checkpoints. In particular, 4.3 ensure that users have
    control over dynamically changing colors.

2.e Issue #550:
  Checkpoint 3.5: Clarification requested on HTTP headers and
                  META data for automatic refresh or redirect


Proposed Resolution:


  * Distinguish server-side from client-side.

  * In normative inclusion 2:
    Change "Authors (and Webmasters) should use the redirect
    mechanisms of HTTP instead of client-side redirects." to
    "Authors (and Webmasters) should use server-side
    mechanisms instead of client-side redirects."

  * We also reminded ourselves that this checkpoint does not
    require control of redirects, per the 13 Jun 2002 teleconf,
    in light of CR experience. More information is in the
    techniques document.

Issue #551: Checkpoint 11.4: Single key mode and single-key
access need fixing?



  * The scenario Steven describes uses Esc as a modifier. It's
    not a real single-key mode.

  * Clarify that single-key mode is expected to allow a number
    of single-key options, not just one.

#552: Checkpoint 2.10: "language and script"


  * No change to the checkpoint since we have no implementation

  * Add a Note per Richard's suggestion that it would be
    good to do this for language information.

#553: Add a requirement for per-script font-family configuration?

  * Resolved: No new requirement. Add comment in Techniques.

Editorial suggestions:

  IJ on Richard Ishida comments:

Action IJ: Update the document with the group's changes; have
a new draft by 3 October.

   Request to advance to Proposed Recommendation with
   modified document.

Open Action Items
JG: Write up user scenarios for why non-text-based highlighting 
     for users; notably which users.

See for additional questions:

JG: Contact Opera about participating in test suite work
JG: Contact Randy Marsden about UAWG test suite work.

Completed Action Items
IJ: Fix cross reference from 1.1 to 1.3 (should be to checkpoint 1.2)

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Thursday, 26 September 2002 16:32:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:32 UTC