W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Raw minutes from 15 March 2001 UAWG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 15 Mar 2001 16:03:39 -0500
Message-ID: <3AB12E2B.4584B8EB@w3.org>
To: w3c-wai-ua@w3.org
15 March 2001 UA Guidelines Teleconference

Agenda announcement:

Reference document 9 March 2001 Guidelines:

Minutes of previous meeting 8 March:

Next meeting: 22 March teleconference:

 Ian Jacobs (chair, scribe), Gregory Rosmaita, Eric Hansen,
 Charles McCathieNevile, Tim Lacy, David Poehlman, Aaron Leventhal,
 Harvey Bingham, Denis Anson

Absent: Rich Schwerdtfeger

Regrets: Mickey Quenzer, Jon Gunderson, Jim Allan


0. Who has read the 9 March draft?
      Yes: None
Partially: IJ, CMN, EH, GR, DP
       No: TL

IJ: Has anyone found any show-stoppers?

/* No one has come across any show-stoppers in their partial
   review */


  All editorial issues with the current document should be sent to the
  list before 21 March. At the 22 March teleconference we expect to
  vote to return to last call.

1.Issue 466: What are the priority of the accessibility issues and
user agent minimum requirements for checkpoint 9.3

Question: Is there a real-world example of why it's necessary to turn
off automatic onFocus and onBlur triggering?

AL: I talked to one of the guys at work yesterday. He said the most
common uses: onFocus for selecting, onBlur for validation.

TL: I wrote some DHTML that implements a toolbar. It relies on onBlur
and onFocus to do rollovers (i.e., replace one GIF with another).

AL: Web designers usually do this for the pointing device.

IJ: I've heard rationale for doing things manually, but less for not
doing things automatically.

GR: Recall that navigation sequence changes when you turn off all
script supports.

IJ: If onFocus causes a change to the document such that you can't
activate the other handlers, then this would be a destructive case.

/* GR raises this email message from Al:

CMN: The form case (don't trigger on enter key) is a separate case, I

IJ: If you do a destructive onFocus manually, you still have to
undo the action. Is there a difference between undo after automatic
behavior and undo after manual behavior?

CMN: There is a difference: Auto behavior can make it hard to 
undo (e.g., chaining, refreshing pages).

CMN: There aren't enough people writing accessible pages to give
real-world examples of using focus/blur. If we are successful, then
perhaps we will need this requirement more than today. Perhaps it's
easier to have a general event trap and not exclude specify types of

AL: But I think that today the big issues are mouse overs and form

IJ: In the past, we've said that automatic behavior may be
disorienting, thus we've required configuration to suppress automatic

 * Automatic behavior can be disorienting.

AL: But we can't think of an example where this would happen.

CMN: When people include focus handlers, they have usually done a job
to make those handlers useful. One problem is that part of a page
changes, but the user is not aware of it.

AL: Screen reader gives you a review cursor.

CMN: I use a variety of browsers because a single one does not meet
all of my needs.

IJ: I don't think that there is a guarantee that if you can't prevent
auto-triggering, that access will be impossible. This is unlike form
submission, where you can't finish filling out the form.

CMN: But there are examples where onFocus causes, e.g., a list of
choices to be updated automatically. Every one of the different
players (author, user agent, authoring tool) can help solve the

GR: Another example: when I was trying to configure a computer online,
a lot of forms used magic links that appear when you do an
onFocus. There is assumption in authoring that you are using a
pointing device: if you navigate to a link that has appeared
dynamically, the rest of the page fails. In other words, the focus
and the pointing device establish context; not the focus alone.

CMN: Part of this is an authoring requirement. 

IJ: It seems like:
 1. This is not a widespread problem in practice.
 2. Not clear to me that automatic triggering is an accesibility
    problem that is a P1 problem.

CMN: Think of the structured navigation requirement in conjunction
with 9.3: You navigate around a "static" tree and fire at well.  The
P1 problem is that self-customizing content becomes inaccessible.

/* Denis joins the call */

AL: I'd like to satisfy this requirement so that a screen reader could
do this, by letting the user zap mouse to focus (technique).

CMN: Blind users don't know what they've missed as they're navigating.

Rationale for P1:

 * Handlers may cause inaccessible changes to content.

Rationale for P2:

 * Not widespread in practice
 * People who write onFocus handlers may be aware of accessibility
 * This is a repair functionality if changes cause inaccessible content

IJ: It's hard for me to include a P1 requirement for extreme cases.

DP: How does this affect access to all content? Would you not fail 2.1?

IJ: Who can't live with it as a P2?

 * Make checkpoint 9.3 a P2 checkpoint.
IJ: Note that an objection will be strengthened by evidence that this
is widespread in practice.

2. Comments from Denis Anson:

IJ: Any statements the WG needs to review here?


* In section 1.1: change "support authoring practices" to 
  "addresses authoring practices."

* Checkpoints 1.1 and 1.3: The way I read these, it's not
  clear you always have to do the keyboard.

  CMN: I want to see 1.1 say: you have to do the keyboard.
       I want to see a new 1.2/1.3 with input modality labels.

  IJ: I don't think you need a label if it only appears once.
      This is why it's different than content type labels.

  EH: Even a set of one, for the sake of consistency, to use a label.
  DA: I agree that it sounds contradictory to say "you have do to
      this but you don't have to."

 CMN: I have two parts to what I'd like to see:
  * Split 1.1 into two different checkpoints (you get
    a sense of two classes of requirements.)

 IJ: The input labels are conformance labels. The content type
     labels are next to the checkpoint labels for convenience

 IJ: All the checkpoints are accessibility requirements, not
     conformance requirements.

