- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 14 Mar 2002 15:37:21 -0500
- To: w3c-wai-ua@w3.org
UAWG teleconference
14 Mar 2002
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0089
Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe)
Tim Lacy, David Poehlman, Jim Allan, Aaron Leventhal,
Eric Hansen, Rich Schwerdtfeger
Regrets: Harvey Bingham
Absent: Lee Bateman, Denis Anson
Previous meeting: 21 Feb 2002
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0069
Next meeting: 28 March.
Reference document 12 September Candidate Recommendation:
http://www.w3.org/TR/2001/CR-UAAG10-20010912/
==========
Discussion
==========
0. Discussions about evaluations:
DP: Expectation that will be done with Jaws 4.01 and IE eval
in a week.
TL: Note that 5.5 SP1 support for changes has ended. I advise
people to not do evaluations based on IE 5.5.
1. Charter status
IJ: Should be sent to the Advisory Committee in the
next week.
2. Implementation Report Update
http://www.w3.org/WAI/UA/implementation/report-cr2
JG:
- Added Opera 6 evaluation.
- Incorporating Mozilla evaluation from Aaron.
- New format for evaluation pages
JG: I have a student implementation of 1.2. I haven't heard major
developers say they would do 4.6 soon.
IJ: In a few weeks, will summarize where we are and make some
decisions about how to advance.
IJ to AL: What are the chances that some functionalities that are not
exposed will be exposed through the UI?
AL: Someone in our UI team will be at CSUN.
IJ: Will you be doing lobbying?
AL: I do some. Sometimes users lobby. If the UAWG sees something we
want, email me.
JG: I would like to talk about add-in technologies.
IJ: I suggest exploring how skins can be used to provide
access modes.
IJ: I suggest adding to the Mozilla "customize" documentation (at
least for now) how to make use of "hidden accessibility features" that
exist today but aren't exposed through the UI.
AL: Sounds good.
3. Ian's proposals based on UAAG evaluations with developers
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0085
=============
From the Mozilla review:
1) Can checkpoints 6.1 and 6.2 be satisfied if the
APIs are not available out-of-process?
AL: I think that when AT vendors say "we would love to use the
DOM", they are not thinking necessarily about the W3C DOM. They
may be thinking about something that gives them access to a
proprietary tree. I contend that these developers don't know what
you're asking for. I think we should ask them "How would you use
the DOM?"
AL: I think ATs will be more likely to use the DOM
out-of-process. These ATs get a handle of the current window, or
the current object. ATs have access through COM.
JG: I think that some developers would like to use the browser's
DOM due to mismatches that happen when they try to do
repair. They'd like access to the UA-defined DOM (e.g., when
invalid markup is repaired differently). They are not worried
about cross-platform support.
AL: Do these developers have a way to use this DOM when it's
in-process?
IJ: My understanding for a long time has been that we were
expecting primarily in-process communication with ATs. See
Techniques Document section 2.18 [1].
AL: I'm wondering how this would work in practice (for out
of process access).
/* RS joins */
AL: Do you know if in-process stub technique has to be
thread safe?
RS: Right. I've tried to push this within the DOM WG.
Their attitude is that this is an implementation
detail. Sometimes using the DOM is done on the server for
transcoding. In many cases, work is done on a single thread,
people are not concerned with semaphores. In reality, if you are
providing access out-of-process, this is usually done with an
object broker, who does this for you. For in-process, you would
need to be sure that it's thread-safe.
AL: I think that it should be a requirement that if you provide
in-process access, it has to be thread-safe.
IJ: Is this for UA developer primarily, or the AT developer?
RS: Mostly the user agent developer. E.g., IE Windows does this
marshalling through COM.
TL: We've done a lot of work to address the asynchronous nature
of how the DOM works.
Action RS: Write up paragraph about the importance of thread-safe
access for in-process ATs.
Resolved: Checkpoints 6.1 and 6.2 be satisfied if the APIs are
not available out-of-process? (No change to the document.)
AL: I think that a "thread-safe requirement" should be at
the checkpoint level.
IJ: I think this is a general requirement for DOM technology
and is not just an accessibility requirement: if you're in
a threaded operating system and providing DOM access, then you
need to provide secure access.
IJ: Do we have evidence that people will be implementing
DOM in a threaded environment without secure access as we've
been discussing?
AL: Yes, Netscape.
RS: Plugins also need access.
IJ: Does everyone think this is important?
(Yes).
IJ: Does anyone think this should not be a requirement?
JG: This proposal is based on new input from a developer.
TL: Thread-safe etc. are implementation details. Is this
the type of information that belongs in the checkpoints?
IJ: Are there other requirements (e.g., security) that
can be grouped with this?
AL: When you don't make something thread safe, you are
likely to get better performance.
Action JG: Schedule a teleconf with AT developers
for two weeks from today.
AL: I can attend.
[1]
http://www.w3.org/TR/2001/WD-UAAG10-TECHS-20010912/topics#loading-at
---------------------------------------------------
Checkpoints 6.2 and 6.3 (DOM write access and programmatic access
to other types of content): there is some content where it's a
security issue to provide *any* kind of programmatic access.
Some ideas for dealing with this:
a) Provide programmatic access, but when security is an issue,
prompt the user for confirmation (on configuration).
b) If the user agent has a mechanism for allowing trusted
programmatic access, then ATs should use this mechanism, and the
UA must make available all content to these trusted agents.
/* IJ gives background */
IJ: Do trusted communication mechanisms exist?
TL: I guess not.
IJ: Maybe it was Adobe.
DP: Yes, it does sound like Adobe.
IJ: How do we handle this security issue?
TL: I think that 6.2 as is makes sense: if you can
get at visually, then you need to be able to get
at this programmatically.
IJ: What about saying (not as a requirement) to prompt
the user before doing anything that's a security risk?
TL: We do this in other areas. We let the user define
what's secure enough.
RS: E.g., accept invalid certificates - do you want to accept?
TL: Right, this is all user-configurable.
IJ: What if the answer is simply "We're just not going to
implement that since it's a security hole."
TL: What about saying "Where the user is the right person to
decide, prompt the user, otherwise you don't have to implement
the feature?"
JG: What happens in IE DOM when you query a password control?
Do you get asterisks or the real password?
/* Discussion stopped there. */
---------------
Open actions:
---------------
1) TL and JG: Review initial implementation report for IE 6.0 and
comment
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0191
2) HB: Contact ION Systems for a review of their e-reader with UAAG
guidelines
Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0082
3) DP: Jaws 4.01 and IE 6.0 evaluation
DP: Expectation that will be done in a week.
---------------
Closed actions:
---------------
IJ: Ask JB about Flash (Macromedia) review
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0058.html
IJ: No information.
IJ: Forward information on Test Suites to QA working group
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0058.html
IJ: Ping Jonny Axelson about Opera 6
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0038.html
See review:
http://www.w3.org/WAI/UA/implementation/eval_win_opera6
TL: Let Ian know about IPR requirements in new charter by 21 February
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0058.html
RS: Let Ian know about IPR requirements in new charter by 21 February
http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0058.html
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Thursday, 14 March 2002 15:37:14 UTC