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

Raw minutes for 8 September UAGL telecon.

From: Ian Jacobs <ij@w3.org>
Date: Wed, 08 Sep 1999 13:47:15 -0400
Message-ID: <37D6A123.E66F297B@w3.org>
To: w3c-wai-ua@w3.org
UAGL Teleconference
8 September 1999


Jon Gunderson
Ian Jacobs (scribe)
Kitch Barnicle
Mark Novak
Harvey Bingham
Rich Schwerdtfeger
Marja Koivunen
Charles McCathieNevile
Gregory Rosmaita
Jim Allan
David Poehlman

Next meeting: 15 September
  Regrets RS, Cathy Laws should be there.

Agenda [1], [2]

Agenda 0) Review of action items:

   1.IJ: Run NN (and Mozilla) through guidelines. 

   2.IJ: Create a list of metadata elements and techniques for HTML 
         Done. Refer to WCAG.

   3.IJ: Send a detailed call for review to the IG. 

   4.IJ: In document, highlight existence of "native" and "applies
         For next draft.

   5.HB, RS: Look at techniques document. 

      HB: Review of Techniques

       RS: Will send in comments on Techniques.

   6.HB: Run pwWebSpeak (with Mark H.) through the guidelines. 

   7.DP: Technique 3.6 - Propose techniques 

   8.DP: Run Jaws for Windows through the guidelines. 

   9.GG: Review proposal for techniques for accessing content. 
     No info.

  10.CMN: Write a proposal for moving forward on conformance to the
     Not done.

  11.CMN: Send proposal to the UA list about including an implementation
          period as part of the recommendation process 

  12.CMN: Propose something about schemas 

  13.CMN: Talk to Dan Brickley about document structure and site
Will send a list of tools that make use of meta information to the
     Done. Conclusion: Don't think we have a checkpoint-level
          requirement at this stage.

  14.JA: Compose list of metadata sources for CSS. (e.g., generated

  15.Marja: Compose list of metadata sources for SMIL. 
     Almost done.

  16.JG: Include in RSVP a request for inidicating completion of action

Agenda 1) Review of AU last call.

  HB: I sent comments about XML info.
  IJ: I sent comments.
  DP: Have the AUGL been evaluated with real authoring tools?
 CMN: Yes. We have authoring tool developers in the WG. We've done
      conformance tests thoroughly with a couple of tools. We would
      like to see more testing. The conformance test with Amaya
      is part of the Techniques document.
 CMN: I'd like to exclude Gregory, Ian, Jim from review since they
      are intimately involved with the process.

 CMN: We want:
  a) A statement that the AU satisfies all needs of the UA Guidelines.
  b) Review from anyone.

  Action Jim, Kitch: Send list of dependencies between AU and UA WGs to
      the AU and UA lists.

  Gregory also says he will review the guidelines.

Agenda 2) Face-to-face/Last call.

  Reminder: Sign up for UAGL face to face, 11-12 October at Microsoft.

  IJ: WAI Team met yesterday. Consensus to wait until
      after face-to-face.

  Resolved: Go to last call after the face-to-face meeting.
  Action Ian: Find out about MS review of document before ftf
              and their participation in the meeting.

  Action Ian: Find out from Judy about NN attendance.

  Action Ian: Find out from Judy about Operasoft attendance.
              IJ: Will talk to Håkon Lie.

  HB: Softquad's HotMetal.

  Action JG: Compose list of assistive technology developers
             for invitation to ftf.

