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

Raw minutes of 14 December 2000 UAAG WG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 14 Dec 2000 16:14:35 -0500
Message-ID: <3A39383B.C83703C1@w3.org>
To: w3c-wai-ua@w3.org
Minutes of previous meeting 7 December:
Next meeting: 21 December 2000

   Jon Gunderson, Ian Jacobs (scribe), Mickey Quenzer, 
   Harvey Bingham, David Poehlman, Gregory Rosmaita, 
   Eric Hansen, Jim Allan, Rich Schwerdtfeger, Tim Lacy

   Kitch Barnicle

   Charles McCathieNevile


Upcoming meeting schedule:

   19 December: No meeting
   21 December: 
       Regrets: JA, HB, EH
   28 December: No meeting
    2 January : No meeting
    4 January : Regular meeting
    1-2 March : Face-to-face in Boston

 2.W3C representatives respond to WAI requirement documents
   JG: Please have AC reps review WAI Activity Proposal.

 3.Glosary group formed in WCAG

 4. MQ: I will be leaving isSound at the end of the month.
    IJ: You are still invited to attend the calls!


1.Issue #405: Checkpoint 4.17: Need stronger requirement to distinguish 

Refer to result of JG's proposals.

IJ: Why is the last sentence necessary? I think that the only reason
conflict arises is due to user. I think that warning the user that
they have chosen settings that might conflict. But there's a big
processing hit to require special treatment. 

EH: Doesn't seem like a P1 requirement to give people a heads-up that
there's a risk of one hiding the other.


1) Adopt:

   4.17 Allow the user to configure how the content focus and current
   selection are highlighted (e.g., through foreground and background
   color, voice pitch, etc.). The default highlight styles must not
   rely on color alone. The default focus and selection styles must
   also differ from each other, and not through color alone. If text
   decorations (e.g., underlining, strike through, over-line, etc.) or
   border styles are used as a highlight mechanism, the user must be
   able to configure them according to the range of text decoration or
   border styles available on the system. 

2) Delete 4.16.

3) Include in techniques:

   - Heads-up for the case when an element has both 
     selection and focus, and there exists a
     conflict between styling (i.e., color, border style, text
     decoration). They should be distinguishable.
   - Perhaps warn the user when they configure styling that
     there's a risk of conflict.

2.Issue #406: Checkpoint 4.18: Lower to Priority 3

JG Summarizing: The point of the reviewer is that if the user
can navigate back, then just an annoyance.

RS: That's true unless they use a system modal dialog box. That grabs
focus and doesn't release it. In that case, you may not be able to
switch back.

IJ: What happens if 4 windows open? Then it's a serious problem.

GR: If focus changes and you are unaware that it has changed, you may
enter data in a form without realizing it, for example.

JA: Or accept something that you didn't want to accept.

RS: But the AT should announce the new window.

JG: But there may be a delay before the AT can respond.

MQ: I think that the reason that this is an accessibility issue is
that the change of focus is very disorienting. The other issue is a
user interface issue that everyone has to face.

GR: This topic is also being discussed in the ATAG WG because of
prompts they discuss.

JG: Note that ATs receive information about windows that have opened
even if they haven't received focus. They can announce to user at a
later time. 

RS: But for the same reason you don't want to be interrupted,
the AT won't tell you.

IJ: What do ATs do today when a new window opens?

TL: Three ways ATs get information from IE:
a) They can track GDI calls
b) They can read the DOM
c) They can read the MSAA. So if IE opens a window, these
events go in the message queue that the AT is presumed to listen to.

JG: So if a browser doesn't give focus, does MSAA still give the 
information to the AT?

TL: Yes.

RS: The situation is not cut-and-dry.

TL: To do an interesting experiment, use outlook and set a bunch
of appointments at the same time. Watch what happens...

  - Due to orientation issue, this should remain a P2.

3.Issue #407: Checkpoint 4.20: Include requirement to control automatic 
closing of viewports

JG: Are disappearing windows more of a problem for people with

GR: If you can see the window close, you know that it closes. 

IJ: Does MSAA indicate that a window has closed?

TL: Yes.

GR: The only auto-closing windows I am aware of is opened when you get
streamed media. A popup shows an ad, then closes when the streaming
media arrives.

DP: Do we want to add a requirement we don't have implementation
experience for?

TL: It is possible to close windows with javascript. 

DP: IE does this today and handles this well. For spawned windows,
IE will prompt before some windows closed.

TL: The bank that I do online banking with, when you click "log out",
it sends a message to the UA window. IE prompts before closing the

JG: Add? 
 Yes: GR, MQ, IJ, TL, JA, 

RS: I don't think we need this. I think it's overkill.

TL: Is this an authoring issue? There's a "close" method in the DOM.

JG: It is an authoring problem as well. But it's a common problem.

RS: My concern is that if we add a new requirement, we will have to
go back to last call again. 

RS: I don't think this is a widespread accessibility problem.

 - Accept reviewer's proposal as a P3 requirement:
      Allow configuration to not close windows except 
      with user confirmation.
 - Evaluate later if we want to raise the priority.

Action IJ: Add a checkpoint.

4.Issue #408: Checkpoint 4.20: Allow configuration to prompt to open, 
not force manual open.

JG: Manually includes responding "yes" to a prompt.

 - Editorial. 
Action IJ: Add a clarification.

