Raw minutes from 22 Sep UAGL teleconf.

User Agent Guidelines Teleconference
22 September 1999

Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Gregory Rosmaita
Charles McCathieNevile
Kitch Barnicle
Mark Novak
Madelaine Rothberg
Marja Koivunen
Rich Schwerdtfeger
Al Gilman

Regrets:
Harvey Bingham
Jim Allan

Agenda [1]

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

1) Review of action items:

   1.JG: Run pwWebSpeak (with Mark H.) through the guidelines. 
    Not done.

   2.JG: Ask Denis Anson to review the document 
    Done, but haven't heard back.

   3.JG: Propose techniques for rendering of frames 
    Not done.

   4.JG: Ask Al Gilman to come to the next meeting to talk about spawned
         windows 
    Done, Al will arrive at about 11:30.

   5.IJ: Find out about MS review of document before F2F and their
         participation in the meeting. 
    Pending.

   6.IJ: Run NN (and Mozilla) through guidelines. 
    Done.

   7.IJ: In document, highlight existence of "native" and "applies to". 
     Refer to 
     http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0396.html

   8.IJ: Make the dependency on micropayments more visible. 
    Done. Added reference to that WD.

   9.IJ: Include GR's link checkpoint as P3 (configurability). Change
         priority of 9.6 to P2. Get techniques out of [1]. 
    Done. For next draft.

  10.IJ: Propose checkpoint wording for access to form control
         information.
    Done. 
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0395.html

  11.IJ: Rewording of checkpoint 4.12: Allow the user to turn on and off
         rendering of frames 
    Done. 

  12.CL: Submit a technique related to text rendering of client-side
image
         maps .
    Done.
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0383.html

  13.HB: Submit a technique related to using for ABBR and ACRONYM
elements
         for rendering 
    Done.
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0382.html

  14.DP: Technique 3.6 - Propose techniques 
    Not done.

  15.DP: Run Jaws for Windows through the guidelines. 
    Not done.

  16.GG: Review proposal for techniques for accessing content. 
    Not done.

  17.Working Group: Review IJ proposal for changes in conformance for
     discussion next week 
    Done.

2) Conformance.

   Ian reviews conformance proposal.
   http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0365.html

   KB: Is it basically all or nothing for communication?

   CMN: If you don't work with other software, then you're not
        interoperable.

   RS: Are there degrees of interoperability?

   JB: Yes, there are different priorities for those checkpoints.

   MN: I think this is the wrong direction since it weakens
       conformance. I'm not comfortable with this direction. Why
       would you offer conformance for UAs that don't meet
       published software accessibility standards. I could say
       I'm interoperable and not support some standard API.

   IJ: You could not support the mouse and still be interoperable.
       But if you support the mouse, you need to do so accessibly.

  CMN: My concern: HPR is not an accessible user agent, per se. 
       It's a good tool for a certain set of user, just like NN
       is useful for a set of users. I don't want the
       result of this conformance provision to be useful tools
       that are not interoperable. I think we would still lose.
       Analogous to question in AUGL WG about accessibility of
       AU Tools. I think this proposal is a step forward.
       I want to emphasize that a stand-alone UA is not sufficient
       to solve the problem of ensuring an accessible Web.

   KB: I like removing the distinction between desktop and dependent
       UA. Like Ian, I'm concerned about removing the complete
       requirement of interoperability.

   JG: The checkpoints in Guideline 6 (on communication) refer to
       standards and conventions (except for DOM) that are not
       W3C Recommendations. 

   MN: I don't understand "interoperability". I don't want a tool
       to be able to confirm if it doesn't conform to published
       guidelines for software accessibility.

   JG: I like in this proposal that it is forward-looking for
       new technologies (e.g., voice input/output).
 
   AG: This is related to mobile platforms - it makes sense for
       desktop computers to have extensibility requirements. But
       not as much for a mobile device. It's not so much that the
       tool interacts with the Web. But is it running in a context
       where extension is a natural requirement.

   MK: If you're afraid people won't conform, you can do something
       at the icon level.

   IJ: But we would still need to agree on the split.
 
  No consensus. Please review and comment on the list. This will be
  on the agenda again next week.

3) Issue #90: UA and AU dependency list (KB and JA proposals)
   http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#90 

   CMN: Those comments are more about when AU will review UA in
        last call rather than vice-versa. But is there something
        we need to do to the UA guidelines to meet requirements
        of UAGL.

    AG: E.g., UAGL wants to do hierarchical navigation. An
        extremely useful thing for AU tools to do is to display
        the hierarchical structure. This would expose the
        author to the concepts of hierarchical blocks. (e.g.,
        in a related power toy). 
   
    MR: The second half of Kitch's message goes in that direction.

   CMN: Yes. The Authoring Tool GL approach is to refer to other
        documents rather than repeating that information. We're
        not going to include WCAG techniques, for example, since
        implementors must know those guidelines anyway. We've also
        tried to be general enough to not refer only to HTML
        or a particular image format or tool. Most popular tools
        used by professionals are really text editors without
        a WYSIWYG interface that give access to the source (e.g.,
        DreamWeaver, etc.) 
   
        In short, there's a big dependency on the UAGL. But the
        current approach is not to include specific checkpoints
        that match up exactly with checkpoints in other guidelines.

        The AUGL would love more review. But the UAGL review has
        already been good.

    JG: All my comments were sent to AU archives.

    IJ: Kitch, Jon, Jim, Ian have all commented. Perhaps all we
        need to make available to AUGL at some point is a statement
        from the Chair stating that the AUGL WG has responded to
        our comments.

    JG: Can UAGL review again during Proposed Recommendation?

   CMN: It's not exactly clear what a WG does when it's not 
        happy with the results of the last call. But the WG
        will track last call comments and show resolutions.

    AG: And Ian should track those for the UA Group.

  Resolved: This issue is considered closed. However, the 
            AUGL last call continues and comments are still
            welcome.
            
