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

Raw minutes from 20 October 1999

From: Ian Jacobs <ij@w3.org>
Date: Wed, 20 Oct 1999 13:37:57 -0400
Message-ID: <380DFDF5.CC4B6E5C@w3.org>
To: w3c-wai-ua@w3.org
User Agent Accessibility Guidelines WG Teleconference
20 October 1999

Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Gregory Rosmaita 
Harvey Bingham
Kitch Barnicle
Charles McCathieNevile
Marja Koivunen
Rich Schwerdtfeger


Mark Novak
Dick Brown
Wilson Craig
Denis Anson

Agenda [1]


1) Review of action items:

    1.IJ: Follow up with Lake on usability questions related 
          to her posting [2] to IG.

      Status: Done. I called her and we discussed a number of 
      features. She will send info to the WG.

[2] http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0023.html

    2.IJ: Repropose Guideline 7 descriptive text to include 
          more than just W3C technologies.

      Status: Not done.

    3.IJ: Update document based on resolutions at F2F meeting

      Status: Pending.

    4.IJ: Redesign techniques document based on discussions at F2F

      Status: Not done.
      IJ: I haven't had time to work on this yet. It will be
          essentially what we discussed at the FTF.

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

      Status: Not done.

    6.IJ: Add a checkpoint to turn on/off background sounds.

      Status: Not done.

    7.IJ: Propose how the conformance checklist will be delivered

      Status: Pending.

    8.JG: Announce F2F meeting being organized for December on 
          the UA page and list.

      Status: Done.

    9.JG: Contact MR about SMIL techniques

      Status: Done. MR (Madeleine Rothberg) will send.

   10.JG: Talk to Wilson Craig off-line about contacts for assistive 
technology developers who may be interested in reviewing the document 
during last call

      Status: Not done.

   11.JG: Ensure that December F2F meeting is discussed at next

      Status: Done.

   12.JB: Follow up on hosting possibilities for December F2F meeting.

      Status: Done.

   13.HR: Find information about European contacts who may be interested
reviewing the document during last call

      Status: ?

   14.TL: Get feedback from MS IE Team on usability of 5 October

      Status: ?

   15.GR: Write a proposal to address issues about spawned windows.

      Status: Pending.

   16.GR: Repropose Checkpoint 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: GR did thinking out loud on PF list. Took the pulse
      there. Should something be fixed in UA or elsewhere?

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

      Status: ?

   19.CMN: Write a proposal to address this checkpoint 2.3 Provide 
     information to the user about author-specified keyboard 
     configurations. P3

      Status: Pending.

   20.RS: Propose rewording of Checkpoint 1.1

      Status: Done.

   21.JG: Run pwWebSpeak through the guidelines
      Status: Done.

   22.JG: Contact Lakespur Roca related to posting for review of

      Status. Done.

   23.JG: Review RS comments on current working draft and update the
issue list

   Status. Done, indirectly at ftf.

   24.IJ: Contact Microsoft about participation at F2F meeting in

   Status. Done.

   25.IJ: Contact Marja about writing a proposal for what should be
          related to checkpoint 2.1 issues 

   Status. Done.

   26.IJ: Propose a checkpoint like the ones for form about table
          information (checkpoint 9.9 and 9.10) 

    Status: Done.

2) FTF meeting in December

   RS: 7/8 December better for IBM (Austin). Week of the 14th is 
       very bad (conf room booked, RS in classes). Don't know about
       room availability for 9/10.

   Who can attend: 9/10: GR, IJ, JG, RS

   Unsure: CMN (depends on AU), 
           KB  (question of permission).
           HB  (issue of access workshop at XML WS).
           MRK (may be in Findland).

   CMN: Process issues - meetings require 8 weeks from meeting
        notice. Exception case ok when WG has consensus about

   JG: If we don't go to last call next week, we may have to
       delay the meeting. If we don't go to last call until 
       after AC meeting, wouldn't meet to process last call
       until mid-January.

   CMN: Mid-january would be good for me.
    RS: I'll be at a conf first week of Nov. I need to know
        as soon as possible.

   Action RS: Look into 9/10 December for room availability.
   Action IJ: Follow up with Judy on FTF coordination with IBM.
   Action JG: Decide if we're ready for last call by next Weds.

3) TODO for last call:

  a) Document Chair's/WG's decision to go to last call.
     (Done at next week's teleconf).

  b) Identify dependencies and track
     their responses in a specific list.

     Action JG: Before next Weds, send list of people to
     contact for last call.

  c) Identify issues and track them in the issues list
     (annotate the existing issues list mechanism?). 
     Get sign-off from individuals who raised issues?

     Action JG: Include an annotation mechanism in current
     issues list mechanism.

  d) Charter up to date. Ok.