5.Issue #409: Checkpoint 4.20: If frames are not opened, what is result?

IJ: A viewport may contain others. I think we are only concerned with
the toplevel viewport.

GR: But they are subject to everything else (e.g., access to content).

IJ: Recall - this checkpoint for cognitive and physical (due to
navigation). What's the impact in the case of frames? I don't really
think there's much of a difference between a new frame or a new window
from the user's perspective. But it does feel different.

JG: What if the frame doesn't look like one?

IJ: Still an issue for navigation.

GR: What about inline frames?


 - Narrow focus of checkpoint to only apply to a top-level 
   viewport of a tree of viewports.

IJ: I don't see any distinction between frames and windows.

TL: Technically, prior to IE5, frames were in their own windows.
Yes, they pose the same problem. I think that how they are turned
off is more of an authoring issue.

/* TL leaves */

 - Add last sentence: "If a viewport includes other 
   viewports, then this requirement only applies to the topmost
 - Add a Note that other requirements still apply to sub-viewports.

Action IJ: Add these.

/* RS leaves */

6.Issue #410: Checkpoint 4.21: Is this redundant to 4.20?


 - Delete second sentence of 4.21 since redundant with 4.20.

Action IJ: Delete sentence from 4.21.

7.Issue #411: Checkpoint 4.21: Not just for GUIs but for any interface 
with overlapping viewports


 - Definition of "graphical" already includes text-based.
 - Add to end of first sentence "with which it overlaps".

Action IJ: Add text to 4.21.

8.Issue #412: Checkpoint 5.8: Editorial association between first and 
second sentences.


 - Add "that benefit accessibility" to end of second sentence.

Action IJ: Add text to 5.8
EH: We could also try to combine the sentences.

9.Issue #413: Checkpoint 6.2: Does this only apply to content?

Resolved: No change.
 - We agree, this is only for content.
 - The checkpoint is in a section on checkpoints for content.
 - Even covered in checklist.

10.Issue #414: Checkpoint 7.3: Need stronger min requirements


 - No change for now. Given our current priority definition and
   our current interpretation of it, it would still be possible
   to access all content.

Action JG: Contact Greg Lowney and ask for a counter-proposal
about minimal requirement.

Action Items

JG: Talk to Cindy King about captioning

JG: Write a proposal to the WG this week for a checkpoint about
    focus from selection all the time

  IJ: Note that there are some issues with this proposal.

AG: Send a reply to Phill related to issue 362

JA: Review SMIL players to find out which ones support positioning of

 JA: Thanks to Goeff Freeed at WGBH, I found ONE!
  Quicktime Pro ($40) - the user, through the use of an initial dialog
  can drag all visible tracks anywhere in the player window. However,
you must
  download movie first, then you can manipulate the visible tracks.
  But not for streaming video.


IJ: Ask Jason White for CSS implementation information for emacspeak
  IJ: I dropped because I got info from T.V. Raman instead.


WG: look for user agents that implement mouse events like mouse over
the keyboard.

IJ: Follow up with Greg Lowney on issue 389

IJ: (Issue 387) Propose new wording for check point 8.4 reflecting 
discussion on 28 November

IJ: Publish new implementation report for the meeting

IJ: Improve wording of note for 4.14 related to CSS reference

IJ, EH, AG: Propose new definitions forterms in question (equivalence,
element, etc.)

IJ: Draft new language for 6.2

IJ: Get wording from Martin for thisrequirement (e.g., "conform", 
"implement", etc.) for issue 327

IJ: Propose new checkpoints to see how it feels to harmonize the 
requirements related to comments in issue 348.

IJ: Propose new checkpoints/modifiedcheckpoints for 8.2.

IJ: Add some more explanation about the difference between 7.3 and 7.4.

IJ: Proposed fixed wording for 7.5

IJ: Add to techniques a link to Adobe's accessible PDF information.
IJ and AG: Revise the applicability provision and send to WG.

IJ: Ask Adobe why this is hard (issue 382)

IJ: 1.4 needs to be re-written in light of changes in checkpoint 1.1.

IJ: Proposed text in 2.1

IJ: Add a note to 5.8 - content requirements may also apply to user

IJ: Mention that resizing and overiding absolute values is part of some 
specification in section 1.2

IJ: Clarify the meaning of system colors

a) clarify "recognize style" in checkpoints 4.5
b) need more rational - refer to WCAG - style less important than other
c) add note 4.5 - give example of multimedia content that can be
as style

IJ: Add technique to checkpoint 4.12 to make clear that:
- This includes author-override if speech engine allows.
- This includes whatever granularity offered by speech engine.

IJ: Add a clarifying note to 4.11 that if you allow independent control
all sources of audio, you satisfy the checkpoint as well.

JG: Implementation information for guideline 2

JG: Propose a list of things we areexpecting UAs to recognize in

JG: Schedule face-to-face time with other WGs

JG: Propose text for the techniques document about synthesized speech 
implementation issues. Notably UA and AT wanting to use the same 
synthesizer engine.

GR: Review checkpoints in Guideline 10 for implementation information

GR: Talk to Håkon about CSS support.

GR: Talk to AFB about captioning and positioning

JA: Review checkpoints in Guideline 4 for implementation information

MQ: Send more details about control of speech parameters for the
document based on OpenBook.

KB: Submit technique on providing information on current item and number
items in search

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

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