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

MINUTES(edited): W3C WAI User Agent Telecon 19 April 2000

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Wed, 19 Apr 2000 17:48:57 -0500
Message-Id: <4.3.1.2.20000419174800.00c99470@staff.uiuc.edu>
To: w3c-wai-ua@w3.org
Attendance

Chair: Jon Gunderson

Scribe: Ian Jacobs

RSVP Present:
Madeleine Rothberg
Al Gilman
Mark Novak
Denis Anson Hans
Riesebos
Harvey Bingham
Al Gilman
Gregory Rosmaita

Regrets:
Rich Schwerdtfeger
Kitch Barnicle
Charles McCathieNevile
David Poehlman

Action Items

Open Action Items

    1.IJ: Draft a preliminary executive summary/mini-FAQ for developers. 
(No deadline.)
    2.IJ: Propose split to the list. Identify why and issue of priority.
    3.CMN: Propose a technique that explains how serialization plus 
navigation would suffice for Checkpoint 8.1.
    4.DA: Send name of new organization to list that was mentioned by some 
from the US Census Bureau
    5.DA: Review techniques for Guidelines 7 and 8
    6.DB: Get Tim Lacy to review G+
    7.DB: Review techniques for Guidelines 3, 4, and 11
    8.GR: Look into which checkpoints would benefit from audio examples in 
the techniques document.
    9.GR: Review techniques for Sections 3.7 and 3.8
   10.GR: Send to list screen shot of JFW Window list.
   11.MQ: Review techniques for Guidelines 9 and 10
   12.RS: Take notification of focus and view changes to PF as possible DOM 
3 requirement.

New Action Items

    1.IJ: Propose new 4.15 and 4.16 to list
    2.DA: Get confirmation that the numbers for checkpoint 4.5 make sense
    3.MR: Send URI to Micrsoft's implementation of synchronized audio/video 
slowing down to the list

Completed Action Items

    1.IJ: Propose three terms to the list: Document Source, Document Object 
and Rendered Content
      http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0132.html
    2.IJ: The content/ui division in G1 needs to be fixed
      Staus: Done locally.
    3.IJ: Resolutions from FTF meeting
      Status: All done, I believe.
    4.IJ: Adopt new wording of proposal for checkpoint 9.2
      Status: Done locally
    5.JG: Take conformance grandulatity issue to the WAI CG.
      Status: done, sent e-mail agenda item to CG
    6.JG: Identify the minimal requirement for each checkpoint.
      http://www.w3.org/WAI/UA/2000/04/min-req.html
    7.JG: Write email to the list asking for information about which user 
groups require the ability to slow down presentations othewise access it 
impossible.
      Status: dropped
    8.CMN: Find out from I18N how to generalize the accessibility provided 
by sans-serif fonts.
      http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0103.html
    9.DP: Review techniques for Guidelines 1 and 2
      http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0102.html
   10.HB: Take scoping issue of the current guidelines to the EO working group
      Status: EO confirms that they are doing the FAQ.



Minutes

1a) Completed

2.IJ: Propose three terms to the list: Document Source, Document Object and 
Rendered Content
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0132.html

3.IJ: The content/ui division in G1 needs to be fixed
IJ: Done locally.

4.IJ: Resolutions from FTF meeting
IJ: All done, I believe.

5.IJ: Adopt new wording of proposal for checkpoint 9.2
IJ: Done locally.

7.CMN: Find out from I18N how to generalize the accessibility provided by 
sans-serif fonts.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0103.html

13.DP: Review techniques for Guidelines 1 and 2
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0102.html

19.JG: Identify the minimal requirement for each checkpoint.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0128.html

20.HB: Take scoping issue of the current guidelines to the EO Working Group

HB: EO confirms that they are doing the FAQ.

18.JG: Take conformance grandularity issue to the WAI CG.

JG: Sent as an agenda item.

1b) Continued 1.

IJ: Draft a preliminary executive summary/mini-FAQ for developers. (No 
deadline.)

6.IJ: Propose split to the list. Identify why and issue of priority.

8.CMN: Propose a technique that explains how serialization plus navigation 
would suffice for Checkpoint 8.1.

9.DA: Send name of new organization to list that was mentioned by some 
person from the US Census Bureau

10.DA: Review techniques for Guidelines 7 and 8 11.

DB: Get Tim Lacy to review G+ 12.

DB: Review techniques for Guidelines 3, 4, and 11 14.

GR: Look into which checkpoints would benefit from audio examples in the 
techniques document.

15.GR: Review techniques for Sections 3.7 and 3.8

16. GR: Send to list screen shot of JFW Window list.

