Chair: Jon Gunderson
Date: Tuesday, 9 May
Time: 1:30 pm to 3:00 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
Next teleconference: Thursday May 11 at 2pm ET (regular time)
Regrets for 11 May: HB, GR, CMN
Agenda   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0314.html
1. Notice of Proposed Rulemaking: Electronic and Information Technology Accessibility Standards by 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
2. New draft of ua guidelines available
DP: For 8.10, is this a mechanism for directly distinguishing active elements?
IJ: The highlighting part, yes. Review of section 3.1 of proposal: http://www.w3.org/WAI/UA/2000/05/ua-minreqs.html
Checkpoint 2.5: When the author has not specified a text equivalent for content as required by the markup language, make available other author-specified information about the content (e.g., object type, file name, etc.).
IJ: What if it is generated? What if it's inline (e.g., "OBJECT/data" in HTML 4.0?
1) Pick at least one from this set...
2) Prioritize the list...
3) Require all (if available) from this set...
1) Requirement: Resource name and (most specific) type, if available. Otherwise "Unknown".
Action IJ: Find out what HTTP gives you in the way of resource name.
Action IJ: Propose a clarification text of 2.5 to make clear that the user agent is expected to associate a text equivalent with the object, text eq generated from author-supplied information. [Note that this is a case where the UA recognizes the association since it creates it itself. Note also that this only applies when the author has not followed the spec.]
HB: I'd like the UA to indicate to the user when it can't support an object. Like for notification when a natural language is not supported.
IJ: What about OBJECT? You don't want indication at every level?
JG: This is not an accessibility problem but a usability issue. Also, our applicability clause says "when you don't support, you don't support." This sounds like notification would be a new requirement.
IJ: I am afraid to get into issues of error handling; that seems like a stretch and may vary according to markup language.
JG: What is true is that the handling has to be done accessibly.
IJ: Should we identify which checkpoints are repair strategies (like "When authors don't..." like "Until user agents...")? This would include 2.5, maybe 9.2. Maybe it's not worth if for only a couple of checkpoints.
Proposed: Split 3.8 back into two cases: redirect v. HERE:
1) For the redirect case, manual control. And translate the redirect to a link. [Note that this is a repair strategy for author-supplied redirects.]
2) For periodic refresh, people argued that they didn't want to refresh manually since they wouldn't be aware of changes occurring. In this case, manual control is minimal requirement and you have to be notified that new content is available. There are several techniques (periodic notification, mail-like notification).
IJ: What other content changes are we talking about?
JG: Scripting information.
IJ: For the periodic type, you want to be able to stop with notification. For the animations, you don't want this type of control - you want actual control.
DP: Should this be configurable, so that the user can set the refresh rate/prompt setting?
IJ: Is this on a page-by-page basis or globally?
1) Make requirements for two specific cases (in one or two checkpoints).
2) Something along the lines of: "For automatic redirects or content refresh specified by the author, allow the user to control the change."
3) Not an issue of timing. Minimal requirement is ability to make the change manually. User agent has to provide notification that new content is available in the case of content refresh. And user has to be able to find out that new content is available. RS: What should the UA do in the case of an author-supplied redirect?
IJ: Details up to UA, but the minimum technique is to allow manual change.
a) Propose new checkpoints (try to keep one checkpoint).
b) Ensure redirect technique is clear.
c) Find out why checkpoints combined in Austin and whether we lose information by making checkpoints more specific. http://www.w3.org/WAI/UA/1999/12/ftf-19991209
d) Global setting.
Proposed: Use "arbitrary" figures here:
1) Video: At least one setting between 40% and 60%.
2) Audio: At least one setting between 75% - 8%%. HB: I think the techniques should suggest that speed up also a good idea.
3) Respect synchronization cues up to 80% of audio speed. 4) Global setting.
HB: Configure or control (dynamically)?
IJ: I think we have identified the pieces to navigate now. We are honing in on the richness of the navigation techniques. Consensus among those present that the exercise of going through these checkpoints is worthwhile.