(Rich and Mark leave).
 
4) Issue #78 Review requirements for window spawning
   http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#78

   AG: Generic three levels of control:
     a) Lightest: When you spawn, alert the user. No control
     b) Middle: If you spawn, you ask the user to confirm.
     c) Most severe: Spawning inhibited.

   Ian had proposed (a) only in [1]
   [1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0212.html
   
   AG: People need to be able to follow the evolution. Need to be able
       to return to known context with back button. Spawning breaks
       this since you can't undo the window creation. Eyes-free users
       need to understand the information space. The difference
       between Ian's proposal and what I proposed [2] is no more than
P3.
       The user should be able to invoke a mode that requires
       confirmation.

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

   JG: If I were Chuck Oppermann, I would say that this problem is not
       one of user agents, but an operating system convention
       issue. Why is problem unique to browsers?

   AG: When it happens in the context of browsing, this is a violation
       of the contract with the user w.r.t. the Web content. Thus,
       even if implemented in the operating system, this is a UA
       requirement.
 
   GR: I recently proposed a checkpoint for forms. See Ian's 
       rewritten proposal [3]. Would it be helpful to write
       something similar for spawned windows?

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

   MK: What about history list of spawned windows?

   AG: You lose old history list thread.

  CMN: Håkon Lie proposed importing history into spawned windows. If
       you do this, do you respect the contract that Al refers to?
       My instinct is that you probably have.

   AG: You've improved usability, in my opinion, without invoking
       the additional levels of control.

  CMN: With Amaya, if you have a page that hasn't been saved, it
       opens the page in a new window. At the end of the day, I have
       a huge pile of excess windows. I throw them all away.

   KB: I've seen situations where users end up with two UAs
       unknowingly, going to a text editor, then returning and 
       being lost. (Window opened either by page or UA new window
       functionality.)

   Action GR: Write a proposal to address issues about spawned windows.

5) Issue #80 Make audio available as text.
   http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#80

  MR: In rationale of Guideline 1, I thought an additional example
      on output device independence. Example would meet needs of
      deaf users and output device independence. Take text from
      [3]:

     "And any output provided in audio should also be available in
      text since most alternative output mechanisms rely on the presence
      of system-drawn text on the screen."

  AG: Also add cross-reference to show sounds in techniques document.

  Resolved: ok.

  [3]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0083.html
  
6) Issue #81 Turn on/off audio descs.
   http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#81

   MR: Propose adding a one for auditory descriptions.

   IJ: Could combine as "auditory description" as we did below.

   AG: Might be better to keep separate for clarity.

   MR: Propose "alternative equivalent" track in place of
       "descriptive track". 

   MK: "Continuous equivalent".

   MR: So bring language more in line with SMIL accessibility Note.

   Resolved:

    a) Generalize 4.5 to continuous equivalents. (list each expected
       type).
    b) Apply this language to related checkpoints.

   Action Ian: Make these editorial changes about continuous equivs.


   MR: Note that SMIL 1.0 only allows people to turn off captions.
       Should have in SMIL 2.0 means to turn off auditory descs.

   IJ: I agree that design ideas about the future are good for
       the techniques.

   AG: In PF, we may not be seeing enough of this conversation.
       The PF charter requires us to send requirements to the
       SYMM Group.

  CMN: Some of that's in my court.

   Action MR: Working on SMIL techniques in addition to SMIL access
              note. Also, coordinate with Geoff Freed so that
              issue sufficiently addressed in PF.

7) Issue #82 Rendering image in a link when there's no alt.
   http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#82

   When images are turned off, how do you indicate the link?

   AG: The "altifier" tool does this. E.g., for a link to the
       same place on the same page, it steals the link text.

   Resolved (pending comments from Harvey): Add info to techniques
       document about this.
       
   Action Ian: Link to "altifier" from Techniques document.
               http://www.vorburger.ch/projects/alt/
              
               Link to ER tools page from techniques.
               http://www.w3.org/WAI/ER/existingtools.html

8) Issue #83 Split speech rendering checkpoints since
             different priorities.
   http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#83

   From Jim Thatcher:
        Speech volume/rate are priority 2 or 1, pitch and 
        gender are priority 3 (max), in my opinion.

   JG: Proposal to create several checkpoints. 

   MR: I agree with Rate/Volume Priority 1, Pitch/Gender Priority 3.

   GR: Sounds reasonable

   AG: Let's ask Kitch to investigate the pitch issue. May be P2
       for a small number of people.

   JG: Some people with head injuries are sensitive to 
       gender/pitch.
   
   GR: I'd support P2 for Pitch/Gender

   MR: If you're implementing synthetic speech anyway, these aren't
       much more.

   Resolved:
     a) Volume is P1
     b) Others P2.
 
9) Issue #84 Checkpoint on natural language applies to all UAs.
   http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#84 

   KB, IJ: Should apply to all user agents.

   AG: One argument is that supporting it in the visual environment
       is just supporting HTML 4.0. The severity of the accessibility
       issue goes up in the auditory scenario. It applies in all
       cases, however, just in terms of conformance to the HTML spec.

   KB: Is there some reason a mainstream UA would not want to do this?
 
   IJ: I delete email that arrives in the wrong character encoding.

  CMN: I don't, I go to a different tool.

  Resolved: Natural language checkpoint applies to all user agents.
      

13:33 ET Adjourned

Received on Wednesday, 22 September 1999 13:36:27 UTC