17.JG: Write email to the list asking for information about which user 
groups require the ability to slow down presentations othewise access it 
impossible.

21.MQ: Review techniques for Guidelines 9 and 10

22.RS: Take notification of focus and view changes to PF as possible DOM 3 
requirement.

2) Announcements

1. April 27th, WCAG Telecon will be discussing markup to provide navigation 
information to user agents

2. Notice of Proposed Rulemaking: Electronic and Information Technology 
Accessibility Standardsby the United States ARCHITECTURAL AND
TRANSPORTATION BARRIERS COMPLIANCE BOARD. Comments will be accepted until 
May 30th
http://www.access-board.gov/sec508/nprm.htm
http://www.access-board.gov/sec508/overview.htm

3) PR#224: Checkpoint 4.16: Minimal conformance requirement unclear

http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#224

JG: The only thing not covered is inheritance by viewports.

IJ: Does the presence of several viewports cause an accessibility problem?

DA: Some users with CD can only process a certain amount of visual 
information. One user could play card games, e.g., as long as there were no 
more than
four cards in his hand. If you have too many viewports, you may exceed the 
threshhold above which processing becomes impossible.

IJ: For me, the requirement becomes the ability to close, not the ability 
to prevent opening.

DA: If you have to close with looking, then it's still a problem.

GR: I don't want to have to do this by hand: I want to configure the UA. 
Also, I want to ensure that configurations are inherited and that focus is 
constant when a
viewport is duplicated.

JG: Sounds like minimal requirement is allowing the user to turn off any 
viewport that opens automatically.

IJ: Propose issues of opening in 4.15 and issues of number in 4.16. "Not 
opening" is a technique for controlling the number.

DA: You might also want a technique to limit the number.

IJ: Would being prompted cause you confusion? So is the technique we're 
suggestion appropriate for the users whose needs we're trying to address.

DA: Prompting might confuse, yes.

AG, JG: The proposed remedy would meet 4.16 as stated today.

DA: One technique: ignore "target=_new".

DA: Too much information is also a disorientation problem. But the cause of 
disorientation is different.

IJ: 4.16: Allow the user to configure the number of viewports open at one 
time.

DA: Techniques will be similar.

AG: I have a residual unhappiness - you're creating more requirements. I 
realize that the problems aren't the same, but if the minimal requirements 
are the same,
why not merge the checkpoints.

IJ: Minimal requirement for 4.15 is to prevent the focus from moving (and 
let the user change it by hand, by navigating to another viewport). For 
4.16, it's don't
open new windows and don't ask.

AG: "Just say no" is not sufficient. You also need prompting and "just do 
it normally". So three pieces to minimal requirement.

AG: I think that number of viewports is an issue for blind users, even if 
it's a lower priority for them.

Action IJ: Propose new 4.15 and 4.16 to list.

4) PR#244: Checkpoint 4.5: Change to P2 since no reference implementation.

http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#244

MR: Refer to my email: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0065.html

MR: Part of the difficulty is to avoid distorting pitch.

JG: Variable-speed tape recorders have been doing this since the 1950's.

AG: Yes, there are techniques for doing this, although I don't think that 
this has been done commercially as long as that.

JG: What's the range for slowing down? Half-speed?

HB: George Kerscher argued that below 80%, the audio becomes almost unusual.

DA: Most of the technology I'm aware of is about speeding up.

GR: Although many blind users speed up rendering, some users who are newly 
blind, or who have other disabilities, will need to slow down as well. GR: 
I don't
think slowing down needs to be symmetric with speeding up.

IJ: We can't pick numbers out of a hat. For any of these ranges, we need to 
do research.

JG: Note that 4.5 does not talk about speeding up since you still have 
access to content. Slower than you wish, perhaps, but you still have access.

HB: Then it's a P2 or P3 to speed up.

JG: You may not have to do pitch adjustment at 80% speed.

JG: What about for animations and video?

HB: Will you get "beating" phenomena in the visual field?

AG: I think it makes sense to split video and animation due to feasibility.

JG: We're not talking about compressing. We're talking about extending the 
time a frame is visible.

AG: You could do dithering. MR: I'm not aware of data on these needs.

DA: I would guess that for video or animation, half-speed would suffice.

MR: If there is audio that goes with the video, then those two need to be 
synchronized. The user needs to know that if they slow down the video more than
80%, that the audio may not be rendered.

JG: It would be acceptable to cut out the sound below 80%.

DA: Yes, a user could view the video without audio first , then replay 
faster with audio to get more information.

JG: - For video / animated: slow to at least 50%
- For audio: slow to at least 80% -
When synchronized: down to 80%, must synchronized, after that, audio can 
drop out.

