- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 05 Jan 2000 13:49:34 -0500
- To: w3c-wai-ua@w3.org
WAI UAGL Teleconference
5 January 1999
Participants:
Jon Gunderson
Ian Jacobs
Dick Brown
Denis Anson
Harvey Bingham
Mickey Quezner
Jim Allan
Gregory Rosmaita
Rich Schwertdfeger
Regrets:
David Poehlman
Kitch Barnicle
NEXT MEETING: 6 January 2000 @ 2pm ET for 90 minutes
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0002.html
1) Review Open Action Items
1.JG: Review techniques for Guideline 8.3 to 8.9
Status 8.3/8.4: Cancelled, though JG may check into Opera
capabilities.
GR: Refer to my evaluation of Opera
http://www.w3.org/WAI/UA/1999/09/uagl-hal95-19990906.html
Status 8.5: Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0011.html
2.JG: Draft a preliminary implementation report for CR
consideration
Status: Not done.
3.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints.
Status: Pending.
4.DB: Find out how developers find out which appropriate triggers to
use
in Windows for using built-in accessibility features (i.e.
sound
sentry, show sounds, ...)
Status: Pending. I've asked an MSAA developer for this information.
See thread from Jim Allan and Ian Jacobs.
DA: There's information at the IE site on this:
http://www.microsoft.com/enable/dev/guidelines/software.htm
(Follow Section 1)
5.DP: Propose new Checkpoint 1.5 for access to system messages
Status: No info.
6.GR: Send to the list techniques for how to use and control focus to
not have new windows cause problems for usability. In
particular, how
this will work with ATs.
Status: Not done. Will ask RS a question offline.
7.GR: Write a technique on how to create accessible installation
Status: May already be integrated.
8.GR: Run LPPlayer through the guidelines. Verify with Productivity
Works.
Status: Pending. Talked with both Ray and Mark. He'd prefer that the
analysis be done internally by Productivity Works. They
would contribute an evaluation. GR will keep us in the loop
on this.
9.MR: Review techniques for topic 3.1 (Multi-media)
Status: No info.
10.MR: Review techniques for Guideline 4 (Multi-media)
Status: No info.
11.MR: Run a multimedia player through the guidelines for January.
Status: No info.
12.MQ: Ask Mark about meaning of comment raised in Issue #167
Status: Mark is still travelling.
13.WC: Take form submission to GL WG to discuss issues related to
inadvertent submission.
Status: Not done. Ian reminded her today.
14.IJ: Refer to
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0758.html
Still todo:
a) Propose a technique for using XSL to transform content
b) Follow up on EH's e-mail with some comments from this meeting
related to issue LC#138 (will post as new issues if any)
2) Announcements
1.New UA weekly scheduled telecon (tommorrow) 6 January 2000 at 2:00
pm
to 3:30 pm Eastern Standard Time, USA
http://www.w3.org/WAI/UA/2000/01/wai-ua-telecon-20000106.html
2.Protocols and Formatting are holding a FTF meeting on 26-27 January
2000 at Sun's Microsystem in Cupertino - Silicon Valley
http://www.w3.org/WAI/PF/Group/2000/01/agenda.htm
3) Discussion
1.Candidate recommendation
JG: Henter-Joyce is implementing their own DOM-like API.
RS: IBM is looking at DOM for HPR.
JG: Work at CAST in their e-text reader also involves DOM.
MQ: I'll ask Mark if PWWebSpeak is using the DOM. JG will email
as well.
IJ: To get to CR:
a) Resolve outstanding issues.
b) Prepare an implementation report
c) Schedule a meeting with the director.
d) Target start date: 14 January.
e) Target duration: will be determined based on implementation
report, but if DOM implementations are
working, then starting point would be
one month.
4) Ian's proposal for "UA Responsibilities"
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0755.html
IJ: Goals:
a) Is this useful?
b) What's missing?
c) How to resolve remaining ones?
DA: I think "AT" definition is too fuzzy. I think that AT's provides
functionality for which an able-bodied user doesn't require extra
software. Not necessarily a plug-in, may be a wrap-around.
Some things that are conveniences for an able-bodied person
(e.g., TV Remote control) are not just conveniences for someone
with a disability because they don't have another way to do it.
This may comprise the group of requirements that should be
built-in natively to the desktop user agent.
DB: This document is useful for developers as well as for "critics"
of the guidelines.
Action IJ: Publish a new draft that incorporates JG's comments.
DA: Some of the "Apply to all user agents" are actually "Apply
to all applications". I suggest creating a "Requirements
for all software" category. And these shouldn't be native but
in the OS.
Action DA: Identify the general ones from the list.
Action EVERYONE: Review the "Unknown" category and we'll discuss them
at tomorrow's meeting.
Action RS: Send editorial comments.
5) Issues
2.LC#156: Propose change in priority of 5.6 (P1 -> P2)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#156
JG: Håkon Wium Lee thinks DOM should be P2, since it turns a
browser into an editor.
Some ideas:
a) Change to P2 as HWL suggests.
b) Change to P2 for write access.
RS: You can't fill out a form this way.
c) Change requirement to be more general
(as we did for UI access).
d) Leave P1.
JG: I'm not sure that physical memory concerns is an issue.
In the past, we haven't made human resource limitations
a criterion.
DA: The DOM is a special case. We're not talking about
functionality here, but implementation.
JG: We've talked about this and since the DOM is
platform-independent and vendor neutral, we felt is
was necessary for interoperability.
HB: We may not be able to paste into the DOM something
that is an audio source. The error control process has
to be invoked to ensure validity.
DA: I don't think this is a big issue. Speech input is a
wrap-around technology converted to movement or keyboard
input.
/* DB and JG leave */
GR: My concern is time lag to implementation by ATs.
People are looking to these Guidelines for quick
improvement to the Web experience (say, a year).
I think that we should send the "UA Responsibilities"
document to reviewers of the document so we can
"show them the money". (Add this concern to the "UA
Responsibilities doc?)
DA: I think the time lag issue is valid for *any* standard
we would promote. Therefore, we can "arbitrarily" choose
the DOM.
IJ: Sounds like a FAQ: "When will browsers be accessible?"
Resolved:
1) Leave P1 for reasons of interoperability and requirement
for write access.
3.LC#158: Propose priority change (1 to 2) for checkpoint 4.1
(control
of font family)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#158
DA: I have a hard time arguing that it's P1. It is difficult,
but not impossible.
IJ: What about some ornate font family?
DA: There are probably a few people for whom it's gibberish.
But if you don't have the appropriate font on your computer,
your browser will choose another anyway.
GR: Important for low vision and cognitive. But my gut feeling
is P2.
JA: You can always find a font family that makes it impossible
for someone to read the text. Take wingdings, for example.
There may be font families that are easier or less easy
to read.
DA: There are inefficient ways, but not impossible ways, to
read the text (e.g., cut and paste)
Resolved:
1) Change to P2.
2) Action Ian: Send this resolution to the list for comment.
4.LC#159: Propose raise priority of 4.13 to Priority 1
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#159
DA: I think start and stop (video, audio, animation) is P1.
"Start" means "start from the beginning".
IJ: You can restart from the beginning by reloading the page.
Why is it P1 to stop?
DA: It may be distracting you from other things on the page.
JA: I've visited sites where audio was rendered and you couldn't
stop it; different audio clips overlapped.
DA: I don't think that slow compensates for pause. Pause should
be P1 as well.
HB: If you're working an audio or braille stream that is pouring
out and synchronized with other content, you need to change
the rate of the audio controls and stay synchronized.
IJ: Pause isn't P1 - you still have access to the content;
you can start from the beginning.
DA/GR: Lack of pause may make access to content impossible for
some users with disabilities. If they don't have time to
stop and are forced to start again, they will never get
to the end of the content.
Resolved:
1) Move "start, stop, pause, rewind, advance" to P1.
5.LC#161: Raise priority of 8.8 to P2 (highlighting and identifying
selection/focus)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#161
IJ: This checkpoint means "Let me know which elements are
active".
DA: Some users with cognitive disabilities need this.
JA: If the user can't find it, the function is not there.
Resolved:
1) Raise to P2.
Received on Wednesday, 5 January 2000 13:49:38 UTC