- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 13 Dec 2001 17:37:43 -0500
- To: w3c-wai-ua@w3.org
13 December 2001 UAWG teleconference
Agenda announcement:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0095
Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe),
Jim Allan, Harvey Bingham, Katie Haritos-Shea,
Denis Anson, David Poehlman.
And for the DOM discussion: Ray Whitmer, Philippe Le Hegaret, Al
Gilman, Charles McCathieNevile
Absent: Gregory Rosmaita, Rich Schwerdtfeger, Eric Hansen,
Tim Lacy, Mickey Quenzer, Lee Bateman
Previous meeting: 29 November 2001
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0082
Next meeting: 13 December
Reference document 12 September Candidate Recommendation:
http://www.w3.org/TR/2001/CR-UAAG10-20010912/
--------------------------------------------------------
Use cases for enumerated list of event handlers in DOM 3
--------------------------------------------------------
Issue: Is an enumerated list of event handlers the best way to
address the documented use cases on this thread:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0089
RW: You have a list of objects that implement the listener
interface. Tells you nothing about the event type or other info
when listener registered.
IJ: Sounds like information is lost after registration. Is this
an implementation-specific detail that's not exposed?
RW: Yes. Implementation must store this information internally.
Event group must be available as well. The event group is used to
avoid cases where unrelated event listeners interfere with each
other. An implementation has to keep it somewhere, however.
IJ: We need to justify use cases. But DOM may need to be extended
to allow access to this information through the API (not hidden
internally).
PLH: We don't think enumerated list matches your requested use
cases. Now that we have your use cases, we need to be sure that
whatever solution we come up with covers the use cases.
AG: As I read the thread, I think that Ray and Joe both
understood the use cases and the utility.
AG: High end request: ...human readable name/description, machine
readable info as well.
AG: Where does the DOM get the information to meet the user need?
There is PF/HTML WG discussion on this. PF has been working to
get the formats to provide the information that the DOM would
need to provide this service to the user.
RW recapping:
* The idea of enumerating the physical event listeners at
several levels is bad. Directly calling handlers is not a
good idea. Having them cascade is better, at which point you
don't need to know the names of the handlers. What you want
to know is "Is there anyone out there wanting to respond to
this?"
I think you're down at too low a level to get anything useful.
Instead, we should consider use cases and use the "Dispatch
events" call.
*Even better, come up with a set of semantically-created
events that would be more appropriate to fire directly, rather than
trying to simulate user key strokes.
AG: In the PFWG archives, there's a thread about XML Events:
XML events
From: Charles McCathieNevile (charles@w3.org)
Date: Mon, Nov 26 2001
http://lists.w3.org/Archives/Member/w3c-wai-pf/2001OctDec/0168
JG: AG is stating long-term goal - We talk about being able to
simulate events.
RW: You can call the dispatch events function. You don't need to
enumerate the handlers. And you get a better result -
relationships between multiple handlers better.
JG: Also useful to know that there are no events associated with
a node.
Charles: Key point, which I think Ray and Joe have both made, is
that we want to be able to find out events (how many listeners
there are) and what they do (get a description from them).
RW: If I fire a keystroke event, is someone listening? You could
have a dozen event handlers registered or zero; in both cases,
you just want to present to the user the option of firing events.
You may want to know about keystroke and mouse, but don't
want to provide access to any old handler.
RW: I think a boolean question is more appropriate: "Is there a
mouse handler here?" If the response is true, use the dispatch
event. Boolean query is not yet possible, but seems closer to
what you want.
Charles: problem when the user doesn't have a good picture of the
page is that they are left tapping every part of it often.
RW: I think there are more issues to iron out; worth having
people sit down to talk about this issue.
AG: The burden on the DOM is to present to the AT; but the AT may
show to the user.
DA: The typical able-bodied user doesn't know what's available on
an element either.
AG: But there is a lot more cueing in terms of concurrent
presentation. Generally speaking on mouse overs, the context sets it up.
Two reasons:
1) People unable to use mouse actions should be able to have
access.
2) People without concurrent visual display may need a more
verbose interface where they learn more of what's available.
Harder to retain context for some users.
RW: One reason I've argued for a boolean - possible for an
application to establish a single key-handler at the root of the
document. The handler could be performing services for the entire
document.
IJ: Is PF the place to address this (having given UA input)?
AG: I'd like to form a swat team to address this composed of
participants from UA, PF, DOM, AT developers, those working
on events.
ACTION PLH and IJ: Convene a subgroup to address this issue.
/* Charles, PLH, AG, Ray leave */
---------------------------------
2) Rechartering/Next steps for UAWG
---------------------------------
/* On the call: Judy, Jon, Denis, David, Katie, Ian, Harvey */
JG: Ongoing actions related to UAAG 1.0:
- Improve implementation report
- Section 508 comparison (Katie, Jim)
- Ian and Judy have been contacting developers; getting more
implementation data in the next two months (Ian corrects JG's
statement of several weeks).
JG: Based on that implementation information, we can better
assess how to move ahead. Right now I don't think we have enough
data to make a strong decision about moving forward.
JB: When document entered CR in early September, its initial
estimate was end of December. I don't think people expected to
get 100% implementation in that period.
Our initial results were not promising due to
(1) developer focus on section 508
(2) tech downturn
(3) 11 September events.
JB: at the same time, the document being in CR has meant that
we've been able to have more focused conversations about
developers.
JB: I've been encouraged by some of what I"m hearing.
JB: Conversations may drive additional implementations.
JB: I think the UAWG needs more time to gather data.
JB: You might want to announce on WAI IG that the UAWG has
extended CR for another three months.
/* IJ notes that today marks the 3 months mark for first CR
period. */
JB: After three months, you may find you're almost there. May
require another couple of months, after which perhaps you might
pull a couple of requirements, return to last call, and move on.
JB: I am interested in hearing what the WG thinks about CR.
HB: Is CR restricted to public products only?
JB: No. The goal of CR is to demonstrate (1) that the provisions
of a spec can be implemented and (2) that industry wants to
implement them.
JB: I continue talking to the W3C Director to get his take on
CR. He says to use CR as a tool to figure out where your
specification is going.
JB: I would like to hear where people in the WG are at on this.
IJ: I think the more pointed question is: Do we keep gathering
data or do we try to cut back provisions?
JG: I think we need more data in order to make that choice.
HB: If we cannot get implementations on some checkpoints, we should
defer them to a later release.
DP: I think CR is a productive process. We've learned some things
that have helped the document. We can also do things in parallel
(like comparison with 508).
DP: We've also been able to bring others on board.
HB: The 508 comparison work indicates where company priorities
are going.
DP: I don't want to scale back the document, notably having
compared to section 508. UAAG 1.0 is so well defined and details.
Now we're not focussing on technical issues, but it's a period of
fragmentation. It may feel like nothing's happening. We need to
make sure we have ongoing stimulus.
JB: Stimulus could be a monthly status check.
JB: Where are you? What's missing? What product reviews can
people do?
IJ: Specifically: Would you rather that the UAWG proceed with the
document as is or think about scaling back the requirements.
Ongoing effort can be fruitful, getting more data, better
decisions, more involvement.
KHS: My concern is 508 - that's the driving force in the US. The
sooner we can finish UAAG 1.0, the better. As DP said, there are
a lot of other devices that are considering themselves user
agents. UAAG 1.0 may have to broaden its scope.
Denis: My view is that the current document represents our
current best estimate of what it would take to have an accessible
user agent. If we back off in order to push it through faster,
that compromise makes me uncomfortable. So I would rather keep
document intact and get implementation experience. Also need to
verify that conformance does in fact make the browsers more
accessible.
/* Jim Allan joins the call */
HB: Some checkpoints may remain stumbling blocks; may want to
defer those to another release. Four years is too long to have
the document drag on.
JB: KHS said that it's important to get UAAG 1.0 "out there".
I've slowly come to understand that it's ok for the document to
be in CR for an extended period. The message I've been getting
about CR is that CR already means "out there" - the message of CR
is "use this, implement this". W3C considers that this document
is properly designed for the subject it's addressing.
JB: I asked a developer if the spec as Recommendation would be
more likely to be implemented than as CR. The answer was "no". In
fact, going to Rec now might even hinder implementation; it's
probably better to get this support done before it goes to Rec.
I realize that there's a recognition problem for some
organization.
JB: With regards to other classes of user agents (and that UAAG
1.0 may not be up-to-date enough). I 've heard that from other
areas. One thing you may want to look at: in re-chartering (long
enough to follow Rec) you might want to say that there's some
value in this same group of people working on an initial set of
requirements for the next UAAG
DP: Thanks to JB for current synopsis of CR. We've been through
very public process (several last calls). The document is being
used, pointed to. I don't expect that the document would change
much as a result of CR (except removing a couple of checkpoints
perhaps). I understand KHS's situation with the document in
"beta testing". True, government agencies hesitate to point to
W3C specifications that aren't Recs.
DP: Any time we can get 508 to reference UAAG 1.0 is a good time.
DP: There is anticipation of UAAG 1.0 in various quarters.
KHS: What we learned with WCAG: even if you think you have
something good, you learn through real implementations. We need
to have the spec out there to get the real solid feedback.
IJ: We need to have more people participating actively over the
next few months. Also, we need to get developer buy-in over the
next few months in addition to gathering implementation data.
JB: Products have very different amounts of market share.
Initially, we're interested in any implementation. But we also
need to look at commitments that are being made.
IJ: I've had very succesful evaluations with zero buy-in
afterwards. We need to do both data-gathering and promotion
actively.
JB: We will be getting additional Team resources. I second IJ's
point that the progress of the WG will depend on the effort of
the WG participants.
JB: I've started looking over UAWG charter. I'm not sure that
there's consensus within the WG about what to do in a renewed
charter. One possibility is to recharter for a period enough to
get to Rec plus time to document requirements for next UAAG.
JG: I think a draft charter would be a useful place to start.
JB: initial requirements, not full requ set.
JG: Rechartering for six months would be minimum amount of time.
JB: Rechartering for longer time probably needed to get this
thing through the proc
JG: Part of process of reviewing charter is that individuals are
willing commit to the duration of the charter. When we see a
proposal, the WG needs to ask themselves that question.
IJ: I hear the WG saying move forward with the document as is;
one possible addition to charter - initial reqs for UAAG 2.
IJ: There is another piece that I would like: test suites.
DP: How does implementation experience affect the document? We
will need a period before requesting PR where we adjust the
document. Given the current pace of the group, I'm not sure how
long that will take. I see us sticking with it for a while. If
we need to recharter to do that, I'd like to see a charter
proposal to comment on.
JG: I think that JB, IJ, and JG need to meet to discuss this.
/* JG leaves */
----------------------
3) Section 508 comparison
----------------------
Katie's latest version:
http://www.w3.org/WAI/GL/508/508-UAAG.html
HB: I think the 508 comparison is a fine start. There are a
number of points still to finish.
/* We note that "@@" means work to be done in the document */
JB: I have problems with the title:
"Draft: Mapping Comparison Between Combined U.S. Section 508
Standards and UAAG 1.0 Requirements & Priorities"
JB: I think that "combined" is misleading.
JB: This is a comparison, but I object to the word "combined"
JB: UAAG 1.0 "requirements and priorities": We don't call the
requirements to my knowledge.
IJ: UAAG 1.0 does talk about "requirements" (e.g., checkpoints
consist of N requirements).
JA: 508 has several different standards - UAAG 1.0 is relevant to
applications, web, etc.
JB: Those are 'parts of a standard' The implication of the title
is that 508 is combined with something else.
JB: Please include a disclaimer that the access board has not yet
reviewed this.
IJ: I also note that the navigation bar at the top of the
document is very 508-centric. Any reason not more UAAG 1.0 links?
JB: Also, in abstract and status: explain why we are addressing
the standards of a particular country.
JB: I will try to comment offline.
/* IJ notes that he has not yet participated in this document.
IJ removes his name from the document */
DP: In some parts of the document, when you go through the list
of sections and find "no mapping", are you also mapping the
sections of 508 within each other?
KHS: Yes.
IJ: Where do section headers come from?
KHS: A couple of places - UAAG 1.0 and 508 sections.
KHS: Has anyone seen Kynn's straw man document?
http://kynn.com/access/fwap-0.1.html
IJ: I suggest removing joke from section 11 title: Blinking and
Flicker (two more of Santa's reindeer)
IJ: I just removed my name as author. Will glad to add it back
once I've contributed.
JA: This is the second or third pass. People's comments welcome!
KHS: We're doing a UAAG 1.0-centric document as well.
JB: We want to draw people into this process to help.
KHS: People have expressed that this document is useful to them
(the mapping)
DP: Can we get someone from the access board to participate in
the process?
JB: I will be talking to them next week. Will give them a
heads-up on this.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Thursday, 13 December 2001 17:37:46 UTC