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

Raw minutes of 25 Jan 2001 UA teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 25 Jan 2001 16:03:36 -0500
Message-ID: <3A7094A8.D5290E2B@w3.org>
To: w3c-wai-ua@w3.org
25 January 2001 UA Guidelines Teleconference


Minutes of previous meeting 22 January:  

Next meeting: 1 February 
    Possible regrets: Mickey Quenzer

   Jon Gunderson, Ian Jacobs (scribe), Harvey Bingham, David Poehlman,
   Al Gilman, Charles McCathieNevile, Eric Hansen, Tim Lacy, Greg
   Lowney, Rich Schwerdtfeger
Regrets: Kitch Barnicle, Denis Anson, Jim Allan, Gregory Rosmaita

     Mickey Quenzer


 - Today is HB's birthday!
 - Will be attending ftf (from this call): HB, JG, IJ, AG (part-time)
   Also: RS, KB(?), EH(?)
   No: JA, DP
   Don't know: DA


2.Issue 452: Checkpoint 2.2: Review minimal requirement (three options?)

  - Adopt Ian's proposal with clarifications that user input is
    "completed" when the user says so.

  - Add techniques based on the WCAG comments.
    The UA may offer other techniques to double or triple 
    time intervals, which may also be useful.

    AG reading comments from Gregg Vanderheiden:
    "you need to provide more options for companies: three option

    IJ: We chose "infinite" as the minimal requirement to be
    sure that the user has enough time. The other options may be
    nice but exceed the minimal requirement.

    AG: I think that GV is responding from the perspective of
    preventing a denial of service attack. But that's not the
    stateless HTTP case. So his considerations may not be
    driven by the Web's architecture.

    JG: Even with statelessness, your cookie could expire (e.g.,
    due to security reasons).
    IJ: We talk about client-controlled timing only.

    AG: A likely case where you might have timeouts is the
    case of voice browsing.

    DP: All of my time-out experience has been server-side.

    IJ: Should we try to address server-side control? We already
    cover client-side control.

    AG: That falls into server administration, and the proper solution
    is probably to build in more time in the server. You can call this
    a content problem (for WCAG) or an HTTP problem (for PF). The
    protocol by which you ask for more time should be in HTTP or
    CC/PP. You don't want this on a page-by-page basis. You want a 
    generic macro.

    AG: Another client-side control scenario is periodic refresh.

    JG: So say to reviewer that some of his concerns about time
        extensions are server-side issues. 


For definition of "presentation":

Resolved from Ian's proposal.

 - Delete the term "presentation" from the glossary
 - Leave 3.2 as is, change content label to Image.
 - Delete checkpoint 3.4 since we aren't aware of
   blinking images on the Web.

/* GL and TL join */


1.Issue 389: Conformance: Hard to test conformance in an objective 

  Status: I wrote the reviewer with clarifications and asked for 
          comment. No response yet.

  Proposed resolution by IJ: We have reduced some of the conformance
  requirements as a result of the reviewer's comments. We have worked
  very hard on this conformance scheme and rejected a number of
  others. If the reviewer has specific suggestions, we will consider

  GL: My concerns about conformance to the document:
   - The checkpoint wording is so broad that it's very difficult
     to understand what it means unless you refer to notes,

   - If the document had been less ambiguous, I would not have had
     as many questions.

   - I don't believe it's possible to define something that's
     objectively measurable in terms of conformance without getting
     technology-specific. What you have is probably as good as you
     can get and still be platform-independent.

   - You need techniques documents for specific technologies (e.g.,
     HTML, or some other implementation strategy).
   - That's how the Microsoft guidelines will evolve: general
     guidelines, accompanied by technology specific complementary

   - Having the UAAG 1.0 be the only thing you can conform to
     is problematic. 

  JG: Will people want to say they conform to UAAG 1.0?

  GL: I don't see that at the current time it is interesting.
      I think the impetus to conformance could be applied by 
      outside organizations. But I don't think the impetus is
      there today from vendors.

  GL: I can imagine user organizations (e.g., NFB) as well
      lobbying a manufacturer for implementation of the Guidelines.
      Guidelines are effective for this. Clear conformance levels
      would allow manufacturers who do wish to try to conform to
      make appropriate decisions about how to do this.

  GL: Vendors may have incentive to interpret checkpoints minimally.
      That would mean that vendors might not satisfy the spirit
      of the guidelines.

  AG: Your prognosis is that the technology-independent statement
      of the checkpoints will make conformance difficult. 

  GL: I think that conformance needs to be measurable and thus
      you have to be very specific. Especially for an implementor
      who is not an expert in the field. I think you need 
      technology-specific bindings to be more effective.

  IJ: My prognostic is negative that we will have the time
      to do the technology-specific bindings at this point.
      The WCAG WG is working on this problem specifically.

  GL: My comments are suggestions, and I realize that some of 
      them may not be realistic. If your goal is measurable
      conformance, though, I don't think you can achieve it with
      a document that is technology independent. Maybe it suffices
      to warn the reader of the document of this.

  JG: Note that we have used the document to try to determine
      conformance of some user agents. The most difficult requirements
      to verify are those related to communication with other
      software. Did you have this feeling as well?

  GL: I think that you are the wrong people to test the document
      since you understand it. I compared the document's definition
      of keyboard access v. yours. It was hard for me to determine
      whether your definition said the same thing as mine. In some
      cases, it was not clear to me which checkpoints applied to
      some cases I had in my head.

  GL: It would be nice to mention in checkpoints what you expect
      the checkpoints to cover.

  GL: Certainly, the API requirements would require platform-specific
      testing tools. I don't think that your WG would be producing
      those tools. It's a problem we're struggling with as well.
      We are trying to develop more general testing tools. There's
      a technical problem in evaluating conformance to the API
      requirements. There's a definitional problem of how an
      uninformed person would evaluate the checkpoints.

  DP: The issues are so numerous and the applications are so broad.
      There is lots of discussion on the interest group list about
      how the document is not designed for those without technical

  GL: I think that in the long term, the field needs to come up
      with tools that offload the verification tasks from the user,
      especially the non-expert user. Tools need to make
      accessible tools automatic, but we also need validation
      tools that don't require expertise in order to be useful.
      They need to allow a novice software tester to generate
      a list of issues that can be turned into action items.

