Raw minutes from 21 June UAWG teleconference

21 June 2001 UA Guidelines Teleconference

Agenda announcement:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0258

Minutes of previous meeting 7 June:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0249

Present: Ian Jacobs (Chair), Mickey Quenzer, Harvey Bingham,
         David Poehlman, Tim Lacy

Regrets: Jon Gunderson, Jim Allan

Next meeting: 28 June
   Regrets from Harvey, Mickey for this meeting.

Reference document 4 June 2001 Guidelines:
 http://www.w3.org/WAI/UA/WD-UAAG10-20010604/

----------------------
Discussion
----------------------

1) Update on last call
  * Processing SVG WG comments. Should be done in a couple of weeks.
  * Next step: CR. Preparation - implementation report, goals of CR.

  Schedule banter:
     - Go to CR on 19 July.
     - Not sure about duration of CR (we have to show implementation
       of each feature in some piece of software).
     - Not clear what would happen if we dropped substantial
       requirements at a result of finding in CR that some pieces
       cannot be implemented.

2) Publication of revised UAAG 1.0 on TR page?
   Request from Ian:
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0257

Resolved:
   - Publish newer UAAG 1.0 (4 June draft) on TR page.

Action IJ: Request publication of newer UAAG 1.0 (4 June draft).

3) Face-to-face meeting in September

Possibly with other WAI WGs at Microsoft:

 - Sept 5, 6, 7, (Weds - Fri) 
 - Sept 10 - 14 (Mon - Fri)

TL: I'll be there. <grin>
IJ: Me too. I think no problem for either date at this time.
MQ: Me too. No date prefs.
DP: Me too. No date prefs.
HB: Possible, can't promise.

Action IJ: Continue to keep WG informed of meeting plans.

HB: What are expectations for ftf?

IJ: We should be in the middle of CR.

4) Review of responses to SVG WG last call comments.
   Refer to document:
   http://www.w3.org/WAI/UA/2001/06/svg-lc  

IJ: General comment - applicability not understood. Since spec has
been split into pieces, it might be possible to move the conformance
section before the guidelines again. Or just put a brief explanation
of applicability up front.

For B.1: Add xml namespaces as an example of something that might not
         be recognized.

   TL: Analyzing a document for scripts is not an unreasonable
   burden. The analysis would be one API call. For IE, we build
   a number of trees. It is one API call to ask whether there's an
   element "foo" anywhere in this tree?

   IJ: They may have understood the requirement to be one alert per
   script element. We only require one alert, and the search can
   stop as soon as one is identified.

For B.2: Checkpoint 4.2: Control of font families burdensome in SVG

   IJ: I'm not sure what "fonts for graphics" means. We might need to
   clarify whether the SVG WG understands fonts to include "pictures
   of letters" (with no characters behind them). We may have to 
   state that we mean fonts as pictures/vectors that are applied to
   text characters.

For C.1: Too many Priority 1 checkpoints

   IJ: I'm not favorable to adding another level. It would be
   significant work (and fighting) that we've already done.

   MQ: Maybe we need to make clearer that the "Who Benefits"
   sections are there. We don't want to ignore certain groups 
   of users with disabilities. This would help explain why so
   many checkpoints. You might also point to the impact
   matrix from the introduction.

   Action IJ: 
    - Add a link to "How People with Disabilities use the
      Web" from the section on the impact matrix.
    - Add reference to this document even though it's not
      yet a note.

   Resolved: 
    - Do not increase granularity. Do not remove checkpoints.
      Do not lower priorities.

      Rationale: We have this many checkpoints to address
      cross-disability concerns. Who do you exclude?

      Were we to re-evaluate checkpoint priority, we would have to
      return to step one. We have spent years on the conformance
      model and establishing priorities.
   
    - Demonstrate implementability in CR.

   DP: A lot of the changes that the SVG WG is recommending
   are very sweeping. I am not sure that they understand
   the rationale for the development of UAAG 1.0.
   You might point them to "Hurdles of UA Guidelines"  
   http://www.w3.org/WAI/UA/2000/10/hurdles

   DP: Our process of developing the Guidelines has gone 
   through these questions a number of times (e.g., whether
   something should be a checkpoint).

/* Discussions of other paragraphs not minuted, as they were just
comments on the draft proposal. Ian is editing the draft proposal in
place. */

C.6: Don't require keyboard access for all functionalities (e.g., text
selection, region positioning)

  IJ: I wonder whether there's some exception that can be carved out
  here. There's some tight binding between input and output modes in
  the case of drawing. Can we capture this? Do we want to? 

  IJ: I have this sense that when a functionality is bound to a
  particular output mode (e.g., drawing is inherently visual), then
  our input mode requirements might be different. Why would we require
  input mode independence when a particular functionality depends
  on a single output mode?

  MQ: I want to be able to show people a set of slides, even though I
  may not be able to use the slides. There are blind people who can 
  visual what they're doing (e.g., drawing). 

  DP: I need to be able to teach my students how to use a drawing
  tool. I need to be able to say "This is how you change the brush
  width", even though I may not be able to see the results. Or I need
  to be able to document this functionality (if I work for a software
  company).

  DP: I may not be able to use a mouse, but I may not be blind. I may
  have a physical disability and be using a large keyboard.

  IJ: How do you answer the question: Some things, like drawing, are
  hard to do with the keyboard? I think the important distinction
  is between two-dimensional input and one-dimensional input.

IJ: It would be useful to distinguish three cases:

  - Direct access (i.e., spatially-independent) 
    required for some users, e.g., with blindness. In this case,
    keyboard shortcuts make the most sense.

  - Keyboard, not mouse, access required for other users (e.g.,
    using specialized input devices that make use of the keyboard
    API, or for whom moving arrow keys is easier than a mouse, for
    example). In this case, keyboard shortcuts are not as sensible.
    This is not to say that no drawing is easy to do with
    direct access; it's probably easy for well-known shapes, flipping
    them, enlarging them, etc. But for some other functionalities,
    such as free-hand drawing.

IJ:  MouseKeys may be the best solution for some functionalities, but
should not be relied on for all access (for those who cannot use
spatially-dependent input mechanisms).

DP: Another important issue is that APIs are important for alternative
input devices.

Action IJ: Clarify for 1.1. the difference between spatially-dependent
and independent access through the keyboard. We don't require all
functionalities be available in a spatially-independent manner. Where
possible, provide at least a spatially-independent input
mechanism. Access through the keyboard API will be useful to AT
developers.

----------------------
Action items (open)
----------------------

1.IJ: Coordinate usability testing of the guidelines (JRG volunteers to 
      be one of the testers).
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0137

5.RS: Send pointer to information about universal access gateway to the 
      WG.
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0258

6.GR: Review event checkpoints for techniques

7.GR: Rewrite different markup (list of elements) that 2.9 applies to, 
      for clarification.


-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 831 457-2842
Cell:                    +1 917 450-8783

Received on Thursday, 21 June 2001 16:20:49 UTC