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

Raw minutes from 12 January UA Guidelines teleconf.

From: Ian Jacobs <ij@w3.org>
Date: Wed, 12 Jan 2000 13:39:44 -0500
Message-ID: <387CCA70.CEF67D2F@w3.org>
To: w3c-wai-ua@w3.org
WAI UAGL Teleconference
12 January 1999


Jon Gunderson
Ian Jacobs
Kitch Barnicle
Denis Anson
Harvey Bingham
Dick Brown
Charles McCathieNevile
Gregory Rosmaita
Jim Allan

Rich Schwertdfeger
David Poehlman

NEXT MEETING: 13 January 2000 @ 2pm ET for 90 minutes

Agenda [1]

1) Review of action items

Review Open Action Items

   1.IJ: Draft a statement for time of publication, there is no
authoritative body that validates claims of conformance 


   2.IJ: Repropose the delivery mechanism of conformance statement to
documentation as an option 


   3.IJ: Follow up on EH's e-mail with some comments from this meeting
related to issue LC#138 (will post as new issues if any) 

   Note done.

   4.IJ: Publish a new draft of requirements document that incorporates
JG'sand other comments. 


   5.IJ: Make clearer in Checkpoint 8.1 that it is "information provided
         the user." 


   6.IJ: Harmonize language in the spec so that a single expression is
to indicate "provide information to the user". (as opposed to
programmatically). Indicate both explicitly when both. 


   7.IJ: Indicate that this is a special case of 10.3 


   8.JG: Review techniques for Guideline 8.9 


   9.JG: Draft a preliminary implementation report for CR

  Status: For this afternoon.

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

  Status: Pending.

  11.DB: Find out how developers find out which appropriate triggers to
  in Windows for using built-in accessibility features (i.e. sound
  show sounds, ...)

  Status: Pending.

  12.DP: Propose new Checkpoint 1.5 for access to system messages 

  Status: Not done.

  13.GR: Send to the list techniques for how to use and control focus to
not have new windows cause problems for usability. In particular, how
will work with ATs. 

  Status: Pending.

  14.GR: Write a technique on how to create accessible installation

  Status: Pending. Refer to GR's email on installation.

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

  Status: Not done.

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

  Status: Not done.

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

  Status: Not done.

  18.MR: Run a multimedia player through the guidelines for January. 

  Status: Not done.

  19.MQ: Ask Mark about meaning of comment raised in Issue #167 

  Status: Not done.
  GR: MN not back from Japan yet.

  20.WC: Take form submission to GL WG to discuss issues related to
         inadvertent submission. 

  Status: Not done.

2) Announcements 

   1.Regular UA telecon scheduled 13 January 2000 at 2:00 pm to 3:30 pm
     Eastern Standard Time, USA 

3) F2F Meeting to process Proposed Recommendation Issues 

   CMN: Based on ATAG, I think it would be worthwhile. I'd also
        suggest allowing a long time. Book extra time (3-4 weeks)
        Note: CMN will be in the UA in April.
   GR: Other WAI meetings around CSUN. 

   JG: WCAG may not meet then due to unavailability of chairs.
       Possibly 27 March.

   JG: Who's willing to go to a meeting late March, early April:
       KB, CMN, DB, DA, GR, IJ, HB, JG.

4) Candidate Recommendation Preparation

   HB: Do we get an early read from developers?

   IJ: I think coordination is the piece that's missing in our
       preparation for CR.

   KB: The plan is reasonable. 

   DB: I will coordinate with IE Team.

   GR: JG should contact MH at ProdWorks.

   GR: I can work with Dolphin.

   GR: I can talk to Håkon (since I'm a beta tester). How would
       we handle a review of a beta-version?

   IJ: I will talk to Håkon.

  CMN: I'll be talking to RealNetworks people in Seattle.

   JG: Other Netscape contacts?

   GR: Mozilla? 
   JR: We can talk to IBM contacts about Mozilla.

   Schedule for CR:

   IJ: Probably not ready for CR 14 January. Will try for following

5) User Agent Responsibilities Document

   GR: I like the direction it's taking.

   JG: Send comments to the list.