HB: We don't need to specify a continuous range down to 50% or 80%.

Consider resolved for now (unless information contradicts our best guess):
1) Leave 4.5 a P1. (We have a reference implementation).
2) Specify minimal requirements for synchronization as stated above.

Action DA: Get confirmation that these numbers make sense.

Action MR: Send URI to MS's implementation to the list.

5) PR#262: Checkpoint 5.9: Change Priority since non-standard approaches 
may be better.

http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#262

Resolved: Keep same priority. Use wording below:

      5.9 Follow operating system conventions that affect accessibility. In 
particular, follow conventions for user interface design, keyboard 
configuration,
      product installation, and documentation. [Priority 2] Note. Operating 
system conventions that affect accessibility are those described in this
      document and in platform-specific accessibility guidelines. Some of 
these conventions (e.g., sticky keys, mouse keys, show sounds, etc.) are
      discussed in the Techniques document [UAAG10-TECHS].

6) PR#264: Checkpoint 3.9: Raise priority since may cause CD problems.

http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#264

IJ: I've sent email to reviewer, no reply. But it sounds, based on 
discussion today, that users with CD are affected. J

G: I sent email too: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0131.html DA: 
Yes, too much visual information can cause problems.

GR: Isn't there also an issue about spatial relationships between images 
and text?

DA: Yes, that's a possibility. With people barely able to take in the 
information, the switch between modalities (text/image) can be difficult. 
If you want to talk
about learning theory, you're dealing with different types of information. 
Research shows that transitions between modalities can be a very difficult 
task. I would
suggest that this be moved to a P2.

AG: Yes, flopping back and forth between modes. The lower challenge may be 
pure text or pure image. Images aren't bad, but complexity can be bad.

IJ: A change in priority would be a substantial change to the document. 
This is not a mere clarification to the document. Therefore, this change 
(and others of this
class), may cause us to cycle back.

AG: I think that it's at the Director's discretion to be able to make the 
call. The Chair should get consensus and take "the call" to the Director.

/* More discussion on the W3C process and how changes have an impact on 
moving to Recommendation */

DA: I don't think we should sacrifice accessibility for convenience. 
Resolved: Make 3.9 a P2 (due to impact on users with CD).

7) DOM 2 issue

/* IJ presents issue of DOM WG dealing with namespace issues and it being 
uncertain when they will move to Proposed Recommendation */

IJ: Options - Wait for them. - Drop to DOM 1. We lose namespace support and 
CSS module.

HR: What about open-ended requirement for DOM?

JG: We closed it off to make the spec tighter.

HB: I don't believe that any MS product conforms to DOM 1.

JG: MS people believe that they do.

IJ: Philippe has told me that IE's DOM is a superset of of W3C DOM Level 1, 
but has not confirmed that yet.

IJ: NN 6 claims full support for the DOM.

JG: How many people consider DOM 2 critical?

GR: I am leaning towards that position. I think 5.4 (CSS module) is important.

IJ: Please be prepared to wait at least 3 extra months.

GR: We might have to wait anyway if we recycle.

IJ: We should change our strategy if we recycle so that we can drop to DOM 
1 by default if DOM 2 not a PR after a certain point.

HR: I think DOM Level 2 important as well. The CSS module is useful (as is 
the events module).

DA: I think that going for accessibility would require going to DOM 2.

MR: I'm not informed enough about the DOM. AG: I still believe that we 
should put in an explicit implementation time out: say that you have to 
comply within 6
months (for example) of the document becoming a Rec. This is the ugly 
proposal.

HB: I would hate for our spec to have to wait 6 months. I'd rather put in 
words about DOM 1, and do what AG says.

IJ: I think we should move to DOM 1. You would get more accessibility 
sooner, then publish another UAAG later and not break conformance to UAAG 1.0.

JG: So it sounds like:

- The WG should resolve the other issues first and get a sense of the sum 
of changes.

- If we choose to recycle, we could try for DOM2.

- If we choose not to recycle, we might try DOM1 then produce a new REC 
with even more of DOM2 work later on.

JG: Would anyone object to going ahead with DOM1 and creating a new UA Rec 
when DOM2 becomes a Recommendation?

HR: I still prefer the solution of giving user agents a six-month lead time.

IJ: I think that an open-ended dependency on a document that doesn't yet 
exist or at least might change in unexpected ways, is dangerous.



Copyright    2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C 
liability, trademark, document use and software licensing rules apply. Your 
interactions with this site are in
accordance with our public and Member privacy statements.

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua
Received on Wednesday, 19 April 2000 18:49:06 GMT

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