W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Raw minutes from 8 February 2001 UA teleconference.

From: Ian Jacobs <ij@w3.org>
Date: Thu, 08 Feb 2001 15:44:39 -0500
Message-ID: <3A830537.8F2E0A77@w3.org>
To: w3c-wai-ua@w3.org
8 February 2001 UA Guidelines Teleconference

Agenda announcement:

Minutes of previous meeting 1 February 2001:

Next meeting: 15 February 

   Jon Gunderson, Ian Jacobs (scribe), Harvey Bingham, David Poehlman,
   Eric Hansen, Mickey Quenzer, Jim Allan, Tim Lacy,  Rich Schwerdtfeger
   Charles McCathieNevile, Denis Anson, Kitch Barnicle

   Gregory Rosmaita

1.Register for User Agent face-to-face meeting in Boston on 1-2
  March 2001

  Registered: JG, IJ, GR
  Will register: HB
    HB: I may try to go to some other meetings earlier in the week.
  Unsure: MQ, EH
  Phone: JA, DP


1.Coordination of joint meetings with DOM and CSS


1. Issue 449: Executive summary.

 Action JG: Send an outline of what should be in a summary.
 Action EH: Send thoughts on what should be in a summary.
 Action IJ: Write an executive summary appendix.

2.Issues 358, 359, 322, 321, 394 postponed.
   These should be resolved after EH, AG, and IJ finish
   action item regarding checkpoint 2.3 and some definitions.

3.Issue 443: Checkpoint 1.4: Device indepdent access to pointer (mouse) 
	     specific events.
  Status: The document currently requires emulation of mouse-specific
  controls by virtue of our requirement that the user must be able to do
  everything through the mouse.
  a) Do we want to require the UA to repair device-specific bindings 
     specified by the author?
  b) Do we have evidence that the ability to simulate mouse events 
     through the keyboard benefits the user?

 TL: Scripting languages already provide for keyboard initiation
 of mouse-specific events. I think pretty strongly that this is
 an authoring issue.

 TL: Another way to fix this - bind some keyboard sequence to
 send a mouse event. It sounds easy on the surface, but it becomes
 complicated: where to you send the event? We don't think this repair
 should be done by the browser.

 MQ: My end-user reaction is that the problem won't get solved this

 TL: But I don't think you should apply a complex solution to
 a problem that has a simple solution on the author side.

 MQ: Do Web page checkers identify these problems?

 JG: I don't think they do much.

 IJ: Note that this relates to including explicit event
 handlers in the list of active elements. If we're not requiring
 UAs to allow users to activate with the keyboard mouse-specific
 events, then should the mouse-specific events be in the list
 of active elements?

 JG: Good point.

  - Either the UA does transformations of device-dependent
    to device-independent and these are included in active
    element list.
  - Or exclude device-dependent handlers from list of 
    active elements.
  - The UA is not required to repair author supplied 
    interaction that is device dependent.

 JG: Transforming mouse-to-keyboard could be a lower priority

  - Exclude device-dependent interaction that is specified by the
    author from the requirements of checkpoints 1.1, 1.2, 7.3, 7.4
  - Include a lower priority requirement for repairing author
    specified device-dependent interaction.

 JG: Since we don't have any implementation experience, we don't
 know whether this will actually help users. We don't know whether
 requiring repair will help accessibility; it may be more disorienting
 than helpful.

 /* IJ summarizes interdependences among WAI WGs and responsibilities
    of each party. The question here is whether we want to ask
    developers to repair device-specific handlers */

 DP: I wouldn't ask UAs to do spell-checking on the fly either.

 EH: I think I would support reducing the repair requirements here.

 /* EH leaves */

 JG: Frequent use of roll-overs is to dynamically changes images;
 basically a visual stylistic effect (so not critical for all users).

 DP: My understanding is that if you use mouse keys, you have similar
 issues - you don't slide over, you move to (it's more like tabbing
 more than rolling over).

 /* Rich arrives */
 RS: I think that you need to be able to navigate to elements with
 event handlers associated. 

 IJ: I have fears about removing this repair; we might have
     to go back to last call since this is eliminating a piece
     of an accessibility requirement (even through repair).

 JG: Has HPR tried repair techniques for this?

 RS: I don't know, but I don't think that you can activate
     mouse-specific events through the keyboard.

 /* The WG reviews the MS home page, which uses pull-down menus. MS
    home page provides pull-down menus, but if not supported, makes
    available the same links one page away. */

 MQ: I am willing to agree that this is an authoring problem. I'm not
 aware of implementations that simulate the mouse events.

 JA: Some of the MS links are available, but not all of them. So the
 author has done an inconsistent job at ensuring that all links
 are available.

 RS: The HPR people haven't implemented repair yet. I don't know
 whether IE provides a means to execute the javascript.

 DP: I may be wrong, but I think that JFW does with IE is that
 it takes every available link and makes it available - all links
 are made available (though not necessarily in the same order).

 TL: The way the home page works - all of the links are in the
 DOM; their display state changes. 

 /* Tim leaves */

 RS: Today, screen readers don't do the repair because they
 need a tie between the dom and what's rendered. Plus, IE
 doesn't let you execute scripts that are attached to an element.
 But today, you don't have the graphical rendering and the DOM
 tied together.

 JG: We already don't require control in the case of event
 bubbling. I'm not sure that a further limitation to
 device-independent handling is much more significant.

 Action JG: Ask WAI PF/WAI ER/WAI CG about their experience
            with repair of device-specific event handlers
            and indicate that we are leaning towards lowering
            the priority of repair here.
 Action RS: Find out what HPR's intentions are re: repair
            of device-specific event handlers.


Completed Actions

 9.JG: Request bridge from Judy for 3-4 people


13.MQ: Send more details about control of speech parameters for the 
techniques document based on OpenBook. (deadline open)

Open Actions

 1.IJ, EH, AG: Propose new definitions forterms in question 
(equivalence, text element, etc.)

 2.IJ: Coordinate usability testing of the guidelines (JRG volunteers to 
be one of the testers).

 3.IJ: Send email to list asking for input on scope of checkpoint 1.1 
       including emulation of device specific behaviors

 4.JG: Talk to Al Gilman at the next WAI CG meeting about a joint 
meeting with UA, PF, and Voice WG (or participants) to discuss 
accessibility issues.

 5.JG: Implementation information for guideline 2

 6.JG: Propose text for the techniques document about synthesized speech 
implementation issues. Notably UA and AT wanting to use the same 
synthesizer engine.

 7.JG: Create issue list for things that need to be addressed in the 
next version of the document

 8.JG: Ping AOL to see if they can attend

10.GL: Ask someone from Microsoft whether they will evaluate the 
guidelines with a product.
   Deadline: 2/1/2001

11.GR: Review checkpoints in Guideline 10 for implementation information

12.JA: Review checkpoints in Guideline 4 for implementation information

14.KB: Submit technique on providing information on current item and 
number of items in search

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 8 February 2001 15:44:41 GMT

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