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

Raw minutes from 1 September UAGL teleconference

From: Ian Jacobs <ij@w3.org>
Date: Wed, 01 Sep 1999 15:22:42 -0400
Message-ID: <37CD7D02.E86760DF@w3.org>
To: w3c-wai-ua@w3.org
CC: jbrewer@w3.org
User Agent Guidelines Teleconference
1 September 1999


Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Gregory Rosmaita
Harvey Bingham
Jim Thatcher
Kitch Barnicle
Mark Novak
Judy Brewer
Marja Koivunen
David Poehlman
Rich Schwertdfeger
Charles McCathieNevile
Jim Allan

Agenda [1]:

1) Review of action items
2) Last call scheduling
3) Conformance

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

Agenda 1) Review of action items.

   1.JG: Draft outline for section 5.3.3 of techniques document. 
   Status: Done. (URL?)

   2.IJ: Run NN (and Mozilla) through guidelines. 
   Status: Not done.

   3.IJ: Issue 56 resolution 
     a) Mention media objects as example in checkpoint 1.6. 
     b) List as example in checkpoint 9.6 
     c) Incorporate media objects into 10.5 and 10.6. 
   Status: Done in 27 August draft.

     a) Add links to WG page with disclaimer about volatility of Working
        Drafts and products. 
     b) Proposed disclaimer to be inserted in evaluations. 
   Status: Done in 27 August draft.

   5.IJ Send proposal to WCAG to propose different wording on the
        requirement for text rendering by UAs. 
   Status: Done in 27 August draft.

   6.IJ: Create a list of metadata elements and techniques for HTML 
   Status: Not done.

   7.HB, RS: Look at techniques document. 
   Status: HB has four pages written, pending.
           RS: Not done.

   8.HB: Run pwWebSpeak (with Mark H.) through the guidelines. 
   Status: Installed, starting to review. Hope to do this week.

   9.GR: Run Hal through the guidelines. 
   Status: Done 

  10.DP: Technique 3.6 - Propose techniques 
   Status: Not Done.

  11.DP: Run Jaws for Windows through the guidelines. 
   Status: Not Done.

  12.KB: Fill in the table for UAGL and coordinate with Wendy Chisholm
Web Content 
   Status: Done.

  13.GG: Review proposal for techniques for accessing content. 
   Status: No information.

  14.RS: Coordinate review of HomePage reader. 
   Status: Done.

  15.CMN: Send proposal to the UA list about including an implementation
          period as part of the recommendation process 
   Status: Not done.

  16.CMN: Propose something about schemas. 
   Status: One more week, otherwise will drop.

  17.CMN: Talk to Dan Brickley about document structure and site
          Will send a list of tools that make use of meta information
          to the list. 
   Status: Pending.

  18.JA: Compose list of metadata sources for CSS. (e.g., generated
   Status: No information.

  19.Marja: Compose list of metadata sources for SMIL. 
   Status: Not done.
   HB: Will this include SMIL "Boston" (the latest version of SMIL?).
   JB: Would be difficult since only a WD.
   MK: Ok for SMIL 1.0 only.

  20.RS: Consider the "applicability clause" and propose rewording of
         conformance statement for checkpoints. 
  Status: Done. (URL?)

  21.RS: Post list of checkpoints at issue to the list related to review
         Home Page Reader. 
  Status: Done. Included in the HPR evaluation.

  22.Reviewers: Read conformance section of guidelines before testing
sub-grouping of checkpoints with current products 

  23.Reviewers: Should be as specific as possible about product
os versions, etc. 

IJ: People should send status info to Jon when they reply to
    invitation to meeting.

ACTION JG: Include this message in next call for participation.

Agenda 2)  REMINDER: Register for October F2F Meeting 

JG: Remember to ask for the W3C rate at the hotel.
    The registration page is up and running.

Agenda 3) LAST CALL: Timing and document preparation 

JG: We are nearing, but have not entered last call. The original
    intent of the face-to-face was to address comments that
    came in during last call. But given state of techniques
    document and number of open issues, not ready to go to 
    last call yet. Therefore, I'd like to discuss the impact
    on the face-to-face meeting.

DP: Have all the unfilled techniques been assigned?

IJ: No. We sent a call for attention to the UAGL list.

JB: Do you want to send to the IG?

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

JG: What do people think about going to last call?

MN: I have mixed emotions. Recent issues raise some 
    concerns. Also question whether we should have a face-to-face.

