Raw minutes from 5 January UA Working Group teleconf

WAI UAGL Teleconference
5 January 1999

Participants:

Jon Gunderson
Ian Jacobs
Dick Brown
Denis Anson
Harvey Bingham
Mickey Quezner
Jim Allan
Gregory Rosmaita
Rich Schwertdfeger

Regrets:
David Poehlman
Kitch Barnicle

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

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

1) Review Open Action Items

   1.JG: Review techniques for Guideline 8.3 to 8.9 
  
   Status 8.3/8.4: Cancelled, though JG may check into Opera
capabilities.

   GR: Refer to my evaluation of Opera 
       http://www.w3.org/WAI/UA/1999/09/uagl-hal95-19990906.html

   Status 8.5: Done
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0011.html

   2.JG: Draft a preliminary implementation report for CR
         consideration 

   Status: Not done.

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

   Status: Pending.

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

   Status: Pending. I've asked an MSAA developer for this information.
           See thread from Jim Allan and Ian Jacobs.

   DA: There's information at the IE site on this:
       http://www.microsoft.com/enable/dev/guidelines/software.htm
   (Follow Section 1)

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

   Status: No info.

   6.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
         this will work with ATs. 

   Status: Not done. Will ask RS a question offline.

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

   Status: May already be integrated.

   8.GR: Run LPPlayer through the guidelines. Verify with Productivity
         Works. 

   Status: Pending. Talked with both Ray and Mark. He'd prefer that the
           analysis be done internally by Productivity Works. They
           would contribute an evaluation. GR will keep us in the loop
           on this.

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

   Status: No info.

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

   Status: No info.

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

   Status: No info.

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

    Status: Mark is still travelling.

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

    Status: Not done. Ian reminded her today.

  14.IJ: Refer to 
        
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0758.html

    Still todo:

    a) Propose a technique for using XSL to transform content

    b) 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)

2) Announcements 

   1.New UA weekly scheduled telecon (tommorrow) 6 January 2000 at 2:00
pm
     to 3:30 pm Eastern Standard Time, USA
     http://www.w3.org/WAI/UA/2000/01/wai-ua-telecon-20000106.html 

   2.Protocols and Formatting are holding a FTF meeting on 26-27 January
     2000 at Sun's Microsystem in Cupertino - Silicon Valley
     http://www.w3.org/WAI/PF/Group/2000/01/agenda.htm 

3) Discussion 

   1.Candidate recommendation 

    JG: Henter-Joyce is implementing their own DOM-like API.
    RS: IBM is looking at DOM for HPR.
    JG: Work at CAST in their e-text reader also involves DOM.
    MQ: I'll ask Mark if PWWebSpeak is using the DOM. JG will email
        as well.

    IJ: To get to CR: 
     a) Resolve outstanding issues.
     b) Prepare an implementation report
     c) Schedule a meeting with the director.
     d) Target start date: 14 January.
     e) Target duration: will be determined based on implementation
                         report, but if DOM implementations are
                         working, then starting point would be
                         one month.

4) Ian's proposal for "UA Responsibilities"
   http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0755.html

  IJ: Goals:

   a) Is this useful?
   b) What's missing?
   c) How to resolve remaining ones?

  DA: I think "AT" definition is too fuzzy. I think that AT's provides
      functionality for which an able-bodied user doesn't require extra
      software. Not necessarily a plug-in, may be a wrap-around. 

      Some things that are conveniences for an able-bodied person
     (e.g., TV Remote control) are not just conveniences for someone
     with a disability because they don't have another way to do it.
     This may comprise the group of requirements that should be
     built-in natively to the desktop user agent.

  DB: This document is useful for developers as well as for "critics"
     of the guidelines.

  Action IJ: Publish a new draft that incorporates JG's comments.

  DA: Some of the "Apply to all user agents" are actually "Apply
      to all applications". I suggest creating a "Requirements
      for all software" category. And these shouldn't be native but
      in the OS.

  Action DA: Identify the general ones from the list.

  Action EVERYONE: Review the "Unknown" category and we'll discuss them
             at tomorrow's meeting.

  Action RS: Send editorial comments.
   