Agenda 3) Conformance.

  JG: I think that we require a third category for
      specialized tools. Not designed for general
      use. But we should still have something for
      them in the document. A category for them
      would resemble the dependent UA category.
      For both of these types, we need to address
      the issue of device-independence. I looked
      at charter, which discusses interoperability,
      but not necessarily between dependent UAs.

  RS: Would another group require a major rewrite of the

  IJ: No.

 CMN: But requires lots of thought...

 CMN: My problem with the whole concept is that 
      if I target a particular market, but provide
      a customizable browser, I don't have to
      worry about interoperability. This is a 
      description of Netscape Navigator (Mozilla).
      Their targeted audience is people using
      a desktop graphical browser. 

  RS: I mean targetted for a particular

 CMN: You can build lists that allow you to
      compose lists to let you target whatever.

  IJ: What about just re-examining the device
      independent checkpoint, for example?
      Just say that if you support a particular
      API, you must do it accessibly.

  KB: So same set of checkpoints, just different
      definition of "applies to"?

  IJ: Yes.

  MN: I agree with Charles. I'm concerned about how
      people will twist around the document.
      Can we be more specific in the Techniques?

  IJ: I think the Techniques are too informative.

  RS: One part bugs me: communication between
      dependent user agents. Targetted user agents
      (e.g,. multi-platform) that try to meet
      accessibility guidelines don't have resources
      for doing communication when this is not their
      targetted audience.

 CMN: I have a problem saying a targetted tool
      is an accessible user agent. They are
      useful, but don't belong in this document.
      Or at least conformance doesn't apply.

  GR: I don't think targetted information should
      be included in a general document. (Said this
      last week). Also, the impact matrix will
      be useful for targetted UAs to find out what
      applies to different groups. I don't think
      another subclassing will help.

  JG: What about tweaking other definitions?

  GR: More reasonable approach. I'd have to review
      a concrete proposal. E.g., in the case of HPR,
      the graphical view is available to the user
      (on demand).

  IJ: Recall this from UAGL (about native support):
          "A user agent supports a feature natively if it 
           does not require another piece of software (e.g.,
           plug-in or external program) for support."

  RS: With HPR, you have several options for having
      Netscape render info. HPR could be considered a dependent
      user agent, but it targets a particular audience.

  MK: I was thinking about device-independence. If the 
      dependent UA gives an interface for the information
      (e.g., speech) then you can use the guidelines.
      E.g., are we requiring UAs to provide a keyboard API?

  DP: Most dependent UAs I know of allow multiple device input.
      PwWebSpeak has more standard components available than HPR.
      So I see HPR more as a screen reader for Netscape.

 CMN: We're talking about a conformance statement that will allow
      HPR, PWWebSpeak, etc. can conform. I think this is a mistake.

  RS: I think it's unreasonable to ask ATs to support all the
      other AT requirements. Dependent UAs are an enhancement,
      providing secondary access.

  IJ: I think including in this document will promote interoperability
      even if people don't have to satisfy all the checkpoints.
      Just being there will benefit developers.

  RS: I propose variable priorities. E.g., Priority 2 for dependent UAs.
  IJ: Note danger of saying "Don't have to do this since we
      don't have resources." Can use that argument for not providing
      accessible documentation.

 CMN: This WG is not chartered for creating legal requirements.
      Broad guidelines fit too many people and doesn't fit anyone
      in the end. I like the variable priority approach.

  RS: I'd hate to not encourage people to develop assistive
      technologies because the interoperability requirements
      are too strong.

  JG: Seems to be consensus not to have more than two categories.

  JA: There's no definition of graphical desktop browser or
      dependent UA.

Action Ian: Propose list of checkpoints that are "sensitive"
   (affect targetted UAs) and propose variable priorities/rewording
   for them. (Look at HPR's evaluation.)

Action Jim: Propose definitions to the list.

Agenda 4) Configuration checkpoints.

 GR: Two checkpoints proposed (and list of techniques)

  a) One for links: Allow user to configure what      
                    information about links is presented. [P1]
     (Would replace 9.5 and 9.6 in 27 Aug draft).

  b) One for form controls: Allow the user to view a 
                    list of FORM controls. [P1].

  DP: I like merging a with 9.5 and 9.6.

     a) Rationale of 9.6 lost if merged with (a).
     b) I don't think should be priority 1.

  JA: Gregory has two checkpoints that he's rolled together
      View, focus info available and configurability confusing.

  GR: Then drop the second sentence from first proposed checkpoint.
  About checkpoint 9.5:

  GR: Make the dependency on micropayments more visible.

  Action Ian: Make the dependency on micropayments more visible.

  GR: I think that configurability is important, but also 
      need a maximum amount of information about links is important.
      Propose 9.5 and 9.6 as P2.

  Action Ian: Include GR's link checkpoint as P3 (configurability).
              Change priority of 9.6 to P2.
              Get techniques out of [1].

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0127.html

  Discussion of proposed checkpoint for FORM controls list:

  IJ: I don't think should be P1.
  GR: Then P2. Tabbing can be disorienting if you don't know tab
  IJ: How does list of form controls help?
  JA: Helps when form is designed poorly (e.g., submit button
      is followed graphically by other important controls).
  DP: Would a correctly coded form require this information?
  IJ: Example of submit button after other controls can be valid HTML.

Received on Wednesday, 8 September 1999 13:47:24 UTC

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