Raw minutes from 15 February 2001 UA Guidelines teleconf

15 February 2001 UA Guidelines Teleconference

Agenda announcement:
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0223.html
Minutes of previous meeting 8 February 2001:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0200.html

Next meeting: 22 February 

Present: 
   Jon Gunderson, Ian Jacobs (scribe), Harvey Bingham, David Poehlman,
   Mickey Quenzer, Gregory Rosmaita, Tim Lacy
   
Absent: 
   Charles McCathieNevile, Kitch Barnicle, Rich Schwerdtfeger

Regrets:
   Denis Anson, Eric Hansen, Jim Allan
   
-------------
Announcements
-------------

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

JG: Possible attendees: Denis, Aaron Leventhal (Netscape)

MQ: I will attend. The forms were confusing, however.

----------
Discussion
----------

1.Coordination of joint meetings with DOM and CSS

JG: We'll meet with DOM WG at 12 on Friday 2 March. 

IJ: Please send DOM issues on this thread:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0213.html

Action IJ: Send an email about CSS issues to take to the CSS
WG. Confirm that IJ will attend CSS meeting earlier in the week to
discuss WAI issues.


2.Definition Issues:
     1.Issue 359: Definition: text content (incompatible with WCAG?)
     2.Issue 358: Definition: Equivalent
     3.Issue 322: The definition of the word element
     4.Issue 321: Equivalency relationships and the wording of 
                  checkpoint 2.3
     5.Issue 394: Checkpoint 2.1: Vague about what cannot be provided 
                  through a source view

/* IJ summarizes EH, AG discussions on Guideline. Proposal
   not yet available to Working Group. */

HB: One concern: Is it true that the user will always have the same
set of user agents? Do some get in the way of others? E.g., if video
were on, then the user might not hear the captions for video.

DP: My experience with captions: not readable with screen readers.

MQ: Should captions be required to be in separate viewports?

3.Issue 443: Checkpoint 1.4: Device indepdent access to pointer (mouse) 
specific events.
  Source:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#443

JG: I'm not sure that the requirement to convert author-specified
device-specific handlers was clear to reviewers. That may have
affected reviewer comments about the document.

IJ: Checkpoint 1.1 is very simple, but there may be some cases where
author-specified behaviors shouldn't be covered:

 a) Event bubbling?
 b) Pixel-specific behavior (e.g., server-side image maps)?

IJ: E.g., when you move focus to a link with a mouseover event handler
specificed, simulate the mouseover. {In other words, "onfocus"
triggers "onmouseover"}

DP: I recommend treating this like an HTML selection: you are informed
that you are in a selection element, and down arrow sends you to first
option.

TL: In current environment, element with a mouseover handler is just
identified to MSAA as a link. So, to get the combo box behavior, the
author would have to tell everyone it's a combo box. 

GR: To avoid disorientation that DP alluded to, the UA should provide
the user with the option to pop up the menu or not.

IJ: But the UA doesn't know it's a menu. I think that we're talking
about a binary mode that, when on, converts device-independent and
keyboard-specific events into mouse-specific events.

TL: A few comments:

 a) Yes, you are correct, there are JAWS users who have no idea that
 links are available because JAWS doesn't tell them.

 b) Handling event bubbling is very difficult.

 c) I think that this issue might be better addressed at the platform
 level than at the UA level. I think you should be able to tell the
 system (system-wide) that you are not going to use a mouse. And in
 that case, key events should be mapped to mouse events. I think that
 this is a valid point.

IJ: Does focus move to a link when I use the mouse to activate it?

TL: When you move the mouse around, you don't change focus until you
click. IE walks up DOM tree up to a node that can take focus.

GR: What about zap-mouse-to-focus?

DP: What about a model where:
  a) These mouse-specific events are identified.
  b) The user can make a choice about what to do.

/* IJ Notes that this discussion falls nicely into the 
"staged access" model presented earlier */

DP: For a popup menu, I want the ability to navigate into it,
or skip over it.

IJ: My question then is: is repair useful if the user agent
doesn't tell the user it's a popup menu (since the user agent
doesn't know; this is a script after all).

IJ: The author could have done a number of things correctly:
 a) Alternative page (with all links available)
 b) Device-independent handlers only (e.g., "onactivate")
 c) Redundant handlers (onfocus + onmouseover)

IJ: So, the question is how much the UA can do (should do) despite
authoring limitations. I think that the UA could provide some help,
but the repair will not guarantee access in some cases (e.g., where
pixel-specific interaction expected).

TL: I think the problem is wider than HTML and Web pages. I think
a zap-mouse-to-focus utility would be a good thing. I'll ask
around here.

Action TL: Report to WG on discussions at Microsoft about keyboard
emulation.

JG: For us to move ahead, I think we need more concrete proposals
about what we are going to require. And what are techniques for
implementing these. I think that we raise this issue to a checkpoint
level requirement to highlight it.

The WG documents some possible repair requirements;

 1) Navigate to active elements, including those with
    explicit event handlers.
    JG: I think we need to make clearer that this includes.

 2) We should not require repair of author functionality that
    depends on pixel information.

 3) We should require repair of author functionality that
    is mouse-driven, but does not depend on information conveyed   
    by a specific pixel. (e.g., repair by throwing onmouseover
    event when onfocus occurs, onmousedown when onkeypress, etc.)

 4) No repair in the case of event bubbling (explicit event
    handlers only).

 5) Repair behavior needs to be configurable.

 6) You have to know that these behaviors are available.

JG: What about different mouse buttons? 
    What about on drag events? 
    We seem to be most interested in:
     - Translating mousein/out to focus/blur
     - Clicks to keyboard emulation

Action IJ: Write a proposal trying to carve out what repair
requirements we might include in the guidelines.
 
-------------------
Action Item Summary
-------------------

----------------------
Completed Action Items
----------------------

3.IJ: Send email to list asking for input on scope of checkpoint 1.1 
including emulation of device specific behaviors
  Source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0193.html

Done: See action 10

5.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.
  Source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0083.html

Done.

10.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.
  Source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0200.html

Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0203.html

9.JG: Ping AOL to see if they can attend
  Source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0193.html

11.JG: Send an outline of what should be in a executive summary.
  Source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0200.html

Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0220.html

13.EH: Send thoughts on what should be in a executive summary.
  Source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0200.html

Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0221.html

14.RS: Find out what HPR's intentions are re: repair of device-specific 
      event handlers.
  Source: 
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0200.html
  Done:
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0226.html

----------------------
Dropped Action items
----------------------

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

-----------------
Open Action Items
-----------------

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

 2.IJ: Coordinate usability testing of the guidelines (JRG volunteers to 
 be one of the testers).
   Source: 
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137.html

 4.IJ: Write an executive summary appendix.
   Source: 
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0200.html

 6.JG: Implementation information for guideline 2

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

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

12.GL: Ask someone from Microsoft whether they will evaluate the 
guidelines with a product.
   Deadline: 2/1/2001
   Source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137.html

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

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

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Thursday, 15 February 2001 16:00:45 UTC