- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 19 Apr 2000 15:44:52 -0400
- To: w3c-wai-ua@w3.org
WAI UA Teleconf
19 Apr 2000
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Denis Anson
Hans Riesebos
Mark Novak
Harvey Bingham
Madeleine Rothberg
Al Gilman
Gregory Rosmaita
Regrets:
Kitch Barnicle
Rich Schwerdtfeger
Absent:
David Poehlman
Jim Allan
Mickey Quenzer
Charles McCathieNevile
Next teleconference: 20 April
Agenda [1]
[1] http://www.w3.org/WAI/UA/2000/04/wai-ua-telecon-20000419.html
1)
Open Action Items
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:
<BLOCKQUOTE>
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].
</BLOCKQUOTE>
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.
JG: 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.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Wednesday, 19 April 2000 15:45:10 UTC