Chair: Jon Gunderson
Date: Thursday, March 2nd
Time:
2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in:
Longfellow Bridge (+1) (617) 252-1038
none
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#196
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#197
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#198
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#199
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#200
Resolution Options:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#201
Resolution Options:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#202
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#204
Proposed Resolution:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#205
Resolution Options:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#206
Resolution Options:
Chair: Jon Gunderson
Scribe: Ian Jacobs
RSVP Present:
Kitch Barnicle
David
Poehlman
Mickey Quenzer
Dick Brown
Denis Anson
Harvey
Bingham
Gregory Rosmaita
Mark Novak
Charles McCathieNevile
Marja
Koivunen
Rich Schwerdtfeger
Regrets:
Madeleine Rothberg
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0418.html
1.IJ: Propose checkpoint to address event notification timing issue
Not done, but discussions, canceled due to resolution in telecon
OTHER IJ Actions in next draft
2.IJ: Split checkpoint 5.1 (28 January Draft) into read and UI write as stated in minutes
3.IJ: Add a cross-reference from 2.1 to 5.1 and say in 5.1 that this is a special case of 2.1
4.IJ: Add techniques to checkpoint 7.2 for synchronous multi-media presentation (space and time)
5.IJ: Ensure that techniques for checkpoint 1.5 talk about using status bar to display message
6.IJ: Incorporate proposal for checkpoint 1.5 from minutes
7.IJ: Add rationale to Checkpoint 1.5: if you're deaf blind you might need this (Braille display).
8.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints
No info.
9.DB: See if microsoft can produce HTML version of their developer guidelines
DB: Status Done: Greg Lowney has wanted to get the docs into HTML. Asked Webmaster to do so.
CMN: Use "tidy" to clean up Word 2000 output.
http://www.w3.org/People/Raggett/tidy/
10.JA: Rewrite techniques for 3.3 (see minutes)
JG: JA says for next week.
11.MK: For 4.8 check if any media players do this?
MK: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0248.html
12.MK: Find out techniques for sending text search requests to servers of streamed text.
MK: I've sent mail, but received no replies.
13.MR: Review techniques for topic 3.1 (Multi-media)
JG: MK will try to post for Friday.
14.MR: Review techniques for Guideline 4 (Multi-media)
JG: MR will try to post for Friday.
15.RS: Take timely and synchronization issues to WAI PF. Get input from
MSAA developers as well. Craft email to PF WG with Ian
Status: Dropped.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#196
Resolved:
1.Change wording "Use and conform to
W3C specifications when they are available and appropriate for a task."
2.Add note: Implementing one accessible format
3.Add techniques: From ATAG
"Specifications that become W3C Recommendations after a user agent's
development cycles permit input are not considered "available" in time."
Action IJ: Implement this resolution.
DA: This is basically saying: Use W3C, then system standards, then your own accessible methods. "When they are appropriate" means "if there's a straightforward way with a W3C spec, you should do this.
KB: I have no problem with this wording and the accompanying note.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#197
Resolved:
1.Narrow scope to that which is
specified in the guidelines as configurable (style and input config).
2.Add technique: Accessible browser project portable configuration file
IJ: Note that Netscape uses X resources, which can be used on any X-windows enabled machine.
Action DP: Send NN profile info.
Action IJ: Implement this resolution.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#198
Proposed Resolution:
1.Make current list of items is minimum requirement, plus any that we may have missed
DP: How does a UA know the size?
JG: Do a GET on the header?
DA: Do you want this always for all links, or just be able to query the link? Could be expensive to do if it's not query.
DP: I think it is useful to have this available when the link is rendered. Query/rendered should be configurable.
CMN: I think we should specify "what's available to the browser" without having to go get information from HTTP calls. Note that this also depends on the linking mechanism.
IJ:
- What's in the markup (attributes, content)
- What's the
UA's state about the link.
- External information it could get.
IJ: Charles has proposed the first two types of info.
DA: Seems reasonable as minimal information.
JG: Who decides whether you satisfy the checkpoint?
CMN: It's known since in spec or the UA knows this info.
Resolved:
- Change checkpoint text to be
something like: "Make available author-supplied and user agent state
information about links."
- Add technique to distinguish this info from
fetched. (more than the minimal requirement)
Action IJ: Implement this resolution.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#199
Resolved:
1.Ensure that frequently used functions
are easily activated in the default configuration.
2.Add technique: Use
operating system conventions to indicate configuration.
DP: How do you verify easily?
IJ: How did ATAG deal with this?
CMN: There is subjectivity in this, but this is a reasonable person type test.
DA: What are frequently used functions? Navigation, accessing pages, etc.
Action IJ: Implement this resolution.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#200
Resolution Options:
1.Merge requirement in with other applicable checkpoints
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0359.html
2.Ian's pending proposal
IJ:
- Drop it.
- Leave it as is.
- Leave it as is with
an example (note) relating to in process communication.
- Comparable
performance to what you get from scripts.
JG: We don't know what that
performance is.
MN: But that performance level accepted in the industry.
If we could get AT performance with what scripting can do now...
MQ: But
hard to quantify the performance of scripts...
- Distinguish static from
dynamic? AT developers thought static just as important.
DA: I don't think we should drop it.
CMN: I feel strongly it shouldn't be dropped.
KB: Does this fit into the category of general accessible application design?
IJ: Why is this problem different from a slow download. CMN: If the page downloads and starts doing something while you're doing something, you'll never know what happened.
DP: Like playing your video tape before your television picture has appeared.
JG: How about: "Use programming techniques that ensure a timely exchange of information." The programmer can't do better than what's available to the programmer/os.
KB: Does this make it more verifiable?
JG: Say clearly in a note that developers should be looking for the most effective techniques.
KB: To me this sounds like general programming advice that's not specific to user agents.
RS: I think it's smart to say that you want to avoid cross-process communication.
CMN: This is an implementation requirement. Our problem is expressing the requirement in words other than examples.
JG: Can we talk about it in terms of "conventions"?
RS: The conventions of today are too slow.
Resolved: Leave checkpoint as is and add an example note.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#201
DA: P1 for dynamic pages.
RS: Also for large static docs.
IJ: I oppose P1 for static, since information is still available. However, for dynamic, problems if the rate of exchange of info is less than the rate of change of the information.
KB: But we allow users to stop dynamically changing pages. (P1)
JG: Also, 2.2
RS: MSAA may not have been used extensively in the past due to performance issues.
IJ: You fail 2.1 (access to all content) if you don't make available content that is changing. This is already P1.
CMN, RS, MN: I can live with this, though a sludgy way around this.
Resolved: Add a note to 2.1 to clarify that it covers dynamically changing content.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#202
Proposed Resolution:
1.HTML 4.0 Specification issues related to NOFRAMES rendering http://www.w3.org/TR/html4/present/frames.html#h-16.4.1
IJ: Since 2.1 is not strictly through the UI, then making available through an API sufficient.
GR: Recall, that access to frame alt requirement was dropped for a note, but the note no longer there:
Mechanisms for specifying alternative content vary according to markup language. For instance, in HTML or SMIL, the "alt" attribute specifies alternative text for many elements. In HTML, the content of the OBJECT element is used to specify alternative content, the "summary" attribute applies to tables, etc. In HTML, the NOFRAMES element specifies alternative content for frames. The ability to access frame alternatives is important for users of some screen readers and users with some cognitive impairments.
Resolved: Ian will edit this and add to definition of alternative equivalents for content.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#204
Proposed Resolution:
1.Add collated text to checkpoints
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0343.html
MK: If it's not synchronized, no problem.
IJ: Is this more burdensome than a caption?
MK: Same as caption.
Resolved: Adopt Eric's proposal.
Action IJ: Review Eric's proposal by Friday.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#205
Resolved: Refer to #200.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#206
MN: I and others have a number of concerns about this module. I think we should leave out of this draft.
CMN: I think it's tricky to put it in. There are good bits and not so good bits.
HB: I wouldn't miss it.
DA: We may also be covered by 6.1 (available and applicable).
Action CMN: Suggest some techniques related to the good bits (related to checkpoint on notification 5.4).
Resolved: Do not add the events module.