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

Raw minutes from 1 February 2001 UA Guidelines teleconf

From: Ian Jacobs <ij@w3.org>
Date: Thu, 01 Feb 2001 16:02:09 -0500
Message-ID: <3A79CED1.2B3843CD@w3.org>
To: w3c-wai-ua@w3.org
1 February 2001 UA Guidelines Teleconference

Agenda announcement:

Minutes of previous meeting 25 January:  

Next meeting: 8 February 

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

   Mickey Quenzer

1.All working group meeting coordination

 JG: Who would like to attend by phone: DP, JA
 JG: Who has registered: HB, IJ, JG, AG.
 AG: I don't a black and white plan.
 IJ: I think RS and GR will be there.
 EH: I hope to be there, unsure though. I would be able to
     attend by phone part of the time.
 TL: I keep asking for MS attendees, but no one has stepped up
     yet. I could attend part of meetings by phone.

 Action JG: Ping AOL to see if they can attend.
 Action JG: Request bridge from Judy for 3-4 people. [No guarantee]

Tim Lacy on Balloon Tips

 TL: I have a question about using "Balloon Tips" instead of
 dialogs. The problem is that they don't send focus events. If they
 did, would screen readers pick up that event? The problem is that
 there's no focusable thing inside a balloon tips window.
 JG: Can't MSAA send a change event?

 TL: MSAA has the text in the balloon tips, but that class of window
 can't send a focus event. MSAA would have to proxy it for them.
 I have suggested not doing balloon tips.

 DP: Tool tips are available to screen readers that know to look for
 them. I think MSAA plays a role in this.

 AG: People who can help with this: Rich Schwerdtfeger and others
 on the side of catching the events. I suggest writing this problem
 to the list. The DOM people will probably have a proper event for
 this. We need to get this into our heap of issues for accessible
 scripts. The UA needs to throw an event that can be caught by
 ATs. The problem is for tools outside the Web sphere.

 /* RS joins here */

 TL: Since a balloon tip has nothing focusable, what's the best
 way to alert the AT? MSAA may already provide partial support.

 AG: This is an exception case...Look in vhdl for

 TL: The Balloon is created by an event, and that's where you should
 alert the AT. 

 AG: And that's where you classify them: so that the AT can pay
 attention to only some of them. Source should grade events,
 AT should filter them.

/* AG leaves, and asks for clarifications to Al's proposal by email */

2.Issue 455: Guideline 4: Change to "Ensure user control of

  JA: "Presentation" is fine.
  IJ: "Rendering and behavior"?
  JA: G4 prose is mostly about presentations.
  IJ: G4 is mostly about controlling behavior/rendering that can be
      detrimental. G4 is about content rendering and viewport
 Resolved: Change G4 to "Rendering and viewport behavoir"

3.Issue 456: Editorial: Need to clarify in section 3.2 that we do not 
  mean system APIs

  1) The old section 3.2 did not require this.
  2) The revised document no longer suggests that this is required.
  3) Checkpoint 5.6 (26 Jan 2001) requires standard APIs.e
  4) The WG does not think that if an standard API does not exist,
     that the UA has to implement a proprietary API.
  5) If a standard device API doesn't exist, it's probably not an
     environment we are trying to address with this environment.

