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

Raw minutes from 27 October teleconf

From: Ian Jacobs <ij@w3.org>
Date: Wed, 27 Oct 1999 14:10:18 -0400
Message-ID: <3817400A.C624E358@w3.org>
To: w3c-wai-ua@w3.org
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Gregory Rosmaita 
Rich Schwerdtfeger
Dick Brown
Harvey Bingham
Jim Allan
Mickey Quenzer
Mark Novak
Marja Koivunen
Jim Thatcher
Charles McCathieNevile

Denis Anson
Kitch Barnicle
David Poehlman

Agenda [1]


1) Review action items

    1.IJ: Repropose Guideline 7 descriptive text to include more than
W3C technologies.
      Status: Done

    2.IJ: Update document based on resolutions at F2F meeting
      Status: Done

    3.IJ: Redesign techniques document based on discussions at F2F
       Status: Pending
       IJ: Expected document Friday or Monday.

    4.IJ: Propose on the list: Generalize 3.8 to apply to more than just 
          continuous tracks : all sources of alt content.
      Status: Done

    5.IJ: Add a checkpoint to turn on/off background sounds.
      Status: Done

    6.IJ: Propose how the conformance checklist will be delivered
      Status: Not done.

    7.IJ: Add RS proposal related to VM and plug-ins into to checkpoint
          using accessible interfaces. For review next week
      Status: Done

    8.IJ: Follow up with Judy on FTF coordination with IBM.
      Status: Pending

    9.JG: Decide if we're ready for last call by next Weds.
      Status: Postpone until 3 November meeting

   10.JG: Before next Weds, send list of people to contact for last
      Status: Done      

   11.JG: Include an annotation mechanism in current issues list
          for last call comments
      Status: Not done.

   12.JG: Talk to Wilson Craig offline about contacts for assistive 
       technology developers who may be interested in reviewing the
       during last call
      Status: Not done.

   13.JB: Follow up on hosting possibilities for December F2F meeting.
      Status: done

   14.HR: Find information about European contacts who may be interested
          reviewing the document during last call
      Status: Not done.
      Action JG: Contact HR.

   15.TL: Get feedback from MS IE Team on usability of 5 October
      Status: Not done.
      Action DB: Contact TL. 
      IJ: If he hasn't done it, wait for next draft.

   16.GR: Write a proposal to address issues about spawned windows.
      Status: Pending.

   17.GR: Repropose Checkpoiont 2.5 on user defined keyboard bindings so 
     that it's clear that there should be a cascade order whereby the
     user has ultimate control or can concede control to the tool.
      Status: Depends on outcome of issue 109.

   18.MN: Propose a new definition of active element, based on keyboard 
          navigation discussion at F2F meeting
      Status: Pending.

   19.MR: Working on SMIL techniques
      Status: Pending.

   20.CMN: Write a proposal to address this checkpoint 2.3 Provide 
information to the user about author-specified keyboard configurations.
      Status: Done. Subsumed by 109.

   21.RS: Look into 9/10 December for room availability for next F2F
      Status: done

2) Announcements 

  2.1) Looking for reviewers for Last call document. Jon has
       started to put together list. Please send names of people
       from various organizations.

       (Refer to message also from HB:

       RS: Contact: Linda Boyer at IBM (Via Voice)
                    phone 561-615-4633
       Action IJ: Contact RealNetworks.
       Action HB: Contact Steve Anderson (of Dragon Systems).

       Action MN: Contact someone at United Cerebral Palsy
       Action DB: Contact person in Windows media group.
       Action MQ: Find someone from WinAmp, SigTuna

  2.2) Decision to go to last call will be made at 3 November
       teleconf. Last call itself won't occur until a couple
       of days afterwards (to finish editing, compose letter
       to chairs@w3.org).
  2.3) Techniques document.

       IJ: In progress.
           - New structure
           - Incorporate content, including content from ftf.

       MQ: Heading levels are useful.
       IJ: We already use them. I'll keep in mind as I restructure