Resolved: (this is issue 465)
 * Split 1.1 into two checkpoints.
 * Add to introduction of Section 2 that content type
   labels after checkpoints are for convenience only.
 * Include an example of evaluting a browser for

CMN: If I'm not satisfied with the wording, I'll send
a new proposal.


 * For checkpoint 2.2, move text format requirement from 
   the note to the checkpoint.
 * Make clearer the "additional bonus should" of the Note.

DA: In checkpoint 2.3, why not have notification to AT that something
is there and unrendered?

IJ: The checkpoint says "alerts the user" as well.

/* No change */

DA: 2.4: Does this include the condition where there are embedded
links inside a QuickTime movie, for example, that allow a user to
further explore building shown in the movie? 

/* The WG thinks that Denis' example is covered by 2.4 */

DA: I'm not sure what this checkpoint means. 

Action IJ: 
 * Work on editorial changes to 2.9
 * Include an example (e.g., "alt" for IMG in HTML).

DA: Checkpoint 3.1: What about condition where you have a table with a
background image?

IJ: That's a chosen limitation of this document.

Action IJ:
 * Add to the beginning of the document (limitations)
   that 3.1 doesn't cover layers.

DA: What if text is bigger than the space alloted for the
    scrolling area?

CMN: You have to come up with some solution. It might be that you
re-render the content. It's the same as when you fire up a page
without images that chop off alt content.

IJ: The unblinking text doesn't have to be in context.

Action IJ:

 * Add to the techniques document that it's ok to render
   the unblinking text not in context.

DA: Checkpoint 3.5: How do I get content after I said no?

DP: Manual refresh is ok.

IJ: By saying no, you may miss some content. But I don't
think we are asking the UA to save 600 versions of a page.

CMN: There is an essential limitation that we can't stop the external

DA: This is like frame-dropping.

/* No change */

DA: Checkpoint 3.7: [SUBSTANTIVE]. When you do this, there should be
an option that when I render "this image" it dismissive the previous
image. Too many images are two many images, whether they all appear at
once or serially one after the other.

IJ: One way to achieve this is to reload the page with images turned
off. We already discussed this and decided that toggling back off was
not considered a requirement.

/* EH leaves */

DA: I think it is, though. I worked with a guy who could hold 5 cards
in his hand, but couldn't hold 6 (he started playing as though he had
9 cards). You need a way to resimplify the page.

IJ: Why so burdensome to turn all images off?

DA: This is burdensome for someone with a cognitive disability.

IJ: This would apply to 3.2 as well (same reasoning: turning on video
and animated images).

AL: Implementation note: Netscape 6 or any Mozilla lets users turn
toggle images on/off on a per-image basis.

DP: I often browse without images turned on. When I'm working with a
sighted user, they often want to view images individually without
having to turn them on globally.

CMN: I do this in Lynx - run Lynx and view images one at a time.

DA: It would also satisfy the user requirement to show an image
temporarily and when you're done, make it disappear.

Action IJ:

 * Add to techniques to show images "temporarily" and when you
   leave the image, it goes away.

DA Proposal: Add toggle-off requirement to 3.2/3.7.

Action IJ: Write a proposal for what the new wording might be
for these checkpoints.

No resolution for now.

Proposals from Ian:

Proposal from IJ to delete 1.2:

 * Delete 1.2 and
 * Make it clear that 1.1 (or sons of 1.1) cover
   both content and UI.

Action Item Summary
Completed Action Items

3.IJ: Propose text for how other documents should reference UAAG 1.0
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
  Done in 9 March draft.

4.IJ: Distinguish techniques for fast forward versus faster palying 
(digital talking books), and point to digital talking books
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes

9.JG: Write a proposal related to the expected actions as the result of 
triggering events associated with the focused element.
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes
  Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0408
Open Action Items

1.IJ: Coordinate usability testing of the guidelines (JRG volunteers to 
be one of the testers).

2.IJ: Write an executive summary appendix.


5.IJ: Add a Note to checkpoint 4.4.pointing to applicability provision 
about streaming and whether slow/etc.control enabled by the format.
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes

6.IJ: Take to the cross-WG WAI list the issue of how to refer to UAAG 
(or other WAI specs) in non-W3C documents

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

8.JG: Create issue list for things that need to be addressed in the 
next version of the document

10.JG: Take to WAI PF the requirement that formats need to provide a 
more precise means for specifying events (than HTML allows for).
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes

11.JG: Create a wish list of other requirements not in UAAG 1.0, 
including those that might fall under this Guideline.
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes

12.JG: Write up some techniques for checkpoints on scripts on/off about 
subsetting the configuration.
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes

13.JG: Take to the WAI CG the question ofpursuing the DOM Views and 
Formatting module.
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes

14.JG: Call Cindy King about formats that support separate windows for 
captioning information
  Source: http://www.w3.org/WAI/UA/2001/03/ua-minutes

15.GL and TL: Ask someone from Microsoft whether they will evaluate the 
guidelines with a product.
  Deadline: 2/1/2001

16.CMN: Find out from SYMM WG whether repositioning of objects will 
appear in the spec (or should be in UAAG).

17.TL: Report to WG on discussions at Microsoft about keyboard

18.RS: Send pointer to information about universal access gateway to the

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 15 March 2001 16:03:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:38 GMT