4) Issue #105: ACCESSKEY implementation issues

   GR: IE implements accesskey somewhat.
   JG: Does Opera implement accesskey? 
   GR: Not in v. 3.6. PWWebspeak latest version may.
   CMN: Amaya does not.

   GR: One reason I haven't proposed yet to UA is that I'm deciding
       whether this is part of G2 (keyboard) or G6 (UI) or G8
       Also, I don't want to lose Tim Lacy's point from face-to-face:
       user doesn't care where bindings come from (author or UA). Only
       wants to know:
        a) What's available
        b) How to invoke them
        c) What to expect from them.

  GR: Discussion in PFWG about handling accesskey. Should PF look
      into CSS3 user interface? I don't have much faith in 
      implementation as defined in CSS3. The onus is on the author
      to write platform-specific bindings. It's not the role of the
      UAGL to fix broken things. 

  JG: Author, through accesskey, is adding user interface. Concerned
      about author's intent. Also, with current accesskey
      specification, no way to notify author of intent.

  CMN: I don't agree. You can look at markup and say "This key
  provides access to this object." 

  IJ: You could ask users to provide "title" descriptions. 

  GR: What is needed (in terms of checkpoints):
   1) List of key bindings (default [P1] + current [P1])
   2) List changes from default.
   3) Cascade order from bindings 
       a) don't override or allow override of defaults
       b) alert user to author-supplied bindings
       c) remap conflicting mappings to unused bindings.
   4) Consistent behavior on activation. Does accesskey switch
      focus alone or do focus + activate? For screen reader users,
      I prefer focus alone; decide based on context. May want
      a cascade here: focus, focus + activate (with prompt
      for configuration).

   RS: I'm for cascading of bindings.

   KB: About remapping: what's involved in that from a developer's

  CMN: The user doesn't care where controls are designed. Only 
       cares about how to operate the UA.

       You can use CSS to document what's got an access key.

   IJ: How will GR's proposal differ from what's in current G2?
       From what I've heard it sounds like there aren't big
   KB: Recall that priority was an issue (due to WCAG).

   GR: What's different: Everyone agreed that 2.5 was insufficient:
       on/off insufficient since a cascade is required. May need
       several checkpoints, may need to put elsewhere.

   MK: Turn on/off is like a different mode. When you cascade, you
       may lose consistency of mapping.

   /* Digression into Guideline 2: whether or not to abstract to
      other devices than the keyboard */

  CMN: Separating author-supplied bindings is a mistake.

   IJ: I agree: 2.5 should be about user final control of 

   HB: When an author changes a binding that the user wants,
       this flies in the face of UA design.

  CMN: I think the priority of accesskeys in WCAG is orthogonal
       to letting the user know how the UA works.

   IJ: I think that most of GL2 is not about the keyboard (as MRK
       has suggested).

  CMN: I agree.

   RS: Consensus at ftf was to keep keyboard separate.

  IJ: I think it's an editorial issue to ensure that the emphasis
      on keyboard access is not lost. I guarantee that the keyboard
      emphasis will not be lost.

  MK: I think it's important to have "keyboard" in the checkpoints.
      It's not clear to me what it means in 2.1 that if you support
      the keyboard API, support the keyboard.

  IJ: The key word is "all".

  JG: I think we need to move this document forward and we may
      need to restrict ourselves to keyboard here to finish.

  IJ: I think there's little effort to abstract slightly and
      it would be worth it.

5) Issue #106: Proposed Abstract revision

   No objections. Editorial.

6) Issue #107: Proposed new checkpoint: 6.7 Support assistive technology 
   accessibility standards defined for plug-in and virtual machine 
   systems used by your browser

  RS: Effort has been made to create accessibility environments
     (e.g., Java). We need to ensure that standard system functions
      are implemented by browsers in this environment.

  JG: Is this a technique?

  RS: For Java in particular, this is a technique (Java Accessibility
      API). Today, browsers aren't implementing the accessibility
      features of environments. Like writing a windows browser  
      without supporting MSAA. Do we extend existing system
      conventions Checkpoint?

  GR: I support separate checkpoint?

 CMN: I'd like to reuse existing one. 

  IJ: I would say priority 2.

 CMN: I say priority 1. The requirement is implicit in other
      checkpoints on APIs and conventions. I don't think that
      we should higlight the specific case of, say Java Accessibility
      API. But recently, this was missed by a major browser.

  GR: Need to ensure that developers are aware of virtual machines
      in addition to their own software.

  RS: I think strongly that this is Priority 1. 

  JG: Are these standards specific or general?

  RS: FCK is a general purpose "screen reader" that talks to
      java components that have implemented java access support.
      Or it can be components that talk by launching the AT in 
      the virtual machine. What's missing: ability to load an
      AT that will run in the accessible environment. Also, 
      IE and Netscape don't have the built-in java access API
      that would come with the JVM shipped with the browser. 
      These browsers are not following industry conventions
      for the environment in question.

  CMN: For any plug-in environment, you must support the accessibility

  RS: Add Java examples. 
  IJ: Proposed:
       Comply with accessibility standards for supported plug-in
       and virtual machine environments.

 CMN: Sounds a lot like: Comply with accessibility standards. Propose
      adding to note that this applies to plugins, virtual machines,

  IJ: Propose adding to "Use operating system and 
      programming language accessibility resources and conventions,
      including for plug-in and virtual machine environments."

  RS: How do you handle conflicting standards: system conventions
      vs. open standards? Should they have to do both? 

  GR: We should favor interoperable. 

  JG: I doubt W3C should promote a particular standard
      that it doesn't produce.

  Resolved: Add this as a Note to existing checkpoint.
  Action Ian: Add this to the spec. For review next week.
Received on Wednesday, 20 October 1999 13:38:06 UTC

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