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

Raw minutes from 24 August UA WG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 24 Aug 2000 15:54:26 -0400
Message-ID: <39A57D71.E0EBA9E3@w3.org>
To: w3c-wai-ua@w3.org
24 August 2000 UA Guidelines Teleconference

 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 Eric Hansen
 Kitch Barnicle 
 Denis Anson
 Gregory Rosmaita
 David Poehlman
 Tim Lacy
 Dick Brown
 Harvey Bingham
 Rich Schwerdtfeger (for 2 minutes)

 Mickey Quenzer
 Jim Allan

 Charles McCathieNevile

Next meeting: 31 August

Minutes of previous meeting:


    1.Issue 310: What level of WCAG compliance should checkpoint 11.1 
      require or should it be relative priority?

    JG: One option is to include in your conformance claim what
    at what level you conform to the documentation.

    IJ: This requires a reviewer to go look at the claim in detail.
    You don't know from "Level X" what the UA will have done for
    checkpoint 11.1.

    EH: Since P3 requirements "may help" accessibility, it seems like
    requiring that for UA 1.0 is too stringent.

    GR: Some WCAG 1.0 P3 requirements are very useful (e.g.,
    acronyms). I think that it should be Level Triple-A in all cases.

    DP: If you're developing a UA and your documentation is on the 
    Web, but your UA doesn't conform, that may be confusing. I agree
    with GR.

    IJ: The best documentation is no documentation...

    IJ: I hear three proposals:

     1) Level Double-A always
        JG: This covers all things that would make access either
            impossible or difficult. One reason in particular:
            table formatting.
        DA: Why does documentation have to rise to a higher level
            than other checkpoints?

        EH: Note that since we're allowing conformance by composite
            UAs, the multiplicative effect is relevant.

     2) Level Triple-A always
     3) Relative priority
        DB, TL: Intriguing (graceful), but may be complicated.

    HB: Note that you could have bad, but accessible, documentation.

    KB: As I look at the P3 checkpoints in WCAG 1.0, I'm not convinced
    that all of them will make a difference. Some of them may, and
    perhaps the WCAG WG should re-evaluate checkpoint priorities.

    Level Double A minimal: KB, EH, DA, JG, IJ, DP, DB, TL
    Level Triple A minimal: HB, GR

    Resolved: Level Double minimal requirement for checkpoint 11.1.
              Note: There was dissent on this resolution. WG
              participants may request that their objections be
              carried forth.

    5.Issue 309: Applicability needs review: how to tell when 
                 checkpoint MUST be followed.

    Refer to analyses:
        IJ: http://www.w3.org/WAI/UA/2000/08/uaag10-applic

    EH: I think it's ok to have applicability issues, but the tighter
    focus is for this document (type of UA we're intending this
    document for) the more the applicability issues disappear. For
    instance, we're talking about UAs that implement text, graphics,
    audio, and video. If you assume this in the target UA, you don't
    need applicability clauses for these content types.

    IJ: I agree with EH that the tighter the document, the fewer
    applicability provisions are necessary. But I am not comfortable
    with too much tightening (e.g., you have to implement audio in 
    order to conform).

    EH: Note also that the less inapplicability, the greater the
    likelihood that conformance will translate to accessibility.
    IJ: EH has identified the "moving part" in the document: more
    flexibility to conform means you either say nothing about
    the moving part (let reasonable people interpret claims) or
    you point to them in applicability clauses.

    EH: I'm concerned about pursuing some of my proposals before
    some distinctions are addressed in WCAG.  

    IJ: What about folding in the provision into the checkpoints? 
    (e.g., if you support X, allow control of X). But this can
    get heavier as you have to combine provisions.

    EH: I think we need to remove "graphical" from our description
    of the target UA since graphics are not required by the document.

    GR: I think that the applicability provisions should be folded
    into the checkpoint somehow. Reduce work on the implementors.

    EH: Applicability provisions are pretty intuitive: if you don't
    support you don't have to do. If you explain this idea in one
    place, you don't need to repeat in each checkpoint.

    IJ: We didn't say for WCAG: "For any table that you use, use
    table headers." 

    a) Incorporate proposal (only four provisions)
    b) Include informative list of checkpoints for the remaining
       four. If the WG doesn't like this, get rid of.

    JG: Ask developers at last call whether they want applicability
    incorporated in the checkpoints.

    Resolved: Change "graphical general purpose UAs" to 
    "general purpose UAs".

    IJ: EH, have we missed other pieces besides "native", "recognize",
    and "applicability" from your proposals?

    EH: Possibly "primary/alternative". 

    IJ: We'll get to with issue 297, I think.

    2.Issue 292: Review list of speech synthesizer characteristics 
      (checkpoint 4.11)

    HB: Gender and pitch are very similar. You could get away with
        gender alone. Some japanese users, for example, require more
        information in inflection.

    DA: Voice for a sighted person differ from requirements for a
    blind person.

    /* Reduce the list? */

    HB: No, satisfied with current list.
    /* Add to the list? */
    GR's proposal:

    IJ: How do you tell your speech synthesizer what you want?
    If you're implementing CSS2 aural style sheets, I know how
    the mapping from content to rendering works. Otherwise?

    DA: It seems like that the user should be able to configure
    that's configurable.

    IJ Proposal:
     a) Leave speech synthesizer checkpoints as they are.
     b) Ensure that Voice Browser WG documents include accessibility
        features. There is a WG dedicated to this topic.

    GR: Need to ensure that UAs don't preclude users from configuring
    their speech synthesizer software.

    GR: Propose : speak-out, speak-punctuation, and number processing
     (as described in CSS2 speak-numeral).
       a) Add verbiage for configuration of spelling, punctuation, 
          and number processing offered by the speech engine.
       b) Get Voice Browser WG review of these three checkpoints
          in last call.
       c) Ensure coordination with VBWG for future coordination.

Completed Action Items

    1.IJ: Rewrite what "recognize" means based on user agent 
          programmed functionalities. Refer to 18 August draft

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 24 August 2000 15:54:29 UTC

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