JG: I feel strongly that we should go to last call shortly
    after the face-to-face.

RS: I feel we need to resolve the conformance issue ("targeted agent")
    before going to last call. Otherwise, I think the guidelines
    are pretty good.

DP: I think we should tackle outstanding issues first. I'm not
    certain we could be ready for last call by the end of next week.

GR: I agree. In my evaluation, I emphasized checkpoints that
    might be better as techniques (e.g., following a link involves
    a fee).

IJ: (Review of process)

 a) The sooner you finish the document, the sooner developers will
    use it.
 b) If you wait, you are likely to have a better document. But
    don't wait too long since document may become irrelevant.
 My preference, all other things equal, is to go to last call
 as soon as possible. But if you have open issues, don't go
 to last call yet. Another consideration is staff resources.
 AUGL and UAGL are running neck and neck. If they go to Recommendation
 in parallel, will make it tough on W3C Team resources. We don't
 know how the timing of this document is affecting developer
 browser release cycles.

 JB: One possibility is to go to last call in three weeks, then
     have a 3-week last call. That may not be enough time to
     compile comments in time for last call. Strategically,
     you don't want to send doc out twice for last call. However,
     you can take extra time before going to Proposed Recommendation.

  HB: A number of the major browser/assistive tech groups have
      had no input to this process.

  CMN: In AUGL, we've had a similar experience. But we've approached
      developers lately who've said "We haven't commented but
      we're trying to implement them!"

  JB: What's the strategic impact of waiting?

  IJ: Let's get other developers on board during this interval
      before the face-to-face.

  GR: Use evaluations as feedback to developers.

  JB: But, until you say to someone "Last chance for comments",
      people may not react or be motivated.

  GR: In some cases, we may still light a fire under developers.

  JB: We tried this in AU, but had no impact. We tried last year
      internally but was a returnless effort.

  JG: I don't think we'll get developers to jump to attention until
      we go to last call.

   JG: I propose that we try to go to last call 16-17 October. We
       will revisit the question at the next teleconference. Judy,
       Jon, Ian will discuss resource issues offline.

   JB: I've argued for moving to last call soon. If the WG
       feels that's ill-advised, please disregard my comments
       as needed.

Agenda 3)  Issues #77 and #79: Conformance for some assistive techs.

JG: RS has proposed a third conformance class.

JG: IBM HPR, Avanti, PWWebSpeak don't fit easily into
    dependent UA group. I'd like the dependent UA class to
    represent advanced features. We don't care whether these
    features are implemented in a browser or assistive tech.

JG: Biggest concerns with dependent UAs relate to compatibility
    guideline (6 in 27 Aug draft).

a) What was the intent of the dependent UA category?
   Seems to be "everything but graphical desktop browser".
 JB: What about text browsers?
 IJ: You conform by meeting a set of checkpoints. That's all it
JT: I don't want Productivity Works to spend time putting
    MSAA into its specialized interface. We would have to
    in order to conform as dependent UA. They shouldn't
    have to based on their "targetedness".

JG: Checkpoint about communication between dependent UAs 
    to promote communication between them. If that's the
    major issue, let's review it. Are there other checkpoints
    that don't make sense?

JT: There are others - because HPR is targetted to people
   who use speech and the keyboard, we shouldn't have to
   comply with 1.1. 

CMN: The problem with the targetted approach is that
   users working together may have different functional
   needs. Graphical desktop browser is a targetted UA.

IJ: Have you seen "applies to"?

JT: No. That helps, but look at "low vision" requirements.
    We have to say "not applicable". Our graphical interface
    is not relevant to the evaluation.