5) Issues

   2.LC#156: Propose change in priority of 5.6 (P1 -> P2) 
     http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#156 

   JG: Håkon Wium Lee thinks DOM should be P2, since it turns a 
       browser into an editor.
   
   Some ideas:

    a) Change to P2 as HWL suggests.

    b) Change to P2 for write access.
       RS: You can't fill out a form this way.

    c) Change requirement to be more general 
       (as we did for UI access).

    d) Leave P1.

   JG: I'm not sure that physical memory concerns is an issue.
       In the past, we haven't made human resource limitations
       a criterion.

   DA: The DOM is a special case. We're not talking about
       functionality here, but implementation.
  
   JG: We've talked about this and since the DOM is
       platform-independent and vendor neutral, we felt is
       was necessary for interoperability.

   HB: We may not be able to paste into the DOM something
       that is an audio source. The error control process has
       to be invoked to ensure validity.

   DA: I don't think this is a big issue. Speech input is a
       wrap-around technology converted to movement or keyboard
       input. 

   /* DB and JG leave */

   GR: My concern is time lag to implementation by ATs.
       People are looking to these Guidelines for quick
       improvement to the Web experience (say, a year).
       I think that we should send the "UA Responsibilities"
       document to reviewers of the document so we can
       "show them the money". (Add this concern to the "UA
       Responsibilities doc?)

   DA: I think the time lag issue is valid for *any* standard
       we would promote. Therefore, we can "arbitrarily" choose
       the DOM.

   IJ: Sounds like a FAQ: "When will browsers be accessible?"

   Resolved:
       1) Leave P1 for reasons of interoperability and requirement
          for write access. 
 
   3.LC#158: Propose priority change (1 to 2) for checkpoint 4.1
(control
             of font family) 
     http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#158 

     DA: I have a hard time arguing that it's P1. It is difficult,
         but not impossible.

     IJ: What about some ornate font family?

     DA: There are probably a few people for whom it's gibberish.
         But if you don't have the appropriate font on your computer,
         your browser will choose another anyway.

     GR: Important for low vision and cognitive. But my gut feeling
         is P2.

     JA: You can always find a font family that makes it impossible
         for someone to read the text. Take wingdings, for example.
         There may be font families that are easier or less easy
         to read.

     DA: There are inefficient ways, but not impossible ways, to
         read the text (e.g., cut and paste)

   Resolved:
       1) Change to P2.
       2) Action Ian: Send this resolution to the list for comment.

   4.LC#159: Propose raise priority of 4.13 to Priority 1 
     http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#159 

   DA: I think start and stop (video, audio, animation) is P1.
       "Start" means "start from the beginning".

   IJ: You can restart from the beginning by reloading the page.
       Why is it P1 to stop?

   DA: It may be distracting you from other things on the page.

   JA: I've visited sites where audio was rendered and you couldn't
       stop it; different audio clips overlapped.

   DA: I don't think that slow compensates for pause. Pause should
       be P1 as well.

   HB: If you're working an audio or braille stream that is pouring
       out and synchronized with other content, you need to change
       the rate of the audio controls and stay synchronized.

   IJ: Pause isn't P1 - you still have access to the content;
       you can start from the beginning.

   DA/GR: Lack of pause may make access to content impossible for
       some users with disabilities. If they don't have time to
       stop and are forced to start again, they will never get
       to the end of the content.

   Resolved:
       1) Move "start, stop, pause, rewind, advance" to P1.

   5.LC#161: Raise priority of 8.8 to P2 (highlighting and identifying
             selection/focus) 
     http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#161 

   IJ: This checkpoint means "Let me know which elements are
       active".

   DA: Some users with cognitive disabilities  need this.

   JA: If the user can't find it, the function is not there. 

   Resolved:
       1) Raise to P2.

Received on Wednesday, 5 January 2000 13:49:38 UTC