- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Wed, 19 Apr 2000 17:48:57 -0500
- 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 UTC