Raw minutes from 28 June UAWG teleconf

Hello,

My apologies for the delays in getting these minutes together. This
is the combination of notes from Jim Allan and myself. Please let me
know if there are any changes necessary.

 - Ian

-----------------------------
Agenda announcement: 
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0271

Participants: David Poehlman, Jon Ferraiolo, Al Gilman, Ian Jacobs
(Chair),
Dean Jackson, Jim Allan, Tim Lacy, Aaron Leventhal

Regrets: Jon Gunderson, Harvey Bingham, Mickey Quenzer, Gregory Rosmaita

Previous meeting: 21 June 2001
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0263

Next meeting: Either 5 July or 12 July; stay tuned to the list.

Reference document 22 June 2001 Draft
  http://www.w3.org/TR/2001/WD-UAAG10-20010622/

==========================================================================

Summary of meeting:

Jon Ferraiolo and Dean Jackson of the SVG WG were invited to discuss
some of the issues that the SVG WG raised that require additional
communication with the UAWG. These issues are highlighted in sections
A and B of draft responses to the SVG WG [1].

  [1] http://www.w3.org/WAI/UA/2001/06/svg-lc

IJ started by mentioning two issues that pervade the SVG WG comments:
the document doesn't seem to do a good enough job explaining
applicability and modular conformance.

JF said that there seemed to be 4-5 levels of formality (normative,
less normative, informative, etc.). IJ said that only two level are
intended, and that if any techniques are sufficient but not in
checkpoint text, that's a bug. Everything in checkpoints + conformance
is normative, everything else informative. 

Action IJ: Ensure that sufficient techniques are in checkpoint text,
not notes.

There was some discussion about how the UAWG and the SVG WG should
work together to make sure that it's clear how UAAG 1.0 applies to
SVG. Since UAAG 1.0 cannot include normative statements that are
technology-specific, the SVG WG may (or should) include normative
statements in future SVG documents that incorporate (and instantiate
for SVG) UAAG 1.0 checkpoints. The WAI and the SVG WG should work on
the binding of UAAG 1.0 to SVG. 

AG expressed support  for a test suite. Even  if informative only,  it
will be very useful to developers. TL and  JF agreed. JF said that the
SVG WG  has decided that test suite  generation  will go hand  in hand
with specification generation   for  SVG 1.1.   As work  proceeds   on
accessibility, the SVG WG could generate  test suite for those aspects
along the   way. IJ suggested looking   at the  MathML test  suite for
inspiration.

----------------------------------------------------------
A.1 Checkpoint 2.4: Doesn't make sense for SMIL 2.0 timing
Issue 516
----------------------------------------------------------

JF expressed the following concerns:

 a) It is possible to specify "definite" and "indefinite" timing
    in SMIL 2.0. Definite means that the user agent can tell
    beforehand whether and when something is supposed to happen.
    
  
 b) In practice, most content (JF said about 75%) that uses SMIL 2
    timing relies on indefinite timing (e.g., that relies on user input
    as a trigger).

IJ explained that the goal of UAAG 1.0 is to address definite timing
(what the user agent can "recognize"), and that there are some cases
(e.g., "begin"/"end" attributes) where the user agent should recognize
the time as definite. Wall time, user interaction events and other
things that are not controlled by the user agent fall under
"applicability".

JF argued that since this checkpoint would not be useful in many
cases, SVG user agent developers should not have the burden of
implementing the checkpoint. JF argued that this was an authoring
problem: low-level events are not the appropriate place to require
functionalities; the author must first provide semantically rich
content.

The UAWG argued that some users cannot use the standard user
interface, and therefore need programmatic access to the same event
handlers. Some users have a physical disability, so this is not just
about making graphics accessible to users with blindness via
descriptions.

There was some discussion about what constitutes an enabled
element. The UAWG went over the definition.

JF: It is possible in SVG to define a link that's only active for one
second. But a Rectangle could obscure the link and preventing it from
being enabled. There's inheritance of property pointer events so that
you can't look at an element and decide whether links are
enabled. It may require analysis of the document tree. 

AG: JonF gave us a quantitative analysis that 2.4 is a minority case
for SVG. The UAAG isn't in the business of saying format-specific
things. An official statement that 2.4 doesn't apply to SVG is
unlikely. However, the implementors are free to take this approach if
there are good reasons.

JF: Should it be 10% of cost to implement UAAG? 100%? 200%?

DP: From the user's standpoint, it is possible to significantly reduce
an implementation burden that the developer though originally was
quite high. The process has been to provide plausible solutions, and
to leave a lot of room for different implementations and
extrapolations. Tell us if there are insurmountable obstacles.

JF: I think that 2.4 is a bunch of extra code to analyze the
particular nature of the current document tree. It's fine to include
these as checkpoints. I have problems with resistance from WAI about
applicability.

DP: As we move forward, the bigger picture SVG WG is bringing will
help.

AG: We need to make it clear what's burdensome here. I heard that
determining ahead of time that there are open sensitivities would take
another kind of analysis than what is done to handle interrupts when
and if they happen.

JF: Yes.

AG: That's a piece of data that the UAWG was not aware of. We were
thinking about HTML script handlers. I think that this concept is new
data. Some stuff is not as important as others (e.g., hula dance when
you pass over it). The other argument that might come to bear: what's
been recognized in SVG may cough up a class of pauses that makes the
content useless.

JF: To implement 2.4 completely and ensure that we catch every case,
we'd probably have to do a pause with every frame.

/* No resolution */

----------------------------------------------------------
A.2 Checkpoints 4.4/4.5: Complicated for nested time containers
Issue 517
----------------------------------------------------------