3) Issue #110: Proposed changes to Guidelines 1, 2, and 11 re: keyboard

   Proposed changes [2]  to G1, G2, and G11.
   [2]   http://www.w3.org/WAI/UA/1999/10/g1g2-proposal

   MQ: I liked proposed text from GR:

   IJ: Any strong objections?
   RS: I agree in principle but require more clarity.
   MK: I agree in principle but require more clarity.
   JT: I have some. Too general.
   JT: This is basically requiring keyboard input with the mouse.
   IJ: Not every API allows.
   MK: Why not require text input with the mouse?
       You can also use your eyes to designate information on the
   RS: Onscreen keyboards are custom applications (or may be
       included with the OS). 

   Resolved: Don't require UAs to provide native support for text
             input with a pointing device.

   RS: People want assistive techs to work with software in general,
       therefore people would only use the standard API.

   JT: I like this note: "Note: User agents are not
     required to reimplement low-level functionalities (e.g., 
     for character input or pointer motion) that are inherently bound
     to a particular API and most naturally implemented through
     that API." However, change "Note:" to "However,".

   RS: I think standard APIs should be part of 1.1.

   MK: Is 1.1. more about making the functionalities accessible
       or about standard APIs? It's not clear to me what "API" me.

   IJ: In one checkpoint, talk about all functionalites.
       In another, talk about use standard APIs.

   Resolved: Add Ian's clarification to 1.1 changing "Note:" to

   Action Ian: incorporate this in draft.


   JT: I think we need to say explicitly that 1.2 is special case of
   MQ: Make clear that no x/y coords necessary.

   Resolved: Add Note that this is a specialization of 1.1
   Action Ian: Clarify note after 1.2.

   1.3: Ok.
   Action: Add an example of standard output to 1.3.
   Refer to RS's email:

   1.4: OK.

   Resolved: Add Note that this is a specialization of 1.1


   JT: I don't understand it. I don't know why it's there.
   JG: Part of what this means to me is that if you write
       text, you should use text drawing routines so that
       ATs can intercept it.
   IJ: Sounds like use 1.3 for me. 
   RS: I read 1.3 as support for the offscreen model. Support
       standard output APIs so that screen readers can get
   GR: Propose: Putting technique about text drawing (from ftf)
       as example after 1.3.
   Need clarification that 1.5 does not mean: output all text as speech
   or output images as sound.

   DB: I don't see why we need 1.5.
   MK: If you only give visual feedback for UA messages, that's

   IJ: Previous version only spoke of messages from the UA.
       Technique: Use text.

   MN: The more I listen, the more I think it's important
       to talk about redundancy. It doesn't make sense for
       a self-voicing UA to not be able to read its own menu.
   GR, MK: I agree.

   IJ: If you support an API, you have to support it consistency.
       Beeps are different from speech synthesis.

   CMN: Following a link is a classic example of not wanting to
        move through two-dimensional space. Or selecting a menu


        1.6 Ensure that all messages to the user (e.g., 
            warnings, errors, etc.) are available through 
            standard output device APIs supported by the 
            operating system. [Priority 1] 

   [4] http://www.w3.org/WAI/UA/WAI-USERAGENT-19991005/

   1.3 is about system standards.
   1.5 is about redundancy of output.

   Action MN: Repropose wording for 1.5 described in [3].

On Guideline 11:

   IJ: Any strong objections?
   JT: I have some. Too general. Difficult to understand.
   MQ: I don't understand it either.
   CMN: Document how the tool works.

   Proposed: "Document the default input configuration"

   DB: Why is this necessary?
   JG: Original intent was to improve traditionally poor
       documentation of keyboard configuration.

   JT: I don't think you should document the default GUI.
   CMN: What does an icon that looks like a waffle mean?
   RS: I think that 11.1 is on the right track, but that
       GUI is considered an output mechanism.

   IJ: I left "keyboard" in to highlight.
   JA: Ian defined "input configuration".
   DB: I don't understand why 11.1 is there when
       there's a more general documentation checkpoint.
   IJ: This is a special case.
   DB: Proposed deleting 11.1, moving to Documentation Guideline.

   Resolved: "Document the default input configuration."
   Resolved: Put rationale in checkpoint Note (e.g., using
       quote from Nov 1998 draft). Also mention keyboard
   Resolved: Move 11.1 to Document Guideline. Note that this
             is a special case.

   11.2: Provide information to the user about the current
         input configuration.
   DB: Accesskey different from what the UA allows to change.
   IJ: I think that source unimportant. The user simply wants
       to know what the current config is.
   DB: If you put accesskey in as an author, it's up to the
       author to document it.
  CMN: I disagree.
   GR: In my last post, I pointed out that Accesskey is not
       the issue. It's an issue of user control.
   IJ: Why should I tell the UA how to use TABLE? It's part of the
  CMN: The UA determines how links are activity. Links are provided
       by the author. The UA implements the mechanism. In the same
       way, the UA implements accesskey. The UA implements the 
       control and decides how it's done. The author has no way of
       knowing what the UA will do, in fact. So the UA is the only
       agent that can know what to do. 
   DB: I think support is required, but not information about
       what accesskeys will work. 
  CMN: I would say that the opposite is true: doesn't matter whether
       there's support. But if there is support, the UA needs to tell
       the author.
   DB: It's the author's responsibility to say "I proved Alt-J".
  CMN: No, since in windows it will be "Alt-J", in Mac "Apple-J", etc.
       The author doesn't know how the support will take place.

   JG: Propose two separate checkpoints for current config (one for
       UA-supplied, one for Author/Other-supplied)?

   DB: Add one for author-supplied as a Priority 3?
   RS: I think a split is a great idea. Dropping priority
       for author-supplied info (notably since accesskey is broken).
       Also, there are so many issues about scripting that the PF
       WG should be focusing on that.

  Action DB: Propose split checkpoints about configuration.
  Action CMN: Send info about MS Word provides this information to
  Action CMN: Send techniques for how to provide author info.

  Resolved: 11.5, 11.6, 11.7, 11.8 ok.

Issue 108: Proposed checkpoint for table summary information 

HB: I think this should be a checkpoint.
JG: I think we should take out "selected table".
GR: I agree with Harvey. Think this is a UA responsibility. 

To be continued at next week's call.

/* Adjourned */
Received on Wednesday, 27 October 1999 14:10:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC