Chair: Jon Gunderson
Date: Wednesday, April 19th
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in:Longfellow Bridge (+1) (617) 252-1038
Notes:
Proposals
for open ended and ambiguous checkpoints:
http://www.w3.org/WAI/UA/2000/04/min-req.html
Proposals for
open ended and ambiguous checkpoints:
http://www.w3.org/WAI/UA/2000/04/min-req.html
Current Info:
Proposal:
Update: Sent request to IJ, UA, AU, GL lists for more information
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
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.
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
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.
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.
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].
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).
/* 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.