W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Real Player Implementation Review

From: Madeleine Rothberg <madeleine_rothberg@wgbh.org>
Date: 02 Feb 2000 11:51:44 -0500
Message-ID: <-1262630195madeleine_rothberg@wgbh.org>
To: "W3C-WAI-UA" <w3c-wai-ua@w3.org>
To discharge one of my open action items, here is an evaluation of 
RealPlayer 7 Basic (the free version) against UAAG Candidate 
Recommendation guidelines. I understand that Real is going to do their
own review, but an outside opinion may be helpful. In one checkpoint, 4.5,
I think the current implementation report mistakenly reports RP as
having a feature that is not present.


Review of RealPlayer 7 Basic
(Real Player Version
With UAAG 1.0 Candidate Recommendation 28 January 2000

1.1 Ensure that every functionality available through the user interface is also 
available through every input device API supported by the user agent. Excluded 
from this requirement are functionalities that are part of the input device API itself 
(e.g., text input for the keyboard API, pointer motion for the pointer API, etc.) 
[Priority 1]
Yes, the UI seems largely accessible. All major functions available through the 
menus and/or using keyboard commands.

1.2 Use the standard input and output device APIs of the operating system.
[Priority 1] 
Seems so, difficult to confirm.

1.3 Ensure that the user can interact with all active elements in a device-independent 
manner.  [Priority 1] 
No. It is not possible to interact with active elements in the media content using the 
keyboard. Only a pointing device can be used to select links and activate buttons.

1.4 Ensure that every functionality available through the user interface is also 
available through the standard keyboard API. [Priority 1]
Yes, as in 1.1

1.5 Ensure that the user interface provides information through redundant
output modes. [Priority 1]

2.1 Ensure that the user has access to all content, including equivalent alternatives 
for content. [Priority 1]
Provides access to some alternative equivalents for media objects: captions are 
available when provided by the author. In addition, the title element of the first 
active media element that has a title in the body of the SMIL file is shown as part of 
the "Clip Info" along with meta data from the SMIL header. 

2.2 For presentations that require user interaction within a specified time interval, 
allow the user to configure the time interval (e.g., by allowing the user to pause and 
restart the presentation, to slow it down, etc.). [Priority 1]
Yes, users can pause and resume (or restart) presentations as needed. No control 
over configuring pauses or slowing down presentation speed, however.

2.3 When the author has not supplied a text equivalent for content as required by the 
markup language, make available other author-supplied information about the 
content (e.g., object type, file name, etc.). [Priority 2]

2.4 When a text equivalent for content is explicitly empty (i.e., an empty string), 
render nothing. [Priority 3]

2.5 If more than one equivalent alternative is available for content, allow the user to 
choose from among the alternatives. This includes the choice of viewing no 
alternatives. [Priority 1] 
Yes, as already noted in the implementation report, RP allows users to select captions 
based on language, however it does not permit choosing any other types of 
alternative equivalents.

2.6 Allow the user to specify that text transcripts, captions, and auditory descriptions 
be rendered at the same time as the associated auditory and visual tracks. [Priority 1] 
Real Player 7 and G2 allow users to specify that captions be rendered, but do not 
allow users to specify that audio description or text transcripts be rendered. (This is 
an amplification of the current implementation report note which lists RP G2 
without caveats.)

2.7 For author-identified but unsupported natural languages, allow the user to 
request notification of language changes in content. [Priority 3] 

3.1 through 3.9 Users cannot turn off rendering of any part of the media presentation 
other than the captions. Unless turning the audio volume to zero counts for 
allowing control of audio.

4.1 through 4.4 No, users cannot configure fonts in presentations.

4.5 Allow the user to slow the presentation rate of audio, video, and animations. 
[Priority 1] 
Current implementation report says RP G2 allows slowing the presentation rate of 
media. I am not aware of this feature, though someone else may know better. 
Perhaps confused with pause/resume, which is explicitly covered in 4.6. I think this 
checkpoint is intended to require setting a presentation to run at half speed, not 
being able to start and stop as needed while running at full speed.

4.6 Allow the user to start, stop, pause, advance, and rewind audio, video, and 
animations. [Priority 1] 

4.7 Allow the user to configure the audio volume. [Priority 2]

4.8 Allow the user to configure the position of captions on graphical displays. 
[Priority 1]
No, users cannot configure the position of captions. It is determined by the author 
and is not changeable in the user agent.

4.9 through 4.11 Synthesized speech not applicable.

4.12 through 4.16 Not aware of any access to style sheets or configuration of focus, 
selection, or viewports.

5.1 through 5.5 Not sure if any DOM or API access is provided.

5.6 Follow operating system conventions and accessibility settings. In particular, 
follow conventions for user interface design, default keyboard configuration, product 
installation, and documentation. [Priority 2]
The user interface follows some system conventions, i.e. underlines accelerator keys 
in menus. Dialog boxes use standard elements. Help is Windows standard help, I 

6.2 Conform to W3C specifications when they are appropriate for a task.
[Priority 2] 
RP uses SMIL for multimedia. May not be a complete implementation of SMIL 1.0. 
RP implements the system-captions flag of SMIL 1.0, but does not thoroughly 
implement other forms of alternative equivalents. (e.g. title, alt).

7.1 Allow the user to navigate viewports (including frames). [Priority 1]
Not sure if this is applicable.

7.2 For user agents that offer a browsing history mechanism, when the user returns 
to a previous viewport, restore the point of regard in the viewport. [Priority 1] 
No, when navigating back to a previous clip the clip is played from the beginning, 
not from when it was paused. Charles noted that this was a question the Real
Player developers raised. I think that for media as well as for documents this 
requirement is valid. If a long presentation has time-dependent links, you 
wouldn't want to have to navigate through the whole presentation to get back
to the point you were at before following a link. I can see that this is not
applicable to live broadcasts, but I think it is applicable to all others.

7.3 through 7.7 No navigation or structure other than using the mouse to click 
author-defined links or active areas.

8.1 Make available to the user the author-specified purpose of each table and the 
relationships among the table cells and headers. [Priority 1]
Not applicable.

8.2 Indicate to the user whether a link has been visited. [Priority 2]

8.3 Indicate to the user whether a link has been marked up to indicate that following 
it will involve a fee. [Priority 2]
Don't know if this is applicable. Is Micropayments included in SMIL?

8.4 Make available to the user information that will help the user decide whether to 
follow a link. [Priority 3] 
No, no info available before selecting on length of clip, location of resource, type of 
resource, availability of alternative equivalents, etc.

8.5 Provide a mechanism for highlighting and identifying (through a standard 
interface where available) the current viewport, selection, and content focus. [Priority 1]
Viewport (i.e. application window) is identified in the OS standard way. Selection 
and focus are identified in user interface elements. Selection and focus are not 
identified within content.

8.6 Make available to the user an "outline" view of content, built from structural 
elements (e.g., frames, headers, lists, forms, tables, etc.) [Priority 2] 

8.7 Provide a mechanism for highlighting and identifying active elements (through 
a standard interface where available). [Priority 2] 
Active elements only highlighted if author specifies, I believe, and then only on 

8.8 Allow the user to configure the outline view. [Priority 3]
Not applicable, since there isn't an outline view.

8.9 Allow the user to configure what information about links to present. [Priority 3] 

9.1 Ensure that when the selection or content focus changes, it is in a viewport after 
the change. [Priority 2]

9.2 Prompt the user to confirm any form submission triggered indirectly, that is by 
any means other than the user activating an explicit form submit control. [Priority 2] 
Not applicable, no forms in SMIL.

9.3 Allow the user to configure notification preferences for common types of content 
and viewport changes. [Priority 3]

9.4 When loading content (e.g., document, video clip, audio clip, etc.) indicate what 
portion of the content has loaded and whether loading has stalled. [Priority 3]
Yes, status bar info available to ATs, includes loading information, elapsed and total 
time, and whether clip is a live broadcast.

9.5 Indicate the relative position of the viewport in content (e.g., the percentage of an 
audio or video clip that has been played, the percentage of a Web page that has been 
viewed, etc.). [Priority 3]
Yes, elapsed time and total clip time available on the status bar.

10.1 Provide information to the user about current user preferences for input 
configurations (e.g., keyboard or voice bindings). [Priority 1] 
Not applicable.

10.2 Avoid default input configurations that interfere with operating system 
accessibility conventions. [Priority 1] 

10.3 Provide information to the user about current author-specified input 
configurations (e.g., keyboard bindings specified in content such as by "accesskey" in 
HTML 4.0). [Priority 2]
No (not applicable in SMIL?)

10.4 Allow the user to change the input configuration. [Priority 2]
Can turn various toolbars on and off and reorder them. No other configurability that 
I found.

10.5 Allow the user to configure the user agent so that the user's preferred one-step 
operations may be activated with a single input command (keystroke, voice 
command, etc.). [Priority 2]

10.6 Follow operating system conventions to indicate the input configuration.
[Priority 2] 
Yes, accelerator keys underlined in menus and dialog boxes.

10.7 Allow the user to configure the user agent through a profile. [Priority 2] 
No (not applicable?)

10.8 Provide default input configurations for frequently performed tasks. [Priority 3] 
Yes, keyboard commands and menu items available for common tasks.

10.9 Allow the user to configure the arrangement of graphical user agent user
interface controls. [Priority 3]
Toolbars can be turned on and off and reordered.

11.1 Provide a version of the product documentation that conforms to the Web 
Content Accessibility Guidelines. [Priority 1]
Uses Windows standard help, not sure if this is WCAG compliant.

11.2 Document all user agent features that promote accessibility. [Priority 1]
Can't assess.

11.3 Document the default input configuration (e.g., default keyboard bindings). 
[Priority 1]
Yes, keyboard section of help gives list of keyboard commands.

11.4 In a dedicated section of the documentation, describe all features of the user 
agent that promote accessibility. [Priority 2]

11.5 Document changes between software releases. [Priority 2]
Yes, Help includes a section called "What's New" which reviews new features and 
changes to the interface.
Received on Wednesday, 2 February 2000 11:53:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:51 GMT