U.S. patent application number 12/469650 was filed with the patent office on 2010-03-25 for systems and methods for a realtime creation and modification of a dynamic media player and a disabled user compliant video player.
Invention is credited to David Martin Anderson, Joseph Jacques-Andre Chamberland, Leonid Geller, Maxim Gubin, David Persing, Michael Anthony PETRO, Keith David Schnable.
Application Number | 20100077322 12/469650 |
Document ID | / |
Family ID | 41340541 |
Filed Date | 2010-03-25 |
United States Patent
Application |
20100077322 |
Kind Code |
A1 |
PETRO; Michael Anthony ; et
al. |
March 25, 2010 |
SYSTEMS AND METHODS FOR A REALTIME CREATION AND MODIFICATION OF A
DYNAMIC MEDIA PLAYER AND A DISABLED USER COMPLIANT VIDEO PLAYER
Abstract
Methods and systems for a disabled user compliant video player
for an end-to-end streaming web video solution affording
accessibility for disabled users, including blind users and those
with partial or poor vision, colorblind users, deaf users and those
limited to only keyboard/voice input. Another embodiment of the
present invention is directed to systems and methods for real-time
creation and modification of specialized media players, to be used
as stand-alone applications or as embedded data display
applications.
Inventors: |
PETRO; Michael Anthony;
(Rockaway, NJ) ; Schnable; Keith David; (Redmond,
WA) ; Persing; David; (Issaquah, WA) ; Gubin;
Maxim; (Forest Hills, NY) ; Geller; Leonid;
(Secaucus, NJ) ; Chamberland; Joseph Jacques-Andre;
(Toronto, CA) ; Anderson; David Martin; (Lynnwood,
WA) |
Correspondence
Address: |
BLACK LOWE & GRAHAM, PLLC
701 FIFTH AVENUE, SUITE 4800
SEATTLE
WA
98104
US
|
Family ID: |
41340541 |
Appl. No.: |
12/469650 |
Filed: |
May 20, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61054794 |
May 20, 2008 |
|
|
|
61055058 |
May 21, 2008 |
|
|
|
61090192 |
Aug 19, 2008 |
|
|
|
Current U.S.
Class: |
715/760 |
Current CPC
Class: |
G06F 3/0482 20130101;
G06F 8/20 20130101; G06F 8/60 20130101; H04N 21/4884 20130101; H04N
21/8543 20130101; H04L 65/4084 20130101; G06F 8/34 20130101; G06F
8/41 20130101; G06F 8/38 20130101; G06F 8/65 20130101; G06F 3/04842
20130101; H04N 21/8193 20130101 |
Class at
Publication: |
715/760 |
International
Class: |
G06F 3/00 20060101
G06F003/00 |
Goverment Interests
GOVERNMENT RIGHTS
[0002] Portions of one or more embodiments of the invention(s)
described herein were made with Government support under contract
GSV06PD00165 awarded by the General Services Administration. The
Government has certain rights in certain embodiments of some of
these invention(s).
Claims
1. A system for dynamically creating a custom media player
application on a computing device, the personal computing device
comprising: a memory for storing a player designer application and
a compiler application; a processor; and a user interface, wherein
a user can use the player designer application to generate a markup
language file and then compile the markup language file into an
executable media player application using the compiler application.
Description
PRIORITY CLAIM
[0001] This application claims priority to U.S. Provisional Patent
Application Ser. No. 61/054,794 filed May 20, 2008, U.S.
Provisional Patent Application Ser. No. 61/055,058 filed May 21,
2008 and U.S. Provisional Patent Application Ser. No. 61/090,192
filed Aug. 19, 2008. All of the foregoing applications are hereby
incorporated by reference in their entirety as if fully set forth
herein.
COPYRIGHT NOTICE
[0003] This disclosure is protected under United States and
International Copyright Laws. .COPYRGT.2008-2009 The FeedRoom,
Inc., All Rights Reserved. A portion of the disclosure of this
patent document contains material which is subject to copyright
protection. The copyright owner has no objection to the facsimile
reproduction by anyone of the patent document or the patent
disclosure after formal publication by the USPTO, as it appears in
the Patent and Trademark Office patent file or records, but
otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
[0004] A media player typically describes computer software used
for playing back various audio and video multimedia files on both
stand-alone computing devices and on computing devices connected to
a network, such as the Internet. Designers of these media players
attempt to tailor the user interface and functionality of their
software applications according to various design preferences
specified by their customers, who are either the hosts or users of
these customized media players.
[0005] Today, many media players are designed to be embedded in
various data displays, such as web pages, electronic programming
guides, and other mobile software applications creating graphical
compositions. The data display platforms associated with these
embedded media players can include specialized scripting which
calls for a media player application resident on a host or client
side, for dynamically embedding the player in a particular data
display. Adobe AIR.TM. platforms such as Flash.TM. (previously
Shockwave Flash, SWF) and Flash Lite.TM. are examples of commonly
used platforms for embedding multimedia content such as streaming
video and audio into web pages. These Adobe platforms utilize the
ActionScript.TM. scripting language to create embedded content that
is capable of playing SWF (.swf) and Flash Video (.flv) data
formats. Other platforms that facilitate embedding media
applications in various web based data displays include: Adobe
Flex.TM., Microsoft Silverlight.TM., and Sun Microsystems
JavaFX.TM., and open source GNU/Linux platforms such as
Moonlight.TM..
[0006] Whether a media player is designed as a stand-alone software
application to be independently executed on a local computing
device or whether a media player is designed to be dynamically
embedded in a web-based data display, the goal of the software
designer remains the same: to custom tailor a media player to best
meet a given customer's needs and preferences. Unfortunately, at
present, a media player customer who desires specialized
characteristics and functionality in their media player (either at
the time of creation or as a subsequent modification), has to
submit these custom specifications to a software designer for
reprogramming, recompiling, and redistribution of a static media
player application. This redesign process is inefficient, time
intensive, and unnecessarily expensive for most media player
customers and applications.
[0007] To remedy the above inefficiencies, it would be advantageous
to facilitate easy real-time creation and modification of custom
designed media players.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 is flowchart illustrating how the Designer, Asset
Manager, and Compiler applications are in communication with the
File System;
[0009] FIG. 2 illustrates a user with access to the Player Builder
application logging into the Player Builder by using a user name
and/or password associated with an approved customer account and
the Player Builder retrieving a list of players from a File
System;
[0010] FIG. 3 is a screenshot of the Player Builder application
illustrating where a user is capable of selecting a "players"
feature for viewing a listing of existing custom media players
associated with player templates stored in the File System;
[0011] FIG. 4 illustrates one embodiment of the Player Listing
template;
[0012] FIG. 5 illustrates one embodiment of the general design
interface;
[0013] FIG. 6 illustrates one embodiment of the Size Design
interface;
[0014] FIG. 7 illustrates one embodiment of the Style Design
interface;
[0015] FIG. 8 illustrates one embodiment of the Content Design
interface;
[0016] FIG. 9 illustrates one embodiment of the FreeForm Design
interface;
[0017] FIG. 10 illustrates one embodiment of the Player Builder
Applications interacting with the Asset Manager and the
Designer;
[0018] FIG. 11 illustrates one embodiment of the Player Builder in
preview function;
[0019] FIG. 12 is a diagram illustrating one embodiment of the
Compiler Architecture;
[0020] FIG. 13 is a diagram illustrating one embodiment of the
Embedded Player Compiler;
[0021] FIG. 14 is a diagram showing the Player File Components;
[0022] FIG. 15 is a screenshot illustrating a web based embedded
player application;
[0023] FIG. 16 is a screenshot showing one embodiment of the
invention utilizing Adobe Flash.TM. Player 9;
[0024] FIG. 17 is another view of the player;
[0025] FIG. 18 is yet another view of the player;
[0026] FIGS. 19-23 are additional views of embodiments of the
player.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
[0027] Embodiments of the present invention are directed to systems
and methods for real-time creation and modification of specialized
media players, to be used as stand alone applications or as
embedded data display applications. In various embodiments of the
present invention these applications can include both host and
client side applications. Example programming platforms that can be
used to realize software applications associated with the systems
and methods of the present invention, include, but are not limited
to, various Sun Microsystems JAVA.TM. platforms and various Adobe
AIR.TM. platforms. In an embodiment of the present invention, a
system facilitating these objectives may include one or more of at
least the following components: a Player Builder, a Designer, an
Asset Manager, a File System, and a Compiler. In accordance with an
embodiment of the present invention, the Player Builder application
is in communication with the Designer application, the Asset
Manager application, the Compiler application, and the File System.
Further, each of the Designer, Asset Manager, and Compiler
applications are in communication with the File System (See FIG.
1). The functionality and significance of these components and
their communications are discussed further, herein.
[0028] The Player Builder application provides an interface for a
user to access and create various media player files using a
personal computing device, such as desktop computer, a laptop
computer, or any other portable computing device. In certain
embodiments of the present invention this computing device could be
an isolated computing device running the Player Builder application
from a local directory. In other embodiments, the computing device
could be a networked device, running the Player Builder application
from a networked directory location.
[0029] The Designer application preferably interfaces with the
Player Builder application to permit a user to actively modify a
selected player file utilizing a variety of design interface tools
that are available to a user in a design mode. The Asset Manager
can be an application which interfaces with the Player Builder and
the Designer applications to allow a user to associate certain
preconfigured assets or media to a select player during a design
mode. The File System facilitates logical storage and retrieval of
all data associated with the systems of the present invention, such
as media files, parameter assets, asset components, player files,
etc. The Compiler can be an application that imports and/or
accesses a user created player data file (e.g., an XML script,
various assets, and other associated data that may be generated by
or referenced with the Player Builder and/or Designer applications,
and then compiles all of this combined data into one executable
custom media player application.
[0030] In accordance with an embodiment of the present invention, a
user with access to the Player Builder application may log into the
Player Builder by using a user name and/or password associated with
an approved customer account (See FIG. 2). Once in the Player
Builder application, a user is capable of selecting a "players"
feature for viewing a listing of existing custom media players
associated with player templates stored in the File System (See
FIG. 3). The media player listing displayed to a user further
provides a user with the ability to redesign, remove, preview, and
export a listed player. A template player listing (See FIG. 4)
provides a user with the ability to select and create a specialized
template media player with preconfigured assets and/or attributes
that meet a user's design preferences. These template media players
provide a relatively quick and easy way for a user to create a
customized media player. In an embodiment of the present invention,
selection of a template player invokes the Designer application so
that a preconfigured template player can be dynamically modified
with various design tools in a design mode.
[0031] A logged in user can also utilize the Player Builder
application to create a new media player by selecting the "create
new player" feature in the Player Builder interface. Selection of
the "create new player" feature invokes the Designer application
which can be run synchronously with the Player Builder application.
In accordance with an embodiment of the present invention a user
can create a new player without using templates or previously
designed media players as a starting point. These new players can
be constructed from scratch, utilizing design tools and
preconfigured player component blocks available to a user in a
design mode. These component block assets can be associated with a
new player under design utilizing the Asset Manager application. In
an embodiment of the present invention, the Asset Manger links a
player identification to selected block component identifications
in the File System, for later retrieval by the Compiler
application.
[0032] Various design interfaces associated with the Designer
application include, but are not limited to, the following
interfaces: General, Size, Style, Content, and Freeform (See FIGS.
5-9). The General design interface (See FIG. 5) includes a
graphical depiction of a media player under design (e.g., a player
based on a previously designed media player in the player listing
(See FIG. 3), or based on a selected player template (See FIG. 4))
and multiple user input areas where a user is capable of entering a
player name and a brief description of a player type. In an
embodiment of the present invention, the player description is
intended to designate a compatibility standard.
[0033] The Size design interface (See FIG. 6) allows a user to
independently size various component block assets associated with a
particular player. Component blocks can comprise various
preconfigured script assets (e.g., interactive command buttons,
slide bars, dials, checkboxes, etc.) and various static parameter
assets (e.g., color schemes, aspect ratios, video and sound
specifications, etc.). An example embodiment of the Size design
interface includes multiple sizing handles associated with
individual component blocks, including: a player window block, a
media window block, and a player controls block. In accordance with
this embodiment, a user can select (e.g., by use of a single-click)
and drag the handles associated with a select component block to a
desired size and position in a design window, to resize the select
component block. The component block assets (e.g., buttons, slide
bars, etc.) dynamically resize to correspond to the size and
position associated with the resized component block.
Alternatively, a user can manually enter height, width, and
positional values directly into a user input sizing window of the
Size design interface, thereby dynamically resizing a component
block and its asset components.
[0034] The Style design interface (See FIG. 7) allows a user to
apply various themes to a media player under design and to various
asset groups associated with component blocks of that media player.
In some embodiments the themes apply to purely aesthetic
characteristics and in other embodiments the themes can alter
functionality associated with player component block assets. The
Content design interface (See FIG. 8) allows a user to associate
select multimedia files (e.g., video and audio files) in a File
System with a particular media player. In an embodiment, the
Content design interface includes various user input areas
associated with a media ID, a media protocol, a host media server,
a URL associated with a media location, and an auto play
preference. Other input areas of the Content design interface can
include various background and video characteristics that a user
can associate with a media player.
[0035] With the Freeform design interface (See FIG. 9), a user can
select various parameters associated with a player window block,
the media window block, and the player controls block of a media
player. In an embodiment of the present invention, these parameters
include component sizing parameters, background colors parameters,
component fill color parameters, and component opacity parameters.
The Asset Manager associates these asset parameters with block
components stored in the File System. After selecting various media
player design preferences in each of the General, Size, Style,
Content, and Freeform design interfaces, a user can save their
associated media player design selections to the File System by
selecting a save feature.
[0036] The Asset Manager application runs synchronously with the
Player Builder and Designer applications (See FIG. 10). In some
embodiments of the present invention, the Asset Manager creates a
logical directory of data associated with a player file in the File
System. This data can include static player parameter assets (e.g.,
color schemes, aspect ratios, video and sound specifications, etc.)
and active player component assets (e.g., interactive command
buttons, slide bars, dials, checkboxes, etc.). In an embodiment, a
logical directory of player asset identifications is linked to a
corresponding player identification in the File System. This asset
to player linking facilitates dynamic retrieval of all data related
to a player file at the time the Compiler compiles a specific user
created player file.
[0037] The Player Builder application's player listing interface
allows a user to view a listing of existing media players in the
File System (See FIG. 3). The media player listing further provides
a user with the ability to modify, preview, remove, and export a
listed player. In an embodiment, when a user selects the modify
option, the Player Builder invokes the Designer application
interface wherein a user can modify and associate various assets
with the component blocks of a select player (See FIG. 10). In a
further embodiment, when a user selects the preview option, the
Player Builder invokes the Compiler to compile a player file and
associated assets to create a preview related to the executable
media player (See FIG. 11). In some embodiments the compiled
preview player is displayed to a user as a scaled up image
representation of what the player's user interface looks like and
in other embodiments the compiled preview is a full executable
version of the listed media player. When a user selects the remove
feature, a selected media player is removed from the listing and in
some embodiments the File System as well. In an embodiment, when a
user selects the export feature, a user is prompted to designate a
local or remote directory location where to export an executable
version of the listed media player.
[0038] When invoked, the Compiler application (See FIG. 12) imports
and/or accesses source code from a designated player file as well
as static and active player asset scripts corresponding to various
attribute and component block assets associated with the player
file. In at least one embodiment of the present invention some of
these assets are stored in a temporary storage area of the File
System. The player file compiles the player file and assets,
creating an executable media player application. In an alternate
embodiment, the Compiler is utilized to create an embedded web
based media player application. In this embodiment, the Compiler
(e.g., a JAVA.TM. based compiler) (See FIG. 13) imports and/or
accesses a player file (e.g., an XML player file) and generates a
custom script wrapper and a web based platform compatible player
file, used by a cross platform compiler (e.g., an Adobe Flash.TM.
based compiler) to call player assets and script components and
then compile the combined information into a web based embedded
player application (See FIG. 15).
[0039] In accordance with an embodiment of the present invention,
an example media player file includes both built in and externally
input parameter asset files, a parameter cache, and various
component assets (See FIG. 14). After initialization of the media
player all parameters are stored in a parameter cache area of the
player. Component assets communicate with each other indirectly
(e.g., as class objects) when parameter changes are detected in the
player.
[0040] In 1998, Congress amended the Rehabilitation Act to require
Federal agencies to make their electronic and information
technology accessible to people with disabilities. Inaccessible
technology interferes with an individual's ability to obtain and
use information quickly and easily. Section 508 was enacted to
eliminate barriers in information technology, to make available new
opportunities for people with disabilities, and to encourage
development of technologies that will help achieve these goals. The
law applies to all Federal agencies when they develop, procure,
maintain, or use electronic and information technology. Under
Section 508 (29 U.S.C. .sctn.794d), agencies must give disabled
employees and members of the public access to information that is
comparable to the access available to others.
[0041] Therefore, methods and systems for a disabled user compliant
video player for an end-to-end streaming web video solution
affording accessibility for disabled users, including blind users
and those with partial or poor vision, colorblind users, deaf users
and those limited to only keyboard/voice input is also disclosed
herein. The Video Player advantageously addresses the individual
needs of all of these users, and, in some embodiments, is compliant
with Section 508 of the Rehabilitation Act, as amended in 1998, and
in embodiments is compatible Level of "Triple-A*" for the W3C's Web
Content Accessibility 1.0 Guidelines.
[0042] The video player is preferably the Access Player developed
by FeedRoom but may be any video player used for video over a data
communication link, an Internet or an Intranet. The video player
preferably is configured to play a plurality of formats of web
video and multimedia, and is configured to be used by with persons
who have disabilities. The player is compliant with Flash as well
as other video formats, and is capable of displaying closed
captions.
[0043] The player is fully functional with multiple file formats
and operating systems, but is preferably compatible with FLV and
DFXP files. It provides a means for disabled end-users to access
and consume the video content, with, or without, the use of
Assisted Technologies (AT). The end-to-end solution encompasses
placing an accessible link on the client's site (home page, and/or
library page) to an accessible Representation of the stories in
their Library (the `Access Map`). The Access Map will preferably be
dynamically generated from a special Data feed of the client's
Library contents (the 508 Data feed), and will include links to an
accessible RSS feeds page, an accessible Help page, as well as to a
Access Player, capable of displaying synchronous captions for any
video for which such associated metadata is available.
[0044] The player further includes player metric ping
functionality; RSS pages; smart re-sizing of full-screen
components, and/or tool tips for player controls. The player
further includes the ability to pass in a parameter (into the
Access Map) that would hide the left column of channel navigation,
essentially turning a multi-channel Access Library into a
single-channel Access Showcase.
[0045] The video player preferably contains, but is not limited to,
three main components: an Access Bar, an Access Map and an Access
Player. An Access Bar is generally a persistent link that is placed
at the top of a client's Library page (it can also be placed
elsewhere on the client's web site), and links to the client's
Access Map. An Access Map is preferably an Representation of the
client's library that is advantageously presented in a fully
compliant manner, and provides navigation between channels of
client-specific content, and for each video, provides a summary,
thumbnail (which can include alt-text), and links to transcript
files and the Access Player. A fully-accessible Help menu and
RSS-links are available from the Access Map as well. An Access
Player is the video player itself and can allow for the
presentation of video with synchronous controls, can offer
full-screen viewing mode, can offer the ability to e-mail links to
specific videos and can reveal embed codes for including the Access
Player on blogs or other web sites. All of this is advantageously
accomplished while maintaining the highest level of accessibility
to the broadest range of users.
[0046] In one embodiment, the digital player includes a feature
that ensures non-text elements have a text equivalent, so that, for
example, a blind user could use screen-reading technology to inform
him of what is on the screen. This would include alt-text for every
image, for example, the Access Map may have a StoryTile image for
every story and a ClientLogo image in the header, at a minimum).
The text used as alt-text for these images would differ from the
text used for, e.g., the headline of Subheadline (this story on
American Reading Habits might have a Headline "Read Any Good Books
Lately?" with a picture of a man on a park bench reading a book,
and the alt-text would be "man reading book on park bench").
Additionally, preferably every window could have a <title>
tag that is descriptive. Additionally, every story may have a link
to a formatted transcript. The player may also include a Flash
Player that is preferably capable of displaying synchronous
captions.
[0047] In one embodiment, the system and method will include
versioning. The product version can be adapted on a per user basis,
allowing for multiple versions to be working at the same time and
further includes a version override mechanism which allows for the
use of particular versions. Further still, the products persist
over time while the versions may change. The product versioning may
include but is not limited to: product version will be implicit and
controlled on per site basis; the version can be set explicitly by
passing variables; the version number may be multiple digits but in
a preferred embodiment is three digits (first designating major
functional product revision, second for minor functional revision
and/or third for bug fixes and minor cosmetic changes); the
implicit version does not have to be the latest version, but is
user and/or developer specific; changing implicit version may have
a mini-release of the skin/property file, with the new version that
is quality assured; version number will preferably not be visible
in the URI; but preferably will be watermarked as an html comment
inside the pages for verification, audit and other purposes; all
parts of the access product (map, FAQ, player, XML landing page
etc) will preferably have to be on same version; moving one will
require moving all to the same version; the actual directory
structure will advantageously be hidden using internal rewrite
rules for link persistence and future compatibility; an/or prior
versions may be eliminated.
[0048] One embodiment of the player may be configured to be capable
of satisfying one or more of the following illustrative
requirements:
TABLE-US-00001 (a) When software is designed to run on a The
FeedRoom Access Help page contains system that has a keyboard,
product functions shall information on enabling full keyboard
access in the be executable from a keyboard where the function
MacOS. itself or the result of performing a function can be Using
FeedRoom Access in conjunction discerned textually. with some
screen reading software preferably uses JavaScript to be enabled on
the web browser to attain full keyboard functionality. Instructions
for doing so are provided. (b) Applications shall not disrupt or
disable FeedRoom Access meets these criteria. It activated features
of other products that are is compatible with the following
operating system identified as accessibility features, where those
and web browser combinations: features are developed and documented
according to Windows Vista industry standards. Applications also
shall not Internet Explorer 7 disrupt or disable activated features
of any operating Firefox 2 system that are identified as
accessibility features Windows XP where the application programming
interface for Internet Explorer 6 those accessibility features has
been documented by Internet Explorer 7 the manufacturer of the
operating system and is Firefox 2 available to the product
developer. Opera 9 Netscape 9 Windows 2000 Internet Explorer 6
Firefox 2 Opera 9 Mac Panther (OSX 10.3) Safari 1 Firefox 2 Opera 8
Mac Tiger (OSX 10.4) Safari 2 Firefox 2 Opera 8 (c) A well-defined
on-screen indication of FeedRoom Access supports keyboard the
current focus shall be provided that moves tabbing. FeedRoom Access
also supports the well- among interactive interface elements as the
input defined on-screen outline that represents current focus
changes. The focus shall be programmatically focus in the Access
Player. exposed so that Assistive Technology can track focus and
focus changes. (d) Sufficient information about a user FeedRoom
Access supports this criterion. interface element including the
identity, operation All non-text elements have associated textual
and state of the element shall be available to information.
Assistive Technology. When an image represents a program element,
the information conveyed by the image must also be available in
text. (e) When bitmap images are used to FeedRoom Access meets
these criteria. identify controls, status indicators, or other
programmatic elements, the meaning assigned to those images shall
be consistent throughout an application's performance. (f) Textual
information shall be provided FeedRoom Access has support for this
though operating system functions for displaying criterion. There
is support for this in text fields (for text. The minimum
information that shall be made example, in certain standard dialog
boxes). available is text content, text input caret location, and
text attributes. (g) Applications shall not override user FeedRoom
Access meets these criteria. selected contrast and color selections
and other Applications recognize operating system settings
individual display attributes. for user-selected contrast, color
and display attributes. (h) When animation is displayed, the
FeedRoom Access can be configured to information shall be
displayable in at least one non- include any animations to display
information to the animated presentation mode at the option of the
user. user. (i) Color coding shall not be used as the FeedRoom
Access supports this criterion. only means of conveying
information, indicating an Although the video duration indicator
and volume action, prompting a response, or distinguishing a level
indicator are presented using color as the visual element. primary
means of conveying information, the video progress is also
indicated by an on-screen time indicator, and the volume level is
indicated by % of max volume, displayed below the volume indicator
bar. (j) When a product permits a user to adjust FeedRoom Access
can be configured to color and contrast settings, a variety of
color permit color or contrast settings. selections capable of
producing a range of contrast levels shall be provided. (k)
Software shall not use flashing or FeedRoom Access can be
configured to blinking text, objects, or other elements having a
include any flashing or blinking elements. flash or blink frequency
greater than 2 Hz and lower than 55 Hz. (l) When electronic forms
are used, the FeedRoom Access meets these criteria. form shall
allow people using Assistive Technology Regarding electronic forms
full keyboard to access the information, field elements, and
accessibility is afforded for all supported OS/web functionality
required for completion and submission browser combinations. of the
form, including all directions and cues. (a) A text equivalent for
every non-text FeedRoom Access includes functionality element shall
be provided (e.g., via "alt", that makes it possible to display
videos and related "longdesc", or in element content). content
within FeedRoom Access that conform to this criterion. FeedRoom
Access users are responsible for ensuring that their video
content's associated images conforms to this criterion. (b)
Equivalent alternatives for any FeedRoom Access includes
functionality multimedia presentation shall be synchronized with
that makes it possible to display videos within the the
presentation. FeedRoom Access Player that conform to this
criterion. FeedRoom Access users are responsible for ensuring that
their videos include associated caption files in DFXP format to
ensue their videos conform to this criterion. (c) Web pages shall
be designed so that all FeedRoom Access supports this criterion.
information conveyed with color is also available The video
duration indicator and volume level without color, for example from
context or markup. indicator are presented using color as the
primary means of conveying information, but the video progress is
also indicated by an on-screen time indicator, and the volume level
is indicated by % of max volume, displayed below the volume
indicator bar. (d) Documents shall be organized so they FeedRoom
Access supports this criterion. are readable without requiring an
associated style by using external stylesheets called via
<link> tags, sheet. and all pages are organized so as to be
readable without the stylesheets. (i) Frames shall be titled with
text that FeedRoom Access supports this criterion facilitates frame
identification and navigation by employing unique IDs for each
<div>. (j) Pages shall be designed to avoid causing FeedRoom
Access supports this criterion. the screen to flicker with a
frequency greater than 2 Hz No elements of FeedRoom Access cause
screen and lower than 55 Hz. flicker outside of the designated
range. User's of FeedRoom Access are responsible for the creation
of the video content displayed by FeedRoom Access. (k) A text-only
page, with equivalent Some embodiments of FeedRoom Access
information or functionality, shall be provided to enable compliant
presentation of FeedRoom make a web site comply with the provisions
of this Library applications. FeedRoom Access can be part, when
compliance cannot be accomplished in automatically updated whenever
the associated any other way. The content of the text-only page
FeedRoom Library is updated. shall be updated whenever the primary
page changes. (l) When pages utilize scripting languages FeedRoom
Access supports this criterion to display content, or to create
interface elements, in that any instance of client-side scripting
has the information provided by the script shall be associated
<noscript> tags providing equivalent identified with
functional text that can be read by functionality. Assistive
Technology. (m) When a web page requires that an FeedRoom Access
supports this criterion. applet, plug-in or other application be
present on the The only plug-in that may be used is Adobe Flash
client system to interpret page content, the page must Player
v9.0+. A link to obtain this plugin, or to provide a link to a
plug-in or applet that complies update an older version, is
provided in a manner with .sctn.1194.21(a) though (1). compliant
with .sctn.1194.21(a) though (1). (n) When electronic forms are
designed to FeedRoom Access supports this criterion, be completed
on-line, the form shall allow people providing both access and
instructions for users using Assistive Technology to access the
requiring AT. information, field elements, and functionality
required for completion and submission of the form, including all
directions and cues. (o) A method shall be provided that permits
FeedRoom Access supports this criterion, users to skip repetitive
navigation links. providing skip instructions where relevant. (c)
All training and informational video FeedRoom Access displays and
multimedia productions which support the synchronous closed
captions for all videos for agency's mission, regardless of format,
that contain which DFXP (Distribution Format Exchange speech or
other audio information necessary for the Profile) caption files
are available. FeedRoom can comprehension of the content, shall be
open or convert many formats of time-stamped transcripts closed
captioned. into DFXP files, and can provide, as a premium service
the creation of time-stamped transcript, or raw transcription
services to assist clients with compliance. (d) All training and
informational video FeedRoom Access allows for links for and
multimedia productions which support the compliant transcript files
for every video. agency's mission, regardless of format, that
contain FeedRoom can assist in the creation and/or hosting visual
information necessary for the comprehension of such files, if
needed, to assist clients with of the content, shall be audio
described. compliance. (e) Display or presentation of alternate
text The display of closed captions, for videos presentation or
audio descriptions shall be user- having associated DFXP files, is
selectable by the selectable unless permanent. user in FeedRoom
Access. (a) At least one mode of operation and FeedRoom Access
supports the criterion, information retrieval that does not require
user with few exceptions, allowing the use of screen vision shall
be provided, or support for Assistive readers to access user
interface information. Technology used by people who are blind or
Commonly-used Assistive Technology (AT) may visually impaired shall
be provided. be used with FeedRoom Access. Users of AT should
contact their AT vendor to assess the compatibility of their
product with various web browsers to learn how to adjust their
settings to optimize interoperability. Known exceptions, including
the use of JAWS screen reader with the FireFox web browser, are
noted in the FeedRoom Access Help FAQ. (b) At least one mode of
operation and FeedRoom Access supports this criterion, information
retrieval that does not require visual affording system large font
settings, high contrast acuity greater than 20/70 shall be provided
in audio settings, and other
display settings used by visually and enlarged print output working
together or impaired customers, including a full-screen viewing
independently, or support for Assistive Technology mode. used by
people who are visually impaired shall be provided. (c) At least
one mode of operation and FeedRoom Access supports this criterion.
information retrieval that does not require user FeedRoom Access
provides the means for hearing shall be provided, or support for
Assistive including formatted transcripts for videos, as well
Technology used by people who are deaf or hard of as the display of
synchronous, on-screen captions, hearing shall be provided in a
manner that does not interfere with the presentation of video. In
all instances where FeedRoom Access provides an audio cue, a visual
cue is provided as well. (d) Where audio information is important
FeedRoom Access supports this criterion. for the use of a product,
at least one mode of Audio information is not important for the use
of operation and information retrieval shall be FeedRoom Access,
and text-based alternatives provided in an enhanced auditory
fashion, or (transcripts and synchronous captions) are provided
support for assistive hearing devices shall be for as described in
.sctn.1194.31(c) herein. provided. (e) At least one mode of
operation and FeedRoom Access supports this criterion. information
retrieval that does not require user FeedRoom Access does not need
speech interaction speech shall be provided, or support for
Assistive for any functionality, but is compatible with Technology
used by people with disabilities shall commonly-used AT for
navigation, control and be provided, inputting text into forms. (f)
At least one mode of operation and FeedRoom Access supports this
criterion information retrieval that does not require fine with few
exceptions. All functionality is possible motor control or
simultaneous actions and that is using only a keyboard, or
alternate AT input operable with limited reach and strength shall
be devices. One known exception is a security provided. limitation
imposed by Adobe's Flash plug-in to allow keyboard input when
full-screen mode is invoked.
[0049] The preceding illustrative features may satisfy some
accessibility requirements. Other possible embodiments may
incorporate one or more of these features to satisfy alternate
existing or future accessibility requirements.
[0050] While the preferred embodiment of the invention has been
illustrated and described, as noted above, many changes can be made
without departing from the spirit and scope of the invention.
Accordingly, the scope of the invention is not limited by the
disclosure of the preferred embodiment.
* * * * *