W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 1999

Minutes from 26 May 1999

From: Ian Jacobs <ij@w3.org>
Date: Wed, 26 May 1999 13:45:35 -0400
Message-ID: <374C333F.B6D06CF0@w3.org>
To: w3c-wai-ua@w3.org
WAI UAGL WG Teleconference
26 May 1999

Chair: Jon Gunderson
Scribe: Ian Jacobs

Present:

Harvey Bingham
Denis Anson
Mark Novak
Chris Weaver
Charles McCathieNevile

AGENDA: @@URL

ACTIONS:

- Action Chris: Write up Math techniques proposal and post to mailing 
                 list. Done. @@URL
       Action MR to review this.

- Action editors: Incorporate resolutions into next draft of document.
  In progress.

- IJ: Write DJW about requirements T&S/WAI.
  Wrote three times, still not reply.

- CMN: Write techniques for 7.2.2 and 7.2.6
  CMN deferred until publication of Note by Rich and Mark.
  Rich and Mark sent Note.

- JG: Techniques for 7.2.1.
  Not done.

- JG: Techniques for 7.2.2.
  Not done.

- JG: Contact Rob about 7.2.4/5/6
  Rob hasn't been participating and we have consensus
  on checkpoints in this section. 
  JG: I need to contact Rob about this. We want
  TECHNIQUES that point to vendor-developed (internal)
  guidelines. This for platform-specific conventions.
  Not done.

- JG: Contact Rich S. and Peter Korn for techniques.
  JG: I contacted Rich but not Peter. 
  Not done.

- JA: Check guidelines for information about tooltip control.
  Not done.

- MK: Propose navigation checkpoint to time-sensitive
  parts of a document.
  Done. @@URL

----

Agenda 1) Navigation to elements with associated scripts.

JG: In 31 March draft, there are  three checkpoints + turn on/off.

JG Summary of issues:
  a) Device independent triggering of events? (Event synthesis).
  b) Navigation to elements with explicit event handlers?

DA: Navigation to elements with event handlers shouldn't
    be priority 1.

JG: I don't think we should include elements with event handlers
    in set of active elements. Many events are "superfluous" or
    decorative. Complicated issues being dealt with by WAI PF
    Working Groups (e.g., event synthesis) for future specs.
    One important issue is to describe the purpose of the event:
    is it eye candy only or essential for access to page information?

DA: For Web pages as interfaces, page inaccessible if you can't
    activate in a device-independent manner.

DA: Would a "mouse-over" be generated when the user tabs to the
    element?

MN: We're running into trying to solve problems we don't understand
    well. Should we just push this to techniques?

DA: Until we can tell whether an event handler is important, we
    shouldn't limit access to it.

CMN: Anything with an event handler is an active element. The UA
    could also provide configurability about what should be
    included in active elements (e.g., P3 checkpoint). User could
    choose to include/exclude event handlers.

DA: Does "active" also mean "takes focus"?

CMN: That's an implementation issue. In IE, in order to specify event
     handlers, you need to use certain types of elements. This is an IE
     peculiarity. I think "active elements" must be able to take
     focus, but things that take focus don't limit the set of 
     active elements.

IJ: I like Charles' suggestion to allow configurability.

PROPOSED: Allow users to configure user agents
          to say what elements will be
          considered active elements. (P3)

/* Editors note: In this case, revise active element definition */

Mark: I like the idea, but I don't want to differ too much from
      current practice.

IJ: Might define active element with some user agent-dependent piece
(e.g., links, controls, maybe other elements).

CMN: My proposal does not really move away from current practice. I
think
it's a more accurate description of the principle.

IJ: Why not generalize to allowing the UA to allow the user
    to configure any elements that are available in sequential
    navigation....

Mark: My concern is defining active elements w.r.t. current practice.
      Otherwise, including them in the list
      of active elements seems ok.

CMN: I don't think we should limit to explicitly associated event
     handlers. If you allow configurabilty, you address bubbling, etc.
     You can give users access to all elements and synthesize the
     events. You *have* to give access, in short.
     I agree that in a lot of cases, you want to skip them.
     You'd probably have to adjust settings after viewing a portion
     of the document (to see how it works). The UI can be simple (it
     doesn't have to be technical). Configurability is an improvement
     on the first requirement: get to everything. Configuration
     can be as sophisticated as you want (reg exps!).

JG: I don't trust that people will be able to make configuration 
    decisions. 

/* CMN leaves */

HB: In HTML 4.0, almost all elements can have associated event
    handlers. 

CW: I think it's reasonable to have two checkpoints.

JG: Several browsers already have sequential access. We'd be asking
    them to do something different. 

Mark: The document is out of date, it's hard to remember what's
    in there. I'm torn: (a) yes to access to everything (b)
    pain to navigate through long lists (c) programmatic nightmare
    For (c), the list of event handlers may be generated dynamically.

DA: I think "active elements" must include event handlers (P1). But
    have another checkpoint to navigate elements with explicitly
    associated scripts (P2).

HB: Users don't know a priori which elements have associated
    scripts. Also, scripts may be associated, but not have
    an impact.

JG: Right, you don't know what the "purpose" of the script is.

JG: What about event synthesis?

IJ: Should this be part of another checkpoint? (the one in the
    guideline about device-independence).

JG: I think we need to say it straight to readers.

Mark: Jaws, for example, simulates mouse events. I don't think
   it needs to be stated explicitly, but I have no problem with
   a separate checkpoint.

IJ: I would rather include in single checkpoint.

Chris: How much will access to event handlers help the 
    average user. We should mention something in the
    Techniques about appropriateness of information.

IJ: I don't think there's consensus about whether we
    need a separate checkpoint for navigation to
    elements with associated scripts.

AD: Too much information (e.g., by including event
    handler information) can be difficult for those
    with cognitive disabilities.

NEXT MEETING 2 June.

Regrets: Ian
Received on Wednesday, 26 May 1999 14:34:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:48:57 GMT