- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 02 Mar 2000 15:52:21 -0500
- To: w3c-wai-ua@w3.org
WAI UA Teleconf
2 Mar 2000
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
David Poehlman
Kitch Barnicle
Mickey Quenzer
Denis Anson
Harvey Bingham
Dick Brown
Gregory Rosmaita
Mark Novak
Charles McCathieNevile
Marja Koivunen
Rich Schwerdtfeger
Regrets:
Madeleine Rothberg
Next meeting: 9 March at 2pm ET
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0418.html
1) Review of Open Action Items
1.IJ: Propose checkpoint to address event notification timing issue
Not done, but discussions
--------------
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.
2) Issue CR#196:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#196
It is unclear to developers how they know they conform to
Checkpoint 6.2: Conform to W3C specifications when they
are appropriate
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.
3) Issue CR#197:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#197
Not clear with the scope of user preferences is in Checkpoint 10.7
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.
4) Issue CR#198:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#198
How much information needs to be provided to satisfy Checkpoint 8.4
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.
5) Issue CR#199:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#199
Poor wording of checkpoint 10.8, it is not clear what the
requirement is to improve accessibility
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.
6) CR#200:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#200
Checkpoint 5.5 on timely exchanges, developers not unclear on how
they know they have satisfied this checkpoint
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.
7) CR#201:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#201
5.5 "Ensure that programmatic exchanges proceed in a timely manner"
should be a priority 1
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.
8) CR#202:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#202
User agent configuration to render NOFRAMES content
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:
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
Resolved: Ian will edit this and add to definition of
alternative equivalents for content.
9) CR#204:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#204
Add collated text to Checkpoint 2.6 and 4.8 or create a new
checkpoint at lower priority
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.
10) CR#205:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#205
Timing issues related to AT missing or not being synchronized to
document changes
Resolved: Refer to #200.
11) CR#206:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#206
Precise specification of what parts of DOM are required
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.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814 or 212 532-4767
Cell: +1 917 450-8783
Received on Thursday, 2 March 2000 15:52:37 UTC