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

Raw minutes from 10 August 2000 UA Guidelines teleconf.

From: Ian Jacobs <ij@w3.org>
Date: Thu, 10 Aug 2000 16:03:40 -0400
Message-ID: <39930A9C.6A43B10@w3.org>
To: w3c-wai-ua@w3.org
10 August 2000 UA Guidelines Teleconference

 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 David Poehlman
 Kitch Barnicle 
 Charles McCathieNevile
 Harvey Bingham
 Mickey Quenzer
 Eric Hansen

 Dick Brown
 Tim Lacy
 Rich Schwerdtfeger
 Gregory Rosmaita

 Mark Novak
 Jim Allan

Next meeting: 17 August
Minutes of previous meeting:


0) Discussion of face-to-face possibilities?

   JG: AOL? For early December?
   CMN: Talk of an ER/PF meeting in conjunction with XML 2000 in Wash
        DC in early December.
   DP: What about Freedom Scientific?
   CMN: May not be W3C Members.
   CMN: Adobe produced an SVG plug-in and the acrobat player. They 
   may be interested.
   Action IJ: Talk to Judy about ftf possibilities.
   (The WG should send ideas to the list.)

1) Pretty Easy:

PR#305: What is definition of "stalled"

  Refer to proposal from Ian:

  HB: I'm still concerned that the proportion information doesn't
  tell you everything (since request not recursive).

  JG: What's the accessibility issue here? Isn't this part of 1.5
     (i.e., the message has to be accessible through the UA).

  JG: Is this information important to ATs? I propose that we delete
  9.4 since there doesn't seem to be an accessibility issue.

  CMN: I agree with JG, this is a modality issue and not an
  accessibility issue per se. If your UA says you're half way there,
  it should say so to everyone.

  IJ: Is it an accessibility issue if someone doesn't have all the
  content in the UA? Or is this just a usability issue?

  HB: I think that it's a problem for everyone and it's how you
  inform the user that matters.

   1) Delete 9.4 since the WG cannot identify the accessibility
      issue other than how notification occurs.
   2) Move 9.4 information to checkpoint 1.5 Techniques.

2) More substantial:

PR#291: Checkpoint 4.16: A Guidelines conflict: 
        All content versus Limited Viewports

Refer to proposal from Ian

JG: What about just opening viewports minimized?
IJ: Is this for graphical viewports only?
CMN: Seven windows all maximized cause usability problems. 
The other issue is when you start going back through the history,
and it stops for no apparent reason. Håkon Lie suggested that a
child window inherit its parent's history. 
IJ: Another issue : serial tabbing through windows when there are a
lot of them.
IJ: Another issue: how do you identify which content you're viewing
when you (a) navigate to a viewport? (b) navigate back in the history?

JG: The primary accessibility issue that we've considered for this
checkpoint is graphical clutter.

IJ: I think that issues surrounding number of viewports are:
a) Graphical clutter: 
b) Number of viewports and navigation (strain of serial navigation)
c) Number of viewports and orientation (where am I?)

IJ: And so minimization would not meet b and c.

/* David leaves */
/* Mickey joins */

IJ: Who thinks that clutter and number are both accessibility
issues: KB, HB, IJ, CMN, JB.

IJ: I think that viewport title (where am I) is covered by 2.1.

IJ: I could see either two checkpoints, each with different
rationale, or one checkpoint with a,b,c rationale in a Note.
For example:

4.17a) Allow users to configure the UA so that newly opened windows
do not obscure the window with focus (e.g., open minimized, open
behind, etc.).

4.17b) Allow the user to configure the user agent to only
open viewports on explicit user request. For a viewport
that the user agent does not open automatically, 
notify the user and allow the user to open the viewport
manually. Allow users to close viewports.
[And satisfying this would also meet the previous one.]

 - Create two P2 checkpoints, one related to graphical
   clutter (graphical viewports),  
   one related to number of viewports.
 - Explain that satisfying the latter will satsify the 
   former as well.
 - Techniques for former: minimization, open new windows behind.
 - These only apply for viewports that open without explicit
   requests to open from the user.

KB: What constitutes and explicit request from the user to
open a viewport?

CMN: Opening something in a new viewport. An alternative
technique is that for any viewport that will open, the UA
prompts the user to confirm the opening (or opening new
content in the same viewport).

IJ: We could say "or acknowledgment" in addition to "on request"
to capture the second technique. We should try to eliminate
the issue of "what constitutes an explicit request" by adopting
Charles' approach.

CMN: Leave wording as is. Put in techniques that the user agent
would meet this by asking the user for cases where the user
hasn't asked explicitly.

Action IJ: Repropose two checkpoints.

PR#294: Native support and downloadable modules

IJ: This is a conformance issue. Refer to CMN's comments 
    about making conformance claims more flexible.

Refer to IJ discussion points:

JG: Do we need a requirement that features be integrated into
    new releases.

/* Discussion of conformance of software on its own or in tandem. */

IJ: I don't want UA developers to be required to claim conformance
with other software. That's different from UA developers (or whoever)
being able to claim conformance of 3 pieces of software together.

CMN: It's good for users to know that there is software that is
Level Triple-A compliant when you combine modules and plug-ins and
somebody's special script. Also, software is modular, so where do
you draw the line? I don't see why to draw the line at a given
company. The idea is that you make a claim for a set of modules,
and that should be ok. 

KB: It makes me nervous if you have to add extra modules.

IJ: The following are distinct:

a) Claims (which are a good thing for users to know what
   software is accessible in tandem).
b) What must be accessible by default? (Do we want to
   require that some piece of software be accessible without
   additional modules?)

/* Eric joins */

IJ: We already make assumptions about the availability of
assistive technologies?

JG: Why aren't these modules part of the main UA release?

CMN: It is good to provide service packs to fix bugs.

EH: It really depends on how expansively you define "installation".
Suppose someone gave you a floppy disk and said "This is a
conforming UA." You install the core from the floppy and
part of the installation involves getting things from the Web.
If, when you're done installing, what you have conforms, it
conforms, regardless of where the information comes from.

Refer to IJ comments about installation:

JG: Why is this different from saying "here's a curb, there's
a ramp in the closet"?

CMN: The differences:

a) You can't get to the closet in your case.
b) You know in advance that the curb is inaccessible.
c) Browsers aren't like curbs. There's only one "street", but
   there's no requirement that you have to use one browser and
   have no other choice of software.

CMN: A big advantage of allowing add-ons is that you can
fix browsers today. And of course, you want them to integrate
features completely. 

EH: One possibility:
a) If a conformance claim is made that requires a procedure
(e.g., installation), the claim needs to include parameters
of the procedure. You need to document what needs to be
done to achieve conformance. 

IJ: Documentation may be distributed.

IJ: The question is: how much accessibility by default, out
of the box?

EH: What about a base-level claim? 

IJ: We have a set of requirements of how to make a claim, should
you choose to do one.

EH: I think that documenting the installation demands is important.

No resolution.
Action IJ: Summarize the discussion.

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

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