- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 11 May 2001 22:29:40 -0400
- To: Rob Lanphier <robla@real.com>
- CC: w3c-wai-ua@w3.org
Hi Rob,
Thank you for the comments! Mine replies are preceded by IJ:
I hope that by this email I can clear up some points. I
also indicate which comments I have added to the WG's
issues list. If there are other comments you feel need
to be considered formal issues, please let me know.
Some of my comments request additional information.
Thank you (and RealNetworks) for taking the time to
review the document,
_ Ian
Reference document:
http://www.w3.org/TR/2001/WD-UAAG10-20010409/
Rob Lanphier wrote:
>
> Hi all,
>
> Here's the review from RealNetworks regarding the UAAG 1.0 Last Call
> draft. Thanks for the extra time to present this -- and hopefully pushing
> the deadline by a few hours won't present too many problems. :)
>
> First, some general comments. We think that many of the ideas presented
> here are great things for the community to think about. However, given
> statements regarding UAAG conformance made in the SMIL Language draft, it
> seems as though there may be a bit of a misunderstanding of applicability:
>
> The Web Accessibility Initiative is defining "User Agent
> Accessibility Guidelines 1.0" [[UAAG]]. User agents are
> encouraged to conform to the Priority 1 accessibility
> guidelines defined in this document, and preferably also
> Priorities 2 and 3. Once the guidelines are completed, a
> future version of this specification is likely to require
> conformance to the Priority 1 guidelines in Conforming
> SMIL user agents.
>
> After reading through the conformance claim section, it seems as though a
> specification referencing UAAG 1.0 would not be able to merely to all
> Priority 1 claims, but would need to actually have a well-formed minimum
> conformance claim.
> It seems very clear that a much more specific and
> carefully negotiated "minimal conformance claim" will need to defined if
> any such requirement for UAAG 1.0 conformance should make it into a future
> SMIL specification, and we hope that the UAWG considers many points in UAAG
> 1.0 negotiable when crafting the minimal conformance claim.
IJ: I have two proposals to address this:
a) Incorporate the appropriate requirements directly into SMIL
2.x and dispense with conformance to UAAG 1.0. UAAG 1.0 may lose
some visibility this way, but the end result may ultimately
benefit the community more since the accessibility requirements
will be part and parcel of the other requirements.
b) Use "partial evaluation": Put as much as possible of the
well-formed conformance claim directly in the SMIL 2.x
specification. Someone claiming conformance to SMIL 2.x would
"inherit" the static part of the claim, and only have to provide
the dynamic information (e.g., user agent version info). For
example, a well-formed conformance claim to UAAG 1.0 requires
the URI and title of the document. Declare these in SMIL 2.x so
that any claim of conformance to SMIL 2.x would inherit them
automatically.
> Many features, though useful, are expensive, and thus when standardized
> minimal conformance claims are issued, it would be very good to ensure that
> either a cost/benefit analysis is done, or that cost/benefit is somehow
> implicit from the process (e.g. through the two interoperable
> implementation rule).
IJ: Are you suggesting that the UAWG do as much as or more than
any other W3C Working Group? I'm not aware (but I could be wrong)
that other Working Groups have to analyze the cost of
implementation. Implementability is certainly important, but
cost analysis is not part of the W3C Process.
> Our biggest problems were with sections 6.1 and 6.2 (DOM conformance), so
> I'd like to call that out now.
>
> Below are comments with specific sections. Anything not specifically
> listed may not have been reviewed (ran out of time), and thus, if you want
> to make sure you get input on a specific checkpoint, let us know:
>
> 1.1 Excellent suggestion/requirement
> 1.2 Excellent suggestion/requirement
> 1.3 Excellent suggestion/requirement
>
> 2.1 Ummm...ok.
> 2.2 Good, with caveats. We have a "View Source" feature that may be
> turned off at the option of the content provider.
> 2.3 Interesting requirement...not something we do in all cases today, but
> there's a strong case for this.
> 2.4 See issues raised in Ian's meeting notes:
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0044.html
> 2.5 Good recommendation (though I'm assuming this is required only for
> tracks specifically marked as captions)
> 2.6 This is what we do for a living :)
IJ: And this is what *I* do for a living. <wink>.
> 2.7 Ok...good as lower priority
> 2.8 Ok...good as lower priority
> 2.9 Ok...good as lower priority
> 2.10 Not clear on the benefits...
IJ: This is intended for users who access content serially (e.g.,
users who are blind and using speech synthesis or Braille
output). If junk is rendered (namely junk characters), these
users may have to "wade through it" until they get to useful
content. This checkpoint is designed to cut out the junk.
> 3.1 Hopefully not applicable to SMIL, since there's no concept of a
> "background image" in the same way that HTML has this.
IJ: Probably not, then.
> 3.2 Difficult to apply to a SMIL playback environment in a useful
> way. Unlike HTML, *all* media (text included) is done as included media
> which the SMIL engine itself has little knowledge of.
IJ: Here's how I imagine it happening: the SMIL player is
configured not to render video, for example. So instead of
handing off video to whatever piece of software handles video,
the SMIL player renders a placeholder instead. The video may be
rendered on request by invoking the same video player manually
Is that an incorrect view of the world?
> 3.3 Seems mutually exclusive with 2.5. May require changes to
> client-server protocol for RealText, seems very difficult for Live Text
> applications, and may not be possible in other settings.
IJ: They may be mutually exclusive. These are cross-disability
guidelines, so different checkpoints are intended to help users
with different disabilities. It is likely that users would not
want all of the required configurations "on" in all
circumstances. It doesn't mean that the checkpoints contradict
each other, however.
> 3.4 & 3.5 Our player is all about dynamic content (audio/video enhanced by
> other media) and all content is handled in one plugin or another, so
> clarification of the applicability of this particular checkpoint would be
> useful. It seems as though encouraging alternate HTML equivalent versions
> may be a more useful alternative to getting too carried away implementing
> the letter of the law here.
IJ: Checkpoint 3.4 does *not* include plug-ins (and this should
be made clearer. The checkpoint refers to excecutable content,
and plug-ins (in this document's model) are not content: they are
components of the conforming user agent. The user chooses to
install or not install plug-ins. This is different from having
applets buried in content.
For 3.5, is the "protocol" for the real player this:
a) Client requests content
b) Server starts sending content and doesn't stop until
the client says so, or there's an error, or the server
doesn't have any more content.
In this case, I would argue that the initial request for content
is the only one from the client. Thus, there is no client-side
content refresh.
Or, is the scenario different, and the client software issues
periodic requests for content? This is the scenario we intend to
cover by checkpoint 3.5.
I welcome your comments on how it really works...
> 3.6 Not sure why distinction between client-side and server-side redirects
> is useful. This feature is easy enough to add, but doesn't seem to have a
> lot of bang for the buck, and just creates one more moving part on a user
> agent that can break.
IJ: Server-side redirects are not controlled by the
client. Therefore, there's nothing the client can do about
it. Client-side redirects are controlled by the client.
> 3.7 Not as applicable to SMIL as HTML. In a simplified view of the world,
> HTML has text content, with images as decoration or buttons that are easily
> replaced by text equivalents. SMIL is nothing but media objects, where
> text and images are peers, and are often indistinguishable from other each
> other or other media by the SMIL renderer (e.g. the "img" tag is syntactic
> sugar for the "ref" tag)
IJ: See my comment above about handing off control to other
rendering engines. If the SMIL engine has been configured to not
render images, when it encounters an <img> element, it can render
a placeholder instead. SMIL engines should have control at this
level since they do things like lay out content. So they can lay
out a placeholder instead of calling another piece of software.
Please let me know whether this is indeed how a SMIL engine would
work.
> 3.8 Ok
>
> 4.1 Does the RealPlayer "Zoom" feature qualify here?
IJ: Yes, very much so.
> 4.2 Very difficult feature to support, since many datatypes in our system
> support text in different ways. We can see the benefit, but it would be
> good to ensure that a lower conformance level can be achieved that excludes
> this feature.
IJ: Added as issue 506:
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#506
I think your comment applies to any checkpoint (e.g., 4.1, 4.2,
4.3) where we require "one value" and there might be N
viewports. Would it address your concern if one could satisfy the
checkpoint by doing *better* than a single setting? For instance,
if one could set the text size for each viewport (read: each
rendering component), that would still meet the accessibility
need of having bigger text/ control over colors and font
families.
> 4.3 Since there's no single identifiable "background color" for text in
> SMIL, this is rather difficult (no global color, only on a per region
> basis). HTML also has this problem with tables.
IJ: Added as issue 507
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#507
Does it make sense to say "please use this as the background
color for all regions" in the case of SMIL? That would probably
satisfy the spirit of this checkpoint.
If that makes sense, perhaps some clarification is possible.
> 4.4 Very costly feature. We understand the benefits, but there are lots
> of complications. See Ian's meeting minutes for some examples:
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0044.html
IJ: Your input here on the technical difficulties is critical for
our Working Group as we do not have the expertise that you
do. Can you say a little more about what is difficult:
a) Slowing down video? Audio? Both together?
b) Synchronization issues?
c) Streaming issues?
> 4.5 Difficult feature. We offer a seek bar in our product that allows for
> timeline navigation, complete with buttons to nudge the presentation one
> "increment" either forward or backward, but we don't offer faster than
> real-time rendering.
IJ: It is my understanding that this checkpoint does *not*
require the user agent to play the content faster than the at the
specified rate. I do not believe that the fast forward
functionality is required to do playback as well - only advance
the viewport through the content to another point in time. Of
course, faster playback is a more useful feature.
Please indicate whether your player allows the user to jump
forward in time, and whether you consider that a reasonable
requirement.
As issue 508, I will ask the WG to clarify their expectations
about whether fast playback is required by this checkpoint
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#508
> Just offering seeking support on rectangular region
> animations doesn't seem terribly useful, and creating a programmatic
> interface to datatype plugins that support animations for rewind and
> fast-forward rendering is very difficult.
IJ: The WG has argued that even for rectangular animations, some
users require this control. Your technical input on the
difficulty of creating the interface is important for us to
understand.
> 4.6 Difficult feature.
>
> 6.1 & 6.2 DOM conformance - Our biggest problem is with mandatory DOM
> conformance for XML datatypes. Since our player currently doesn't support
> a DOM or provide access to many bits of functionality that DOM provides,
> this would be a *very* expensive feature to add. However, a programmatic
> interface to the raw source code would be much easier to add, and would
> still give a lot of bang for the buck.
>
> It seems as though some form of access to the raw source should be a
> priority one feature, followed by read-only DOM access as a secondary level
> of conformance. It would be a shame if some level of compliance cannot be
> claimed because of this requirement gating conformance (or if this
> requirement adds enough to the cost of implementation that someone
> evaluating the whole set of checkpoints decides to drop trying to support
> the entire specification).
IJ: I will add this as issue 509
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#509
> 6.3 This is rather vaguely defined -- not sure how one would certify
> conformance to this checkpoint. Also, "operating environment" is
> tricky...for applications such as ours trying to provide cross-platform
> APIs, to say that the operating system vendor, for example, can define a
> "standard" API which must be adhered to makes it virtually impossible to
> comply on all platforms.
IJ: Because UAAG 1.0 is format and platform independent, we are
not able to say: use API Y on platform Z. We must live with a
certain amount of ambiguity, which we hope translates as
flexibility. We point out this feature/limitation in the
definition of "API":
"... this document does not define in all cases how those APIs are
standardized (i.e., whether they are defined by specifications such
as W3C Recommendations, defined by an operating environment vendor,
de facto standards, etc.)."
I think that certification is not impossible. Platforms have
guidelines for APIs, and it would be fairly easy to document that
an API has been widely adopted, or formally standardized, or is
part of guidelines for implementing on a particular platform.
> 6.4 Programmatic read/write access to user agent controls - Doable for most
> controls, but becomes pretty unfunctional as the complexity of the controls
> increases.
>
> 6.5 Programmatic alert of changes to content, user interface controls,
> selection, content focus, and user interface focus - the granularity of
> notification would need to be defined in order to understand the cost of
> providing conformance.
IJ: I think that most of this comes for free by using certain APIs
such as MSAA or the DOM.
> 6.6 - Implement standard accessibility APIs (e.g., of the operating
> environment). Where these APIs do not enable the user agent to satisfy the
> requirements of this document, use the standard input and output APIs of
> the operating environment. Not sure what this means to an application like
> RealPlayer.
IJ: An accessibility API on Windows is MSAA. For Java, there's
one as well. For example, I think you get MSAA for free by using
standard Windows user interface controls.
> 6.6, 6.7, 7.1, 7.2 Implementing or don't disrupt various OS accessibility
> conventions. - Once again, these get *extremely* difficult for those trying
> to build one codebase that functions across Win/Mac/and multiple Unix
> flavors. In designing a cross-platform application, a product may opt for
> consistency for ease of development and/or usability. X-plat may make some
> OS features unavailable, unattainable or tether a product to the OS
> manufacturer's demands/designs; not always a positive outcome.
IJ: Added as issue 510
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#510
I believe we've discussed this before, but I think that the WG
should confirm (and state clearly in the document) how
cross-platform considerations and following conventions interact.
> 6.8 For an API implemented to satisfy this doc, support the character
> encodings required for that API. - this is rather vaguely worded, and if we
> understand, doesn't add anything. If an API requires a certain character
> encoding, then implementing it in a conformant way would necessarily mean
> satisfying this requirement, without the existence of this
> requirement.
IJ: Yes. This is exactly the case. The I18N WG requested that we
include this special case checkpoint in the document.
> 8.1 Implement the accessibility features of all implemented specifications.
> Plugin architectures allow the addition of non-compliant components --
> voiding the warranty on the entire application?
IJ: No, you can exclude the plug-in from the claim.
> This requirement points out the need for standardized minimal
> conformance statements, in which the required set of supported
> datatypes/specifications is enumerated.
IJ: I'm not sure yet how we would do that since this document is
supposed to be useful to many different types of user agents
(though not all) implementing current and future formats on
current and future operating environments.
> 9.1 Good requirement
>
> 9.2 Allow the user to move the content focus to any enabled element in the
> viewport. - Good requirement -- authoring guidelines probably very
> important to really make anything useable after satisfying this requirement.
>
> 9.3 For each state in a viewport's browsing history, maintain info about
> point of regard, content focus, user interface focus, and selection
> -- hmmmm...this is a bit of a "history tax".
Nice term!
> If adding a history mechanism causes a user agent to go out of
> compliance until they implement this feature, the temptation may be
> to just not have a history mechanism. A generalized, robust way of
> implementing a history mechanism for plugins is not easy.
IJ: UAAG 1.0 does *not* require that the user agent implement a
history mechanism. Only that if implemented, it must satisfy the
requirements of checkpoint 9.3. I believe this is editorial and
should be clarified. The checkpoint used to say "For user agents
that implement a history mechanism..." and it appears as though
this type of statement would make the checkpoint clearer.
Note that checkpoint 11.5 confirms this: if a history mechanism
is implemented, the default input configuration must include
bindings to go back and forth in the history (of each viewport).
> 10.1 states "This checkpoint refers only to table information that the user
> can recognize"... Shouldn't this be "user agent" as specified by the
> Glossary definition of recognize?
IJ: Yes! This is a bug. Good catch (hey, you must actually be
reading the document <grin>).
Strictly speaking, the sentence isn't necessary at all, but some
checkpoints have been questioned so often, we have special
reminders in their Notes. But applicability works for all the
checkpoints.
> 10.2: In theory this is a reasonable demand; however, it may need SMIL
> clarifications--there's no general purpose way to inform visually of focus
> and linked areas in SMIL.
IJ: Can you explain what you mean by "there's no general purpose
way"? Is that for reasons cited above: different handlers handle
different media types? If that's the case, it's up to each
handler to include a focus mechanism.
> 10.3: This seems reasonable, but rather unprecedented in all current
> browsers. Also, this seems to imply that all datatypes must support the
> ability to identify recently visited links.
IJ: The format doesn't support the notion of recently visited link;
it's the user agent that tracks what the user has visited recently.
It may be unprecedented, but it may also be very inaccessible that
way.
> 10.7: see 10.2 comments.
>
> 11.1: Excellent recommendation
>
> 12.1 Excellent recommendation
> 12.2 Excellent recommendation
> 12.3 Excellent recommendation
>
> We hope this helps. Let us know if any of these points need further
> clarification or discussion.
It helps a lot Rob! Thanks again (and see my embedded questions).
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Friday, 11 May 2001 22:29:43 UTC