4.Issue 457: Checkpoint 5.4: Ambiguity about what exactly required: 
  standard APIs only?

  "Checkpoint 5.4: Provide programmatic read and write access to user
  agent user interface controls using standard APIs (e.g.,
  platform-independent APIs such as the W3C DOM; standard APIs defined
  for a specific operating system; and conventions for programming
  languages, plug-ins, virtual machine environments, etc.)"

  IJ: Question: If there is no standard API, must you still provide
  access to UI controls?

  RS: I don't think so; the platform is "inaccessible".

  DP: I read it differently: providing access came first, then
  using standard APIs came second.

  IJ: Must you still provide access to custom controls.
  JG, TL: Yes.

   a) Provide programmatic read and write access to user
      agent user interface controls.
   b) Where a standard API exists, the UA must use it.
   c) Add clarification that access required even where standard
      API not available. You should implement accessibility APIs
      in your controls to provide access. This works for Java and

  IJ: Can custom controls be subclasses of standard controls?
  TL: Yes.
  JG: There are some cases (e.g., in MSAA) to create custom controls
      using accessibility APIs.
  RS: In the java case, you can provide a list of action
      description pairs to an element.
  TL: Here's an example: you can put an ActiveX control in a Web
      site. It's easy to write one that is a black hole to ATs.
      If you write one that uses MSAA, you've created a custom
      control, but you've implemented the standard accessibility
      API for it.
  DP: I'd hate to exclude potential future technologies from being
      able to claim conformance. If a UA can provide an accessible
      solution, they shouldn't be excluded from conformance.

  Straw poll:
    Allow conformance without using a std API: IJ, DP, EH, RS
    Don't allow conformance without using a std API: TL, JG
    Abstain: HB, JA

   a) Drop "using STD APIs" from 5.4
   b) Add cross-reference to 5.6, since it covers the standard
      API requirements.
   c) Checkpoint 5.4 requires read-write access in all cases,
      even when no std APIs available.

5.Issue 458: Do link highlighting requirements apply to all zones of an 
  image map? 
  What is required granularity?

  IJ: The issue is, e.g., an image map.
  DP: Is this visual highlighting only? If I activate an image map,
      using MSAA and IE+Jaws, I get links from inside the image map.
  IJ: I am happy to live with the granularity of "whole image map"
  since I assume that the hot spots are conveyed through the image.
  RS: The API should give you access to each link in the map,
      independent of what's in the image.
  JA: Form controls are distinctive; that highlights them.  
  JA: I think highlighting the image map as a whole is sufficient.

  /* RS and TL leave */

  Straw poll:
   Image map as a whole suffices: JA, DP, HB
   Individual hot spots required: CMN (by email)

   a) Add a note to 8.3 that highlighting an image map as a whole
      satisfies the checkpoint for image maps. UA may highlight
      all of the hot spots of a client-side map.
   b) There is some assumption that the author will make the image
      communicate different zones. We choose not to add a repair
      requirement for the case of bad images.

6.Issue 443: Checkpoint 1.4: Device independent access to pointer
  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.

  IJ: Note that 1.1. states: 
      "Ensure that the user can operate the user agent fully through
       keyboard alone..."

  IJ: This implies that the user agent must repair device-specific
      behavior specified by the author (e.g., the mouse).
      This is related to issue 370 raised by Phill Jenkins

IJ:Do we want to require the UA to repair device-specific bindings
specified by the author?  Do we have evidence that the ability to
simulate mouse events through the keyboard benefits the user?

IJ: I could see going two ways here:
  a) Bad authoring requires repair by UA and we don't require 1.1
  b) No exceptions to 1.1 (repaire required for mouse-specific events).

DP: I could see taking device-specific events for 1.1.

Straw poll:

 a) We must include in 1.1 coverage of 
 author-specified device-specific behavior, 
 and call that out as bad authoring: JA, HB

 b) It is ok to exclude from 1.1 author-specified device-specific
    behavior, and call that out as bad authoring: DP, EH, JG

 c) Abstain: IJ

 JG: My main concern is that we don't have implementation
 experience. We know they can't do some things, but we don't 
 have evidence that they would be able to these things.

 IJ: We agree that this is a repair function. Repair of either
 bad authoring or bad specs.

 JA: Often this is done through JavaScript.


  a) If we leave as is (no exclusion), add a note that this checkpoint
  also includes repair of device-specific behavior specified by the

 JG: Leave open to get developer input.

 Action IJ: Send email to list asking for input on this.
7.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

IJ: Update: we have moved from definitions to scope of 2.3.
AG: We are close to being closed.

Completed Action Items

4.JG: Send screen shots of directional techniques


Open Action Items

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

Status: Progress!

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

3.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

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

8.JG: Request input on the resolution of issue 454

9.GL: Ask someone from Microsoft whether they will evaluate the 
guidelines with a product.
  Deadline: one week.

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

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

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

13.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, 1 February 2001 16:02:12 UTC

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