6) Issue LC#162: Raise priority of 8.9 (consistency in configs) to P2. 
   KB: How will developers say that they meet this checkpoint?
   JG: How much consistency is required?
   IJ: Seems like usability, not accessibility to me.
   GR: If the configuration changes significantly, it should be noted
       in documentation and README.
   IJ: Seems like definition of P3 applies.
   DA: Can be a bigger problem for users with cognitive difficulties.
       Rearranging controls makes it very difficult.
   KB: Is documentation of changes more important?
   IJ: Another factor - difficulty of establishing minimal
   JG: If the change makes using the tool easier, but there is
       inconsistency, what do you do?
   DA/GR: I think it's arguably a P2, but we do have a problem with
       identifying how you meet it.
   CMN: My gut feeling is P2, but not sure.
    JA: Same here. It's hard to nail down which direction to go on this.
    GR: We need to point developers to the other aspects of the
        question, notably documentation of changes.
    HB: I think P3 is ok.
    DB: I think P3 is ok.
    KB: This falls to me in the category of general UI design. 
            - Delete checkpoint 8.9. Move discussion to guideline
              or principles of accessible design.
            - Talk about documentation of changes in G11.
    DA: We're trying to say: don't make arbitrary changes. Will that
       in prose alone make it clear that this is an accessibility

    GR: I'm ok with deleting the checkpoint as long as clearly
        indicate that documentation important.

    DA: I still think it's a significant issue, even if it's in the
        documentation. It's a burden beyond the documentation.

    KB: I agree that it's an important issue.

    IJ: Proposed:
        - Delete 8.9
        - Add a checkpoint in documentation (P3)?

    GR: Dolphin offers compatibility modes. This has boosted their
        sales. Propose adding a technique to configuration checkpoint
        about compatibility with previous UIs.

        - In principles of design, add consistency to list of 
          good design ideas.
        - Delete 8.9
        - Add a P2 checkpoint in G11 about documenting changes
        - Add a technique to config checkpoint about compatibility

   Action IJ: Update document with these changes.

7) Issue LC#166: Review priority of 10.5 (default configs that interfere
   OS conventions) 
   IJ: 10.5 in 20 Dec 1999 draft.
   DA: If the OS intercepts keystrokes, the UA won't see those
   JG: But that's the same for everyone.
   DA: But may be an accessibility if you can do it through mouse but
       not keyboard.
   KB: That's covered by 1.1
   GR: Do we have "mobility access keyboard modifiers reserved for
       the operating system" in the techniques document?
   JB: I think in the appendix.
   GR: Based on the second sentence it's a P1 item. (e.g., breaking
       accessibility input methods). 

       - Change 10.5 to P1 "Avoid default input configurations that
                interfere with operating system accessibility
       - Move first sentence of note afterwards to techniques for 5.6

   Action IJ: Update document with these changes.

8) Issue LC#175: Proposed raise (to P1) of checkpoint 4.18 

   IJ: 4.15 in 20 Dec draft.
   GR: In the absence of notification, serious accessibility problems.
       People think that their history mechanism is broken. People
       often work around by shutting down the browser window.
   DB: I think it's inconvenient, but not impossible. P2.
   GR: The key point is knowing; not the event itself.


     - Leave P2
     - Move "SMIL" example in Note to techniques. (Ian to simplify)
     - Add cross-ref from 4.15 to 9.1

   Action IJ: Update document with these changes

9) Issue LC#176: Proposed change in priority (P3 to P2) for checkpoint
   (link information) 

   IJ: 8.3 in 20 December draft. 

   KB: If a UA implements CSS, do they meet this checkpoint?
   IJ: If pseudo-elements supported.
   DA: If you have a page with lots of links, if you don't have 
       a way to know which you've visited, you have to memorize that
       and it's difficult to access the data.
   GR: There are a lot of superfluous links on pages, notably portal
   DA: I think it's a P2.
   GR: I think P1, but can live with P2.
   JA: I think it's a P2.
   HB: I think it's a P2.
   DB: I think it's a P2.

        - Make 8.3 and 8.7 P2.

   DB: I have a reservation about making 8.7 P2. I think  developers
       might not add features because of this.

   DA: You can't find a way to present link information that is 
       accessible to everyone. 

   GR: Refer to section 3.3 of techniques document (link techniques)

   KB: Do we have a checkpoint for link presentation?

   IJ: Yes: 8.6

   KB: If the UA supports CSS, does that suffice? Or does the UA
       also have to provide a piece of UI for presenting information?
       Or must the default style sheet display all information?

     - The concept is P2.
     - Problems with ambiguity of the checkpoint.
       There may be some implementation problems.
     - Configuration less important if UA makes right choice
       about what information to present.

   Action GR: Send screen shot of JFW link view.


     - Add (back the old) 
       checkpoint for visited/unvisited links P2. If you don't have
       access to that information is to follow a link and then return.
       For complex pages, this becomes an unreasonable burden for
       people with non-graphical browsers or cognitive disabilities.
     - Leave 8.3 and 8.7 as is (removing visited).

   Action IJ: Update document with these changes.
Received on Wednesday, 12 January 2000 13:40:00 UTC

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