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

Raw minutes from 2 March UA teleconf

From: Ian Jacobs <ij@w3.org>
Date: Thu, 02 Mar 2000 15:52:21 -0500
Message-ID: <38BED485.9CD354EF@w3.org>
To: w3c-wai-ua@w3.org
WAI UA Teleconf
2 Mar 2000

Jon Gunderson (Chair)
Ian Jacobs (Scribe)
David Poehlman
Kitch Barnicle
Mickey Quenzer
Denis Anson
Harvey Bingham
Dick Brown
Gregory Rosmaita
Mark Novak
Charles McCathieNevile
Marja Koivunen
Rich Schwerdtfeger

Madeleine Rothberg

Next meeting: 9 March at 2pm ET

Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0418.html

1) Review of Open Action Items

   1.IJ: Propose checkpoint to address event notification timing issue 

   Not done, but discussions

   OTHER IJ Actions in next draft

   2.IJ: Split checkpoint 5.1 (28 January Draft) into read and UI write
         stated in minutes 

   3.IJ: Add a cross-reference from 2.1 to 5.1 and say in 5.1 that this
         a special case of 2.1 

   4.IJ: Add techniques to checkpoint 7.2 for synchronous multi-media
         presentation (space and time) 

   5.IJ: Ensure that techniques for checkpoint 1.5 talk about using
         bar to display message 

   6.IJ: Incorporate proposal for checkpoint 1.5 from minutes 

   7.IJ: Add rationale to Checkpoint 1.5: if you're deaf blind you might
         need this (Braille display). 

   8.DB: Ask IE Team about publication of review of IE 5 and Pri 1

     No info.

   9.DB: See if microsoft can produce HTML version of their developer

     DB: Status Done: Greg Lowney has wanted to get the docs into
         HTML. Asked Webmaster to do so.

    CMN: Use "tidy" to clean up Word 2000 output.

  10.JA: Rewrite techniques for 3.3 (see minutes) 

         JG: JA says for next week.

  11.MK: For 4.8 check if any media players do this? 

         MK: Done.

  12.MK: Find out techniques for sending text search requests to servers
         streamed text. 

         MK: I've sent mail, but received no replies.

  13.MR: Review techniques for topic 3.1 (Multi-media) 

         JG: MK will try to post for Friday.

  14.MR: Review techniques for Guideline 4 (Multi-media) 

         JG: MR will try to post for Friday.

  15.RS: Take timely and synchronization issues to WAI PF. Get input
         MSAA developers as well. Craft email to PF WG with Ian 

   Status: Dropped.

2) Issue CR#196: 
   It is unclear to developers how they know they conform to
   Checkpoint 6.2: Conform to W3C specifications when they
   are appropriate 


   1.Change wording "Use and conform to W3C specifications when they are
     available and appropriate for a task." 
   2.Add note: Implementing one accessible format 
   3.Add techniques: From ATAG "Specifications that become W3C
     Recommendations after a user agent's development cycles permit
     input are not considered "available" in time." 

   Action IJ: Implement this resolution.

   DA: This is basically saying: Use W3C, then system standards, then
       your own accessible methods. "When they are appropriate" means
       "if there's a straightforward way with a W3C spec, you should
       do this.

   KB: I have no problem with this wording and the accompanying note.

3) Issue CR#197: 
   Not clear with the scope of user preferences is in Checkpoint 10.7 


   1.Narrow scope to that which is specified in the guidelines
     as configurable (style and input config).
   2.Add technique: Accessible browser project portable configuration
   IJ: Note that Netscape uses X resources, which can be used on
       any X-windows enabled machine.

   Action DP: Send NN profile info.

   Action IJ: Implement this resolution.

4) Issue CR#198: 
   How much information needs to be provided to satisfy Checkpoint 8.4 

    Proposed Resolution: 

   1.Make current list of items is minimum requirement, plus any that we
     may have missed 

   DP: How does a UA know the size? 
   JG: Do a GET on the header?

   DA: Do you want this always for all links, or just be able to
       query the link? Could be expensive to do if it's not query.

   DP: I think it is useful to have this available when the link is
       rendered. Query/rendered should be configurable.

   CMN: I think we should specify "what's available to the browser"
        without having to go get information from HTTP calls.
        Note that this also depends on the linking mechanism.

     - What's in the markup (attributes, content)
     - What's the UA's state about the link.
     - External information it could get.

   IJ: Charles has proposed the first two types of info.

   DA: Seems reasonable as minimal information.

   JG: Who decides whether you satisfy the checkpoint?

   CMN: It's known since in spec or the UA knows this info.

     - Change checkpoint text to be something like:
       "Make available author-supplied and user agent 
       state information about links."
     - Add technique to distinguish this info from fetched.
       (more than the minimal requirement)

   Action IJ: Implement this resolution.