IJ: We have not considered nested time-sensitive comment.
I think that the checkpoint applies. I don't think we've discussed the
nested time container issues.

JF: SMIL has a tiled approach to regions. You break the canvas into
regions. There are distinct places where you could say "I want to go
to this region an pause it".

IJ: What's the relationship between a region and a time container? 
Is the binding to the layout required?

JF: How do you select a nested time container? I don't see right away
how to do this easily. There's an infinite canvas.

IJ: What about just requiring control over the root time container?

JF: RealNetworks has a pause capability for the entire document.
Dealing with nested things is complicated. You need a selection
mechanism.

IJ: Selection is important, but a graphical selection is not the only
technique. You could use menus, for example, but you lose context.

IJ: 
 - Synchronization is one thing.
 - Nested is another story.

IJ: Are nested time containers always relative?

JF: In Adobe product, you have the possibility of pausing a parent and
either continuing or pausing a child. 

IJ: I can see it being useful in the independent case: pause parent,
go through children and slow them one-by-one.

Proposal:

 - Where children dependent on parents, we cover this through
   synchronization.

JF: What about: when parent causes pause of child, no requirement to
pause child independently. Otherwise, ok to require independent pause
of child.

Action IJ: Write a proposal where control is required. If controlling
parent allows control of synchronized child, this is sufficient.

----------------------------------------------------------
A.3 Conformance icons
Issue 518
----------------------------------------------------------

IJ: My understanding is that the icons don't represent certified
conformance.

JF: I'm satisfied with response.

Resolved: 
 - No change: icons represent claims, not certified claims.

Action IJ:: Clarify in document that icons only about claims.

JF: What is the point of conformance icons?

IJ: Marketing. For example, on SVG viewer page, put icon, say we
conform to UAAG 1.0, with link to guidelines. a vendor could on the
web make a claim to accessibility. We cannot say to press that yes
company X is accessible. Claims are in hands of claimant.

----------------------------------------------------------
Checkpoint 3.4: Requirement to alert users to presence of scripts too
burdensome / utility not clear
----------------------------------------------------------

IJ: First, let me clarify that this is a single binary alert:
There are / are not scripts somewhere in this content. At a previous
telecon, Tim Lacy reported that this required a single API call (e.g.,
for the SCRIPT element in HTML) and was not expensive. Would require
extra API calls for event handlers.

IJ: Rationale: This is a last resort checkpoint. Blinking may be
caused by a script, for example. We have "turn off blinking" as a
higher-order requirement. Turning of scripts is a big hammer but may
be necessary.

JP: this is implement able, it parallels, something the HTML user
agents implement and will have same check point. boils down to
priority level. P1 yes its worth every should implement, or P2 would
be nice to implement.

IJ: not quite, P1 - it is impossible to do something, with given
rationale.  Alert is P1, there is no way to know about scripts.

JP: In case of SVG are script there, benefit, if there is scripting in
this document what use is it to the end user.

IJ: Do you think the alert is P1 or P2? Do you think that turning of
scripts P1 or P2?

JP: For SVG, both are P2. Most of the time scripting has to do with
things moving about.

IJ: what if user has cognitive disability, and this movement is
distracting.  

JP: have to think about that, there is a call to javascript, not
stopping scripting but pausing scripting.

IJ: We have specific pause animation checkpoint. If pause does not
work then user may need to turn off scripts. We have a similar
checkpoint
to turn off style sheets as a last resort. 

/* On the topic of too many requirements in UAAG 1.0 */

IJ: We must create cross-disability guidelines. Can't eliminate
constituencies to make the document smaller. Our concern now is
technical feasibility. We are sensitive to implementation burden. We
will learn more in CR. We have spent a lot of time coming up with this
list of requirements, and these priorities. We can't just drop
priorities, nor just eliminate checkpoints. We have a pretty good
conformance granularity, and have decided a long time ago not to have
a per-checkpoint conformance granularity.

IJ: We do intend to include informative profiles to help developers
get started with the most relevant checkpoints for the type of UA they
are implementing. But they must always consider all checkpoints
(depending on the conformance level they choose).

JF: You have a set of checkpoints, and are bickering about particular
checkpoints and implementation. It might be more valuable to say here
is svg, what can we do that match with svg design and promote
accessibility. You started from html and generalized to others. That's
a round peg in square hole.

DP: I am not sure how I would beneficially work with SVG, but then
again, I said the same about Windows before their work on
accessibility started.

JF: It might be more productive for the world for the access team and
the svg wg to get together and talk.

IJ: I think that we have already tailored the UAAG conformance
mechanism to different shaped holes. We can address specific technical
comments now, but can't redo the entire shape of UAAG 1.0 at this point.

JP: The explanation in past half hour have been very useful. you may
be running into problems with candidate rec and implementability. May
be opportunities missing just looking at current guidelines.

IJ: SVG is on edge on our knowledge and expectations. We have
generalized somewhat from html, but also smil, for example. UAAG 1.0
does not address mobile devices. Some things may work for svg some may
not. There has not been sufficient communication to see which apply
and which don't. may develop a document jointly, might be a good
thing. 

IJ: How can we advance from here with respect to the SVG WG comments?
I think we have addressed them most of them. Will SVG object in CR
process or say we understand where you are coming from? The SVG review
was helpful, but may not apply in all cases. We are very interested in
getting out of last call. 

Action IJ and DJ: Discuss technical comments from SVG WG and bring
back to both WGs. Deadline: 2 weeks.


-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Cell:                    +1 917 450-8783

Received on Monday, 2 July 2001 17:20:41 UTC