RealNetworks' review of UAAG 1.0

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.

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).

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  :)
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...
3.1  Hopefully not applicable to SMIL, since there's no concept of a 
"background image" in the same way that HTML has this.
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.
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.
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.
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.
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)
3.8  Ok

4.1  Does the RealPlayer "Zoom" feature qualify here?
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.
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.
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
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.  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.
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).

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.

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.

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.

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.

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 existance of this requirement.

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?  This requirement points 
out the need for standardized minimal conformance statements, in which the 
required set of supported datatypes/specifications is enumerated.

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".  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.

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?

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.

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.

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.

Thanks
Rob

Received on Thursday, 10 May 2001 03:31:03 UTC