JG: Issue: Which output of the tool do you evaluate? Primary
    or secondary?

 JT: The visual user interface of HPR is irrelvant for the
    discussion we're having.

 RS: The only reason for the visual interface is to help
    a sighted user work with someone who cannot see.

  JT: Also for debugging.

  DP: If a blind person is teaching a sighted person, the
    sighted person would still need an interface.

 JT: HPR can turn on synchronziation for this purpose: cause
    Netscape to bring up the same page.

 DP: My concern here: can I voice command input into HRP.
    That's a legitimate concern.

 JT: Yes, through the keyboard API. You can use voice
    recognition, therefore, to activate keys.

 KB: Will the font/color adjustments apply to Lynx?

 DP: Lynx doesn't care about fonts. So no, doesn't apply.

 JT: We have comparable
     requirements for voice (e.g., changing voice
     for links).

 CMN: Lynx hands off issues of font size to the OS.
     But I agree that you can't style or control the
     presentation of a link w.r.t. an ordinary piece of

 JT: For Lynx, there are no fonts.

 IJ: There are colors, though.

 JG: I'd like to move back to the question of 
     PWWebSpeak and HPR in terms of conformance.
     Need to evaluate definition of "applies to".

 CMN: If you take a given UA, you can say "This
     UA requires a minimal set of input/output." For HPR,
     the minimal output set is speech. MInimal input set
     is the keyboard. That is has added input/output
     is not relevant for conformance.

  DP: There are one or two UAs that are uncommon in their
     special capabilities for specific audiences. I think
     we need only expand the definition of "applies" to
     be able to exclude device issues. 

  JT: I agree with this approach.

 CMN: Do HPR need to apply to UAGL at all? Maybe they
      don't since they are trying to meet specific needs.
      We've been addressing "general accessibility" up to
      now. A UA that didn't allow that therefore wouldn't
      conform. I don't think this is a bad thing. In short,
      specialized tools may not need to conform to the
      same set of guidelines as a generalized tool.

 JT: Then bite the bullet and state that.

CMN: One possible outcome would be to drop the dependent
     user agent conformance clause. Dependent user agents
     don't conform unless they attempt to function 
     more generally. I think, however, that it's still
     critical to explain how assistive techs will work with
     general tools that conform.

RS: And for dependent user agents, we would need guidelines
    for features relevant to a particular disability. What
    I have a problem with is "do so natively" definition.
    Do we need to redefine this for targetted UAs?

CMN: I think we should specify what we expect dependent
    user agents to do in order to interoperate with a
    conforming UA. But we should drop other requirements
    for targetted UAs.

 IJ: We've had this discussion already at the beginning
     of 1999. It proved too difficult to break out
     the different functions, devices, content types
     into different documents or guidelines. We decided
     to keep it all in one document.

 GR: I propose creating W3C Notes for particular slices.
     I second CMN's motion to drop the subclassing.

 JG: Recall that the split was made, in part to allow
     consumers to ask intelligent questions about
     assistive technologies. I gather from previous 
     discussions that assistive tech developers want
     to be able to conform to the UAGL. So benefits to
     consumers as well as assitive tech developers.

  RS: The impact matrix is very helpful for figuring
      out what's important for a targeted agent. 
      E.g., I'm building a speech output device on
      multiple platforms. I would want this type of
      of checklist. I would want to consider less
      the particular platform. If, on the other
      hand, I were building a speech synthesizer to
      run in the background would do something else.

   IJ: We've already had a proposal (in January)
       to not have conformance at all, but just
       suggest profiles and have developers
       fill out the checklist.

    DP: Screen readers are, can, and should be providing
	access through interfaces. My expectations
	are rising. I think there is a need for the
       dependent UA checkpoints that are in there that
       promote interoperability and cooperation. 

    KB: One fear about the impact matrix is that
      singling out a particular population will cause
      people to ignore important features for other users.
      In many cases, benefits are for multiple groups,
      even though there may be a particular population that
     would benefit most. In many cases, all users, and
     use at the same time by several people, needs to be considered.

   MK: The matrix is kind of a "next phase" after conformance.

   GR: I don't think that targetted information should be
      included in a document that addresses generality.

  CMN: The impact matrix (assuming it's correct), allows you
      to say "I'm not interested in a universally accessible
      product" and you can be relatively sure to satisfy
      requirements. I don't think we should write a Note, however.
      It's a byproduct of the group.

   IJ: I think our charter says that we must consider targetted
      user agents. Can't just dismiss them.

   RS: My main issue is "applies to". Perhaps we need wording
       that some functionalities are not fundamental to 
       accessibility, but are only meant for people "along for the

    IJ: I have problems with "along for the ride". A lot of people
       would say the same thing about documentation. But it's
       certainly vital to using software for many.

     RS: I don't want to do major surgery on the guidelines. The
        area that needs focus is "native support." Don't change
        the whole document.
      HB: Would it be worth having another reply (other than 
       yes, no,  not applicable) for checkpoints.

  Action CMN: Write a proposal for moving forward on this issue to 
       the list.

  Action IJ: In document, highlight existence of "native"
    and "applies to".
Received on Wednesday, 1 September 1999 15:23:29 UTC

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