/* Rich joins */

  GL: It would be interesting to have three people evaluate a 
      user agent (including one who is not in the WG) and see
      what they come up with.

  Action GL: Ask someone from Microsoft whether they will
  evaluate the guidelines with a product. Deadline one week.

/* Another issue */

  GL: I thought that forward navigation alone was insufficient
      for minimal navigation through active elements.

  JG: We hope UAs will do more, but the minimum was forward
      sequential navigation.

  IJ: We have two checkpoints: sequential navigation and 
      structured navigation (which subsumes direct navigation).
      Our structured navigation relies to a large extent on the

  GL: Because "important elements" is not defined, is it possible
      for a UA to claim conformance that doesn't meet the spirit of
  IJ: What would you say if I asked you (GL) if you objected
      to moving forward with the current conformance stuff?

  GL: I think that you should clarify that the document is
      subject to interpretation.

  AG: I have the same feeling as GL: this document is worth
      publishing for guidelines. We will confuse people if we
      say "test to this docuement" instead of "design to
      this document"

  GL: It would be good to have testing experience to see how to
      move forward with testability in future versions.

  GL: My experience is having designed guidelines in the past
      and having designed standards in the past. When random
      companies try to conform to a published standard, they will
      ask for clarification over and over again. The only way
      to deal with that in practice is to be more and more specific
      in complementary materials (FAQs, etc.) and to make explicit
      points that were initially implicit.

  JG: I think WAI EO will be crucial to this effort.

  GL: I think that the techniques document will be most
      useful for developers trying to do work.

   - We expect to test the usability of the document per this
   - We may add some verbiage to the document about "design to"
     v. "test to", but that will depend on the results of our

  Action IJ: Coordinate usability testing of the guidelines.

/* TL leaves */


3.Issue 454: Checkpoints 3.6/3.7: Should these be Priority 1?

  Refer to proposal from JG:

  JG: I would be more comfortable raising refresh to P1 if we
  had implementation experience.

  DP: Lynx lets you do manual refresh.

  GL: Don't know whether IE allows user to stop auto-refresh.

  DP: Yes you can lose data if the refresh rate is too short.
      I've had this experience where I've been reading along and
      a page was yanked out from under my feet. However, if you
      don't update the page, you lose data in-between when you start
      updating the page and when you actually do.

  GL: Note that client-side redirect (3.6) often breaks the back
      functionality. If you are on page A and you go to page B which
      takes you to C, then going back to "B" may be fatal since you
      are taken to C immediately.

  DP: You can use the history to go back to in this case.

  IJ: This problem affects everyone, doesn't seem to be just about

  IJ: I think that redirect should be done on the server side.
      Therefore, 3.6 is something of a repair checkpoint.

   - (3.6) Redirect is P2 (author didn't intend user to see this page)
   - (3.7) Refresh  is P1 (author meant user to have content). 
   - Clarify that 3.7 (like 3.6) is about client-side driven refreshes.
     Delete "author-specified" in 3.6/3.7 and highlight "recognize"
   - Clarify that 3.6 and 3.7 are about pull rather than push.
   - Add to techniques to not break "back" when implementing
     client-side redirect.

4.Issue 455: Guideline 4: Change to "Ensure user control of

5.Issue 456: Editorial: Need to clarify in section 3.2 that we do not 
  mean system APIs

6.Issue 457: Checkpoint 5.4: Ambiguity about what exactly required: 
  standard APIs only?

7.Issue 458: Do link highlighting requirements apply to all zones of an 
  image map? What is required granularity?

8.Issue 443: Checkpoint 1.4: Device independent access to pointer 
  (mouse) specific events.

  Status: The document currently requires emulation of mouse-specific 
  controls by virtue of our requirement that the user must be able to do 
  everything through the mouse.


  a) Do we want to require the UA to repair device-specific bindings 
     specified by the author?

  b) Do we have evidence that the ability to simulate mouse events 
     through the keyboard benefits the user?

Completed Actions

Resolved actions from Ian:

15.DP: Send information on programmable objects based on security 
       options in IE



14.AG: Consult Trace Institute and reply to UAWG about what the 
   requirement should be for checkpoint 2.6.


Open Actions

4.IJ, EH, AG: Propose new definitions forterms in question 
              (equivalence, text element, etc.)

 8.JG: Talk to Al Gilman at the next WAI CG meeting about a joint 
   meeting with UA, PF, and Voice WG (or participants) to discuss 
   accessibility issues.

 9.JG: Send screen shots of directional techniqes

10.JG: Implementation information for guideline 2

11.JG: Propose text for the techniques document about synthesized speech 
       implementation issues. Notably UA and AT wanting to use the same 
       synthesizer engine.

12.JG: Create issue list for things that need to be addressed in the 
       next version of the document

13.JG: Request input on the resolution of issue 454

16.GR: Review checkpoints in Guideline 10 for implementation information

17.JA: Review checkpoints in Guideline 4 for implementation information

18.MQ: Send more details about control of speech parameters for the 
   techniques document based on OpenBook. (deadline open)

19.KB: Submit technique on providing information on current item and 
   number of items in search

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 25 January 2001 16:03:39 UTC

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