5) Issue CR#199: 
   Poor wording of checkpoint 10.8, it is not clear what the
   requirement is to improve accessibility 


   1.Ensure that frequently used functions are easily
     activated in the default configuration. 

   2.Add technique: Use operating system conventions to indicate

   DP: How do you verify easily?

   IJ: How did ATAG deal with this?

   CMN: There is subjectivity in this, but this is a reasonable person
        type test.

   DA: What are frequently used functions? Navigation, accessing
       pages, etc.

   Action IJ: Implement this resolution.

6) CR#200: 
   Checkpoint 5.5 on timely exchanges, developers not unclear on how
   they know they have satisfied this checkpoint

   Resolution Options: 

   1.Merge requirement in with other applicable checkpoints
   2.Ian's pending proposal 

     - Drop it.
     - Leave it as is. 
     - Leave it as is with an example (note) relating to in process 
     - Comparable performance to what you get from scripts.
       JG: We don't know what that performance is.
       MN: But that performance level accepted in the industry.
           If we could get AT performance with what scripting
           can do now...
       MQ: But hard to quantify the performance of scripts...
     - Distinguish static from dynamic? AT developers thought
       static just as important.

   DA: I don't think we should drop it.
   CMN: I feel strongly it shouldn't be dropped.
    KB: Does this fit into the category of general accessible
        application design? 
    IJ: Why is this problem different from a slow download.
   CMN: If the page downloads and starts doing something while
        you're doing something, you'll never know what happened.
    DP: Like playing your video tape before your television picture
        has appeared.
    JG: How about: "Use programming techniques that ensure a timely
                    exchange of information."
        The programmer can't do better than what's available to the
    KB: Does this make it more verifiable?

    JG: Say clearly in a note that developers should be looking
        for the most effective techniques.

    KB: To me this sounds like general programming advice that's
        not specific to user agents.

    RS: I think it's smart to say that you want to avoid
        cross-process communication. 

    CMN: This is an implementation requirement. Our problem
         is expressing the requirement in words other than

     JG: Can we talk about it in terms of "conventions"?

     RS: The conventions of today are too slow. 

        - Leave checkpoint as is and add an example note.
7) CR#201: 
   5.5 "Ensure that programmatic exchanges proceed in a timely manner"
        should be a priority 1 

   DA: P1 for dynamic pages.
   RS: Also for large static docs.
   IJ: I oppose P1 for static, since information is still available.
       However, for dynamic, problems if the rate of exchange of info
       is less than the rate of change of the information.
   KB: But we allow users to stop dynamically changing pages. (P1)
   JG: Also, 2.2

   RS: MSAA may not have been used extensively in the past due
       to performance issues.
   IJ: You fail 2.1 (access to all content) if you don't make
       available content that is changing. This is already P1. 
   CMN, RS, MN: I can live with this, though a sludgy way around this.

     - Add a note to 2.1 to clarify that it covers dynamically
       changing content.

8) CR#202: 
   User agent configuration to render NOFRAMES content 

   Proposed Resolution: 

   1.HTML 4.0 Specification issues related to NOFRAMES rendering

   IJ: Since 2.1 is not strictly through the UI, then making
       available through an API sufficient.

   GR: Recall, that access to frame alt requirement was dropped
       for a note, but the note no longer there:

Mechanisms for specifying alternative content vary according to markup
language. For instance, in HTML or SMIL, the "alt" attribute specifies
alternative text for many elements. In HTML, the content of the OBJECT
is used to specify alternative content, the "summary" attribute applies
tables, etc. In HTML, the NOFRAMES element specifies alternative content
frames. The ability to access frame alternatives is important for users
of some
screen readers and users with some cognitive impairments. 

   Resolved: Ian will edit this and add to definition of
             alternative equivalents for content.

9) CR#204: 
   Add collated text to Checkpoint 2.6 and 4.8 or create a new
   checkpoint at lower priority 

   Proposed Resolution: 

   1.Add collated text to checkpoints

   MK: If it's not synchronized, no problem.
   IJ: Is this more burdensome than a caption?
   MK: Same as caption.
   Resolved: Adopt Eric's proposal.
   Action IJ: Review Eric's proposal by Friday.

10) CR#205: 
    Timing issues related to AT missing or not being synchronized to
    document changes 

    Resolved: Refer to #200.

11) CR#206: 
    Precise specification of what parts of DOM are required 

    MN: I and others have a number of concerns about this module.
        I think we should leave out of this draft.

   CMN: I think it's tricky to put it in. There are good bits and
        not so good bits. 

    HB: I wouldn't miss it.
    DA: We may also be covered by 6.1 (available and applicable).

    Action CMN: Suggest some techniques related to the good bits
                 (related to checkpoint on notification 5.4).

    Resolved: Do not add the events module.

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814 or 212 532-4767
Cell:                        +1 917 450-8783
Received on Thursday, 2 March 2000 15:52:37 UTC

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