Before the
Federal Communications Commission
Washington, D.C. 20554
In the Matter of Implementation of Sections )
716 and 717 of the Communications Act of )
1934, as Enacted by the Twenty-First ) CG Docket No. 10-213
Century Communications and Video )
Accessibility Act of 2010 )
)
Comments of the
Rehabilitation Engineering Research Centers on
Universal Interface & Information Technology Access (RERC-IT)
and Telecommunications Access (RERC-TA)
Gregg C. Vanderheiden, Ph.D.
Principal Investigator, RERC-IT
Co-Principal Investigator, RERC-TA
Trace R&D Center
University of Wisconsin-Madison
1550 Engineering Dr.
Madison, WI 53706
Christian Vogler
Co-Principal Investigator, RERC-TA
Gallaudet University
800 Florida Ave., NE, SLCC 1116
Washington, DC 20002
Introduction
A. About the IT and Telecom RERCs
The Rehabilitation Engineering Research Center (RERC) on Universal Interface
and Information Technology Access at the University of Wisconsin?s Trace R&D
Center, and the RERC on Telecommunications Access, a joint project of the
Trace Center and Gallaudet University, commend the Federal Communications
Commission (FCC or Commission) for seeking broad input from the public on the
advanced communications provisions of the Twenty-first Century
Communications and Video Accessibility Act of 2010 (the ?Act?).1
The Trace R&D Center has been working in the area of technology and accessibility
for over 30 years and it was this Center that created the initial accessibility features
(e.g., mouse keys, sticky keys) that are now built into every copy of the Windows
operating system, the Macintosh operating system, Linux, etc. The Trace Center
also created the first set of Web accessibility guidelines in 1995 and has worked with
over 50 companies in building accessibility directly into their products. Cross-
disability accessibility features developed by the Trace Center can also be found in
automated postal stations throughout the country, Amtrak ticketing machines, ATMs,
airport information systems, and voting machines.
Gallaudet and the Trace Center have collaborated on research and development
related to cross-disability access to telecommunication since 1995. The RERC-TA
has carried out research and developed tools and resources related to hearing aid
compatibility, universal design of cell phones, and real-time text, as well as
contributing to international industry standards and government policy initiatives.
1 Twenty-First Century Communications and Video Accessibility Act of 2010, Pub. L. No. 111-
260, 124 Stat. 2751 (2010) (as codified in various sections of 47 U.S.C.). The law was enacted
on October 8, 2010 (S. 3304, 111th Cong.). See also Amendment of Twenty-First Century
Communications and Video Accessibility Act of 2010, Pub. L. 111-265, 124 Stat. 2795 (2010),
also enacted on Oct. 8, 2010 to make technical corrections to the Twenty-First Century
Communications and Video Accessibility Act of 2010 and the amendments made by that Act.
We appreciate the opportunity to comment on the Commission?s Notice of Proposed
Rulemaking on the implementation of the requirements of Sections 716 and 717,
which were added by Section 104 of Title I of the Twenty-First Century
Communications and Video Accessibility Act of 2010 (CVAA).
B. ACS and the CVAA
Advanced communications services and equipment (ACS) are rapidly transforming
the way people in this country and around the world live, learn, work, and relate to
each other. Unfortunately, as Congress found in enacting the CVAA, people with
disabilities have too often been left out of this transformation and, as a result, are
being left further behind in the most important aspects of community life. The CVAA
is designed to stop the exclusion of people with disabilities from the benefits of ACS,
by incorporating accessibility throughout the complex ecosystem that develops and
distributes ACS. The CVAA, and the regulations the Commission will develop to
implement it, is not just about technology specification. Rather, it is about equal
participation in American life. We appreciate the seriousness with which the
Commission is taking its responsibility to develop effective regulations to implement
the CVAA.
III. STATUTORY DEFINITIONS
A. Scope of Coverage
2. Manufacturers of Equipment Used for Advanced
Communications Services (Paragraphs 20-24)
?Manufacturer? (Paragraph 20): We agree that the meaning of the term
``manufacturer'' should be the same as in the rules implementing section 255 as
``an entity that makes or produces a product.'' However, it should be made clear
that many ?products? will be software only. Such Advanced Communication
software products must be clearly covered.
In addition, given the current and growing trend to ?mashup? technology, a
provider of a mashup product may try to claim not to have manufactured anything
? just to have put together different pieces. Such a provider must still be
considered a ?manufacturer? and covered because they have control over the
choice of components they use (like any manufacturer) and have an obligation to
choose accessible components and assemble them appropriately to create a
product that is accessible (like any manufacturer).
?Software? (Paragraph 21): We agree that upgrades to software (OS, user
interfaces, or applications) by manufacturers must be encompassed in the
definitions proposed by the Commission. Upgrades can be used to increase
accessibility (such as the Microsoft service pack no. 1 upgrade to Office 2011
that just added alt text capability to Word and Powerpoint on the Macintosh) or
they can take accessibility away, as has, unfortunately, occurred on numerous
occasions.
We also believe that in some circumstances a manufacturer should be
held responsible for third-party applications and add-ons because of the
interconnected nature of many devices/services and their third-party
components.
? We agree that if a manufacturer or carrier has nothing to do with
the purchase or installation of the 3rd party application, it should not
be responsible for a third-party application purchased separately by
the user and installed on the device.
? However, if a third-party application is bundled or sold with a
device/service, it should be considered part of the product as sold
and the manufacturer should be responsible for its accessibility.
? Moreover, if a manufacturer requires, prefers, or incentivizes (e.g.,
by providing increased speed) a purchaser to use a particular third-
party application in order to use all the features or get all of the
benefits of the device/service, then the manufacturer, rather than
the user is making the choice and the manufacturer should be
responsible.
? Finally, if the manufacturer markets its device or service in
conjunction with the third-party add-on, the manufacturer should be
responsible. Essentially, if the manufacturer uses a third-party
application as a reason to purchase its product, it should be
responsible for accessibility of the third-party application.
?Used for advanced communications services? (Paragraph 22): We believe
equipment need not be capable of offering ACS on a standalone basis in order to
be covered. Increasingly, information and communication technology involves
functionality from different components and layers working together. A web
application is provided from a server, must operate through firewalls and runs
within a browser (platform) on an operating system (platform) on hardware that
may include multiple physical devices. If we only require functions that are
implemented in a single location or divorced from other equipment or systems to
be accessible, we will eliminate most future ICT. All of the components in the
system can and must support accessibility.
?Offers for sale or otherwise distributes in interstate commerce? (Paragraph
23):We agree that the act of a manufacturer's making software available for
download is a form of distribution.
RE: ?what should constitute making software available for download? (Paragraph
23): Making software available for download includes any time that software
goes from a server to the end user equipment, whether the download is
originated by the user, ?pushed? by the manufacturer, or activated by the
equipment itself in an automated fashion that is intended by the manufacturer.
?By such manufacturer? (Paragraph 24): We agree that manufacturers of end
user equipment should be responsible for the accessibility of their products,
including the software, user interface, and applications that they install. We also
agree that manufacturers of software used for ACS that is offered for sale or
otherwise distributed in interstate commerce by such manufacturers and that is
downloaded or installed by the user is covered by section 716(a). Any other
approach would result in ambiguity and an uneven playing field for companies in
the relevant industries who use different models of distribution. Coverage should
not depend on how a manufacturer distributes its ACS software (pre-installed on
the device or installed by the user).
3. Providers of Advanced Communications Services
(Paragraphs 25-27)
Resellers and aggregators (Paragraph 26): We agree with the Commission that
Congress intended to use the term ?provider? broadly ? to include all entities that
make telecommunications services available? under the CVAA. Therefore,
resellers and aggregators should be covered. With modern technologies, it is not
only possible but advantageous to custom build products at the reseller or
aggregator point in the value chain. Providers should not have different
accessibility obligations just because they use different distribution or marketing
models. Similarly, a consumer?s ability to use a device or service should not
depend on its distribution mechanism, which is beyond the consumer?s control or
even knowledge.
?Providers of ACS? (Paragraph 27): We agree that providers include entities that
provide ACS over their own networks as well as providers of applications or
services accessed (i.e., downloaded and run) by users over other service
providers' networks. Such an approach will create a level playing field for the
industry and predictable and interoperable accessibility for consumers. If the
consumer needs to purchase devices and services that are marketed in different
ways or operated in different environments, they need to be sure the pieces in a
function chain will work together and that accessibility will not be blocked or
defeated by a piece of the chain.
As discussed above, we believe there are situations in which a service
provider must be responsible for the accessibility of third party services and
applications. If a third-party application is bundled or sold with a device/service,
it should be considered part of the product as sold and the manufacturer should
be responsible for its accessibility. Moreover, if a manufacturer requires, prefers,
or incentivizes (e.g., by providing increased speed) a purchaser to use a
particular third-party application in order to use all the features or get all of the
benefits of the device/service, then the manufacturer, rather than the user is
making the choice and the manufacturer should be responsible. Finally, if the
manufacturer markets its device or service in conjunction with the third-party add-
on or identifies the third-party application as a reason to purchase its product, the
manufacturer should be responsible.
We agree that "providers of applications or services accessed over
service provider networks'' covers anyone providing any services over any
network. If they are not providing any services over any network, they are not
covered. If, however, a service provider provides a private network, it is still a
service provider?s network. It is now possible to provide private networks that are
disconnected and also private networks that travel over the internet in secure
channels. These should all be considered service provider networks if the
network is provided or maintained by any outside agency or the network travels
over any network provided by an outside entity at any point. If a company has its
own network completely off the grid, that it creates and maintains, and that does
not at any time connect to another grid, it would not be covered.
The terms "providers of applications or services accessed over service
provider networks'' and "providers of advanced communications services'' are
generally identical. Note that both service providers using interconnected
networks and those using non-interconnected networks are covered service
provider networks. The one exception is for an application that may be
downloaded over a network where none of its functionality utilizes the network.
That is, the software would not be considered an ACS product if there is no
difference in any aspect of its operation based on whether it is connected to the
service provider network or not connected to the network. Such software could
be delivered on a CD and run on a computer that was disconnected from all
networks and still function without limitation.
The term ?in or affecting interstate commerce? should be construed
broadly to include both applications used in interstate commerce and applications
used by a user whose business is engaged in interstate commerce.
4. Advanced Communications Services
a. Interconnected VoIP Service (Paragraph 29): We are concerned about item 4
in the Commission?s proposal to define interconnected VoIP as a service that (1)
enables real-time, two-way voice communications; (2) requires a broadband
connection from the user's location; (3) requires Internet protocol-compatible
CPE; and (4) permits users generally to receive calls that originate on the public
switched telephone network (``PSTN'') and to terminate calls to the PSTN. At
some point in the future, the PSTN will be turned off. When it is, all law relying
on this term will have to be rewritten. In order to allow for future developments,
Clause 4 should, therefore, be changed to say ?PSTN or its successors.? In
addition, the term ?generally? in clause 4 is rife with danger of
misinterpretation/over-interpretation and should be removed. A VoIP service
either does or does not allow users to make calls. If it allows some people to ever
make calls, it should allow all people to make calls, including people with
disabilities. The term ?generally? should be removed making the revised item 4
read: (4) permits users to receive calls that originate on the public switched
telephone network (``PSTN'') or its successors and to terminate calls to the
PSTN or its successors.
Section 255/Section 716 (Paragraph 30): We agree that multi-purpose devices
should be subject to section 255 to the extent that the device provides a service
that is already subject to section 255 and subject to section 716 to the extent that
the device provides ACS. The two sections together should be interpreted to
cover all the communication functions of the device. It should be noted however,
that once all the ACS functions of a device are accessible, making the
telecommunications functions (covered under 255) accessible becomes much
more readily achievable. Also, it would seem to be in the best interest of the
designers to create products that operate uniformly throughout their
functionalities, rather than have something designed to behave differently for
different portions that are covered by different laws. Finally, the engineers
designing these devices are not usually in a good position to legally judge which
of the interconnected functions are in one category or another. For example, if a
webpage provides a phone number you can click, when you click the phone
number, the product should not suddenly become inaccessible because you
invoked the telecommunications function of the product. Thus, we agree with the
AT&T interpretation as long as the ?functionality of the ACS is not compromised
by application of a lesser 255 standard for functions that are integrated directly
into the ACS.? Thus, someone creating a unified communication package where
the telecommunications and messaging are integrally intertwined or merged
should have to follow the higher of the two standards.
b. ?Non-interconnected VoIP service? (Paragraph 31): We are concerned about
the last clause of the proposed definition, stating that non-interconnected VoIP
?does not include any service that is an interconnected VoIP Service?. This could
be interpreted to mean that if you have a service that includes both
interconnected and non-interconnected VoIP, then all the non-interconnected is
exempt because it is bundled with an interconnected VoIP service.
Instead, each service provided in the bundle should be treated separately,
even if the bundle is called by a single name. With that approach, all of the
services would either fall under the rules of interconnected VoIP or fall under the
rules for non-interconnected. In the same way that industry sought to not have
the rules for one apply to the other by association, non-interconnected services
should not be excluded from rules by being associated with an interconnected
service. Non-interconnected VoIP should be defined simply as ?any VoIP
that is not interconnected VoIP?. Anything else creates unnecessary gaps in
coverage. The two (interconnected and non-interconnected) should be
comprehensive and exhaustive so that together they cover all VoIP. The
proposed definition does not accomplish that goal and threatens to leave some
VoIP without any coverage.
Purely incidental VoIP components (Paragraph 32): We believe that non-
interconnected VoIP should include incidental VoIP components. We are
concerned that excluding ?purely incidental VoIP? components would allow a
significant VoIP product or service to be exempted simply by attaching it to
something larger. For example, attaching the computer to a refrigerator does
not, and should not, exempt the computer from the requirements (e.g., RF
interference) for computers. Similarly, waivers based on whether a device or
service is primarily for purposes other than using advanced communications
service should be narrowly and strictly applied. In the future, all technologies will
be highly integrated. Therefore, it is important for the FCC to create strict
guidelines for waivers in order to prevent the exceptions from swallowing the
rule. Purely Incidental VoIP should be VoIP that a user might do with a product
but that was not the intent of the manufacturer. Intended VoIP functionality
should never be classified as ?incidental? and should be available to all.
c. Electronic messaging service (Paragraph 33): We generally agree the
Commission?s proposed definition of electronic messaging service. However, the
exclusion (of ?blog posts, online publishing, or messages posted on social
networking websites?) should be characterized by operational characteristics,
rather than by name. For example, social networking websites now include email
and chat, which are explicitly listed as being included as electronic messaging
services. In the future, these terms are likely to become obsolete and blurred as
new technologies and terms come into play. The Commission should endeavor
to avoid problems such as those created by the Americans with Disabilities Act?s
reliance on terms and examples in common use at the time of enactment to
define coverage, rather than basing coverage on functionality. Instead of
excluding ?blog posts, online publishing, or messages posted on social
networking websites? the commission should use language like ?information that
is posted to a location where it is expected to be found and read by many people
over an extended period of time, rather than information directed to specific
individuals or expected to be read and responded to or acted upon immediately
after posting?
?Between individuals? (Paragraph 34): The comments cited are unclear. If they
refer to situations where there is no human interface ? then we agree. But this
also seems self evident.
However, coverage of something with a user interface cannot be limited to
communications ?between individuals.? A service must be covered if it is
intended to involve a human (even as a backup to a machine) at any point in the
communication. Many communications involve a human communicating with a
machine ( e.g. IVR systems or voice command systems). Many of those involve
a human communicating with a machine that has a human for backup when the
machine is unable to solve the problem, blurring the line between human and
machine. For example, many technology companies have a voice robot answer
the phone and try to interact with you to solve a problem. If it fails a human
comes on to help you. Such systems need to be covered whether the human
comes on or not, and whether there is human backup to the machine or no
human backup. These are still covered by the definitions of ACS.
Much communication today (and in the future) is human-to-machine-to-
machine-to-human. Machine-mediated human communication (an interaction
that requires a human being to do something to the machine to cause the
machine to communicate the person?s desires to the other end) must be covered
and should not be considered machine-to-machine. Technology is fast replacing
human functions and blocking a person?s ability to access a human being until
the machine fails to handle the interaction. Even a personal phone call often
requires moving through a robotic system first.
All of these situations involve tele-communication between or among ?points
specified by the user, of information of the user's choosing, without change in the
form or content of the information as sent and received? and should be covered.
The language should be clear that any interaction that at any point was done
under user control ? is covered and the aspects that involve user control or
interaction much be accessible if achievable.
In response to TIA?s suggestion that services and applications that provide
access to electronic messaging service should not be covered, we note that the
majority of email services in the future are likely to be web-based services. Such
services should not be excluded from coverage, as they would appear to be
under TIA?s proposal. Otherwise, as we move to the cloud, everything will be
excluded from coverage. All elements from the user to the ACS are part of the
ACS value chain and must be covered. If not, the other aspects will not be able
to work and there will be no access to the ACS.
d. Video conferencing service
ii. Video Conferencing Service
Classifying services (Paragraph 36): It is unclear whether the
Commission?s proposal to ?classify? services is intended to mean to ?include?
them or to create different ?classes.? Video conferencing service should be
interpreted to include the broadest range possible because none of the listed
services is likely to exist in its current form in 20 years, but the legislation will still
need to be meaningful. The definition should be wide in order to prevent new
technologies from defining themselves out of the requirements. Classifications,
as in creating a list, would be dangerous because it would lead to exclusion of
services whose development is not yet foreseen or that are inadvertently left out
of the list. We recommend against creating any classes, because there should
be a level playing field for all the players providing these services. In addition,
technology has a wonderful way of flowing around any obstacles, and creating
classes with different rules will create confusion each time a new service that
doesn?t have one of these names and isn?t exactly like one of these is created.
For example, a technology that includes elements from two or more classes
could be argued not to be covered by any list that included the two classes
independently. Alternately, adding a small element from a class with lower
coverage could be used to pull a service out of needing to conform to the proper
set of rules.
Video relay services (Paragraph 37-40): We agree with the consumer
groups that VRS services are covered - the video leg of the VRS meets the
definition. Further, individuals who are deaf have unfortunately not been given a
get-out-of-jail-free card for other types of disabilities, nor from the effects of
aging. To say that a system for the deaf should be exempt from other types of
accessibility would be to deny the human condition or to claim that deaf people
are exempt from it.
Web conferencing service (Paragraph 41): We agree with consumer
groups that webinars are covered. Web conferencing systems are not designed
to broadcast information, but rather to provide user interaction in the form of chat,
voting, and hand-raising, etc. While it is possible that webinar systems could be
used in a one-way communication scenario, they are designed and used often to
allow two-way information transfer -- and that intention and use determines
coverage. If an application has any features for two-way communication, it is an
ACS.
One-way video communication (Paragraph 42): Nor do we believe that
simply the fact that a communication system could be used for one-way
communications removes it from coverage or limits coverage to the two-way or
multi-directional elements. We believe the Commission underestimated its
authority in opining that voice mail was not covered by the Telecommunications
Act and had to be treated within its ancillary jurisdiction. Similarly, video mail
capability included in a video conferencing service is ACS. The accessibility of
the service should not disappear simply because the ?caller? discovers that the
person she?s calling isn?t home. Nor should the recipient with a disability find that
missing the live videoconference means they cannot access it at all, even though
nondisabled participants can view the conference later. The one-way and two-
way functions are integrated and should be subject to the same accessibility
requirements. Video mail is as important as voice mail and should be covered.
Without regulating the video mail aspects of video conferencing, the
Commission?s ability to ensure accessibility of other forms of ACS would be
significantly hindered.
Incidental video connection (Paragraph 43): We disagree with TIA?s
argument that ?incidental? video communication capability should be excluded
from coverage, for the same reasons we disagree with the similar argument
(above) about ?incidental? non-interconnected VoIP. Accepting this argument
would mean an ACS provider could avoid any regulation simply by mounting its
device to a larger non-communication device (like avoiding regulation RF
interference of a computer by mounting it in the door of a refrigerator). Doing so
does not, and should not, exempt a computer from the requirements of
interference or any other regulation of computers.
In the future, we will see unified communication, including more and more
devices that not only combine many separate functions on one device (like
today?s iPhones and Android devices), but integrate them seamlessly with each
other. Take, for example, Facebook and its integration of email and real time
communication in what used to be a pseudo-blog or public diary. In the future, all
functionality will be incidental to the sum of everything that will make up the
product. We will have environments in which many services are mashed-up,
rather than individual products or programs like we have today. If the
communication is truly incidental and unimportant, the manufacturer may choose
to leave it out. If it is important to include it for some people, then it should be
available for all, including those with disabilities. Anything that is designed in
as an intended capability should not be considered incidental. Incidental
should be reserved for those places where users find ways of using a device for
communication where that was not the intent of the manufacturer.
ii. Interoperable (Paragraph 44-47)
The fact that video relay service wasn?t always interoperable from the
beginning was an unfortunate anomaly. All progress in this area is toward
interoperable VRS, including both interoperability among VRS services and
interoperability with the public communication system. Purely for economic
reasons, it is important that deaf people be able to make point-to-point calls with
each other and with other members of the public, (rather than having to always
rely on publicly funded relay services because of incompatible videophones).
In addition, it is important that the equipment that a person is expected to
use in an emergency is the same equipment that people use for every day
needs, because, in an emergency, people will turn to that which they use every
day to make the call. It makes no sense to build next-generation emergency
systems that need to support a variety of different incompatible video
communication systems in order to be able to accept emergency calls from
different deaf callers. Nor should we have an emergency system that is different
from the system used for mainstream video communication calls. Videophone
interoperability is particularly essential in a disaster, because the emergency
systems will be overwhelmed and people who are deaf will need to turn to
anyone who can help them. So their video systems need to work with
mainstream video systems as well as that of other deaf people ? point to point.
Video communication services, therefore, should be required to be interoperable
with each other and with other ACS (mainstream and special).
Regarding the VRS Definition of Interoperability: The VRS definition of
interoperability under Section 255 does not apply here for purposes of
determining whether a video communication service is covered. In the case of
VRS, the Commission is seeking interoperability of all VRS systems (full
interoperability). Because VRS is a public service, and for the reasons discussed
above, it requires full interoperability. The CVAA, by contrast, is determining
coverage, which does not require full operability. Rather, coverage should be
provided whenever there is partial interoperability. If the intent of the CVAA
were, indeed, that the law only apply to interoperable systems, the term would
have been in the definition, as it clearly was in any other definition of concept.
The definition of a term is the definition, not the title of the term.
It appears that the Commission is treating ?interoperable? as having the
same meaning as ?interconnected [VoIP]. Rather ?interoperable? in this context
means the video conferencing system follows some standard that allows it to
work with some product made by some other manufacturer. If the system will
work with any products of any other manufacturer, it is ?interoperable? and
covered. Thus, the law would not apply to a home intercom system with a
camera on it that is proprietary and doesn?t work with anything else. In addition, if
the system maker publishes its standard and/or allows other
manufacturers/service providers to build products/services to work with it, it is
covered. Skype, is made to work with Skype-phones manufactured by others. It
is, therefore, interoperable, and covered.
5. Customized Equipment or Services (Paragraphs 48-50)
All systems are customized ? some more than others. Almost all
enterprise systems have to be customized for each customer. And with the
current technologies, future systems are likely to be even more ?custom systems
for each customer.? We agree that the purpose of this exemption was for highly
customized equipment or software ? not for standard equipment or software that
is being routinely customized to fit each client.
Allowing minor customization done for employers to result in exemption
would result in people with disabilities being unable to work in most future
workplaces. ?Customized? for the purpose of this exemption must mean the
service or device was changed functionally in a significant way for the customer
(not just in appearance, as in adding a logo or color, or having its functions tuned
to customer preferences, or adapted to work with the customer?s other software).
When a service or device meets the definition of customized, only the
customized function should be excepted from coverage.
In addition, we agree with the Commission that ?used by members of the
general public? should be interpreted to include ACS devices and services used
by public or private institutions, such as schools, libraries, and government
agencies, for the use of their customers.
6. Waivers for Services or Equipment Designed for Purposes Other
Than Using ACS (Paragraphs 52-55)
We first address the scope of waivers. If a manufacturer is seeking a ?not
achievable? ruling ? this should not be handled as a waiver because a) it is
already provided for in the law and b) waivers tend to live past the time when it is
?achievable? due to changing technologies.
It is important, in determining the scope of waivers, to consider the scope
of the offerings of a device or service, not just the device or service. The Senate
and House Reports make clear that a waiver is available only for a ?feature or
function of a device that is capable of accessing advanced communications
services but is ? designed primarily for purposes other than accessing advanced
communications.? A device does not become non-ACS simply because it
includes some non-ACS features. If a feature or function is bundled or mashed-
up with other functions, it is still a function or offering in the bundle or mash-up
and should be treated as an individual offering. Adding a non-ACS component
to an ACS device does not exempt the device and nothing in the CVAA would
allow a waiver for the device on that basis. Coverage cannot be avoided by
putting the ACS function into a larger non-ACS device (see the analogy to a
computer in a refrigerator, above). Nor can coverage be avoided by adding a
non-ACS component to an ACS device.
We recommend that each function be considered individually, even if it is
attached to, included with, or mashed up with other functions that are not ACS.
For a particular function or feature to be considered ?primarily for purposes other
than? ACS, and, therefore, excluded from coverage, the removal of the function
would need to have no effect on the ACS functions of the device or service. We
agree that, whether a function is primarily for purposes of ACS does not depend
on how the device is marketed or understood by the general public. As we have
seen repeatedly, a device may initially be marketed with one primary purpose
and later become widely used for another purpose, as customers? interests and
expectations change.
The purpose of the CVAA was to ensure that people with disabilities would
have access to communication functions in their emerging forms. While it would
be beyond the intent of the law to include all of a device?s functions in
accessibility requirements just because there was some communication
functionality, it is not beyond the intent to include ACS functionality that is
specifically included in a product for the purpose of allowing individuals to
communicate with each other. Denying this would mean that people who could
otherwise use the product would be prevented solely because the
communication function was not accessible. Again we note that it is likely that
all communication functions in the future will be bundled into products and
systems that provide many functions, making the communication function a
minority of the total function of the system. Consider a future where there are
panels around a room and you interact with them using gesture, gaze, voice and
keyboard - and all of the functions of your office/classroom/ study carrel, etc. are
provided through those screens and the system behind them. Communication
would be one of the many functions, and must be required to be accessible.
Waivers should not be provided to an intentional communication function
built into a larger non-communication product, but only to non-communication
functions that could incidentally be used to communicate. Examples of elements
that could be subject to waiver include the ability in a game to draw in the sand,
or wipe a dirty window with your finger ? and the fact that one could incidentally
use that to communicate even though that was not the intent of the game
developer.
It is also important to note that once something is waived, it cannot be
taken back. The record is full of decisions that were made early in the life of a
new technology or technique, granting exceptions based on the fact that it
seemed exceptional and was not in widespread use. Later, when the technique
or technology was integrated centrally into education, employment or daily living
routine, it was not accessible because it had been granted an exception early on.
Process, confidentiality, and duration of waivers (Paragraphs 56-57): We
agree that waiver petitions should be subject to public comment. Waivers should
not be kept confidential beyond the release of a product. It is understandable that
waivers might be kept confidential where they would amount to a pre-release of
information about a new product. However, once the product is announced, all
information about the waiver should be released. Waivers also should not be
based on technologies, but only on functionality as discussed in the law. As such,
a review should not require releasing confidential information about the inner
workings of a product.
Expeditious processing and ?deemed? grants of waivers (Paragraph 57-
58): We agree that waivers should not be ?deemed granted.? Such an option
would invite companies to raise the topic very late in product cycle development
for any number of reasons. Instead, companies should be operating under the
assumption that waivers would be rare and fairly predictable. If the function is
being designed by the company as a communication function in the product, then
it would not be incidental and would not be waived. We agree that waiver
requests should be processed expeditiously so as not to encourage
manufacturers to delay implementing accessibility while awaiting a waiver.
We agree that no waiver should be permanent. Waivers should be
reviewed annually with a one-year delay in re-implementation. This approach will
accommodate changes to the technology or its uses and help mitigate the effects
of misjudgments of the impact, utility or essential nature of something which
initially seemed incidental.
Class waivers (Paragraph 59-60): Blanket ?class? waivers should not be
available, particularly on a prospective basis. The goal of the law is to ensure that
individuals with disabilities, including veterans and our rapidly aging population,
are not left out of innovation as it occurs. Innovation happens continually and
what is hard to do one year can be easy to do 3 to 5 years later. Providing a
waiver for a class today because it is either hard ? or the technology does not
seem essential, usually leaves the waiver in place long after something is easy to
make accessible or has moved into our daily lives in an integral way. A hearing
aid compatibility waiver was placed on cell phones when they came out because
they were luxury items. But it stayed in place long after cell phones had become
essential for salesmen, and many other job categories ? and had become an
important safety device as well. Most of the population rides on the wave of
innovation. People with disabilities should be able to as well. Innovative products
are coming to dominate the market, the workplace, the school, and daily life. To
assume that people with disabilities do not need to access innovative
technologies ? when they are introduced - but only to old technologies, would
deny them the ability to compete in these environments. Often, these innovative
technologies are the ones that give individuals with disabilities the capabilities
they need to compete. In addition, the lifecycle of modern technologies is so
short, that delaying access may delay it right past the end of the product life.
Companies will have no incentive to add accessibility to products if they don?t
need to at introduction ? and product lifetime is short.
We also are concerned with the continued faulty logic that if you removed
all accessibility requirements from a category of product it would speed up the
process of bringing benefit to everyone, including people with disabilities. This
has never been shown to be the case. It is true that people with disabilities are
people and, therefore, do benefit from general advances in technology. However,
without accessibility regulations, there are always individuals with disabilities who
are unable to access and use these wonderful new technologies that would be
beneficial to them, if only they could access. Instead what happens is that
everyone without a disability can benefit from these new innovations, while
people with disabilities are continually left at a disadvantage. One example is in
the area of electronic books. Electronic books, and the devices that are used to
read them, offer a tremendous potential opportunity for people with print
disabilities to read the same books at the same time for the same price as
everyone else. However, because accessibility has not been incorporated in the
books, and the software and devices used to read them, people with disabilities
are now two steps behind their peers. Not only is their access to these materials
delayed, but they only get access to a small subset of all the books, periodicals,
and other print materials available to their peers.
We also emphasize that making things accessible does not inhibit
innovation. In fact, it encourages innovation. In addition, adding accessibility has
almost always been shown to increase the understandability, usability, and/or
functionality of products to mainstream users.
?Class? and other generic waivers are not necessary. For those situations where
it truly is difficult to make something accessible, the ?achievable? test is already
available. If it is not achievable, technically or otherwise, it simply is not required.
Documenting this is not difficult in clear cases. Borderline cases do not need to
be documented if access is provided instead.
7. Exemption for small entities (Paragraph 61-66):
We agree with the Commission that there should not be a blanket
exemption for small business. There are many ways that accessibility can be
incorporated even in the work of a small business. A large percentage of the
websites on the Internet, for example, are created by small businesses.
Increasingly, these websites include communication channels. Making them
accessible is not difficult and can be a straightforward part of the web design.
The websites created by these companies are the gateway that people with
disabilities need to be able to pass through in order to access all of the services
and companies that are on the other side. Without accessibility, a significant
portion of commerce, education and services would be blocked from use ? not
just small businesses.
Some services are only provided by small companies in an area.
Providing such a blanket exemption would deny any people with disabilities in
these areas from receiving accessible services of that type entirely. Similarly, to
make all rural communication entities exempt from accessibility would be to
decide that individuals with disabilities in rural locations should all be cut off.
What is of most concern is that rural individuals then would not have any
alternatives to turn to. Disabilities among farmers are not rare, soldiers return to
homes all across America, and the incidence of disability in rural families is the
same as in urban areas. Thus, a significant portion of the population are
represented by rural local exchange carriers.
Often, small businesses are redistributing or applying products designed
by large businesses. They are thus able to drive the accessibility from the large
businesses (if accessibility is required and small businesses ask for accessible
versions from the large businesses). Exceptions for small businesses should
only be done for specific reasons and specific product types where there is a
clear need to provide the exception and consumers have a choice.
A. Nature of Statutory Requirements
1. Achievable Standard
a. General Approach (Paragraphs 67-69)
We agree that adding accessibility should not cause a fundamental
alteration in the purpose or functionality of a product. For example, a company
should not be required to add a display to a product that did not already have a
display where doing so would change the size, shape, weight or price
substantially. For example, a communicator built into a brooch would be
fundamentally altered if one had to add a touchscreen display to it. However, we
have seen companies argue that adding voice output to a product in order to
achieve accessibility was a fundamental alteration because the product did not
talk before the voice was added. The mere addition of accessibility as a
functionality should not ever be deemed to be a ?fundamental alteration.? To be
a fundamental alteration, accessibility would have to materially change the size
or weight, or materially interfere with the functionality of the product.
Other factors (Paragraph 70): We agree that the four factors should be
construed broadly to include and weigh the relevant considerations. When
assessing the cost to add an accessibility feature to a product, however, the cost
should be amortized across the entire number of items sold. That is, considering
whether adding the feature to the product would cause the product as a whole to
increase significantly in costs. To allow companies to load the entire cost of an
accessibility feature on the first units sold to someone with a disability would be
unfair. It would encourage them to not build accessibility into their products, but
rather to add it on for those customers aware enough to ask for it. At this point,
the approach would focus the costs on those few, aware, people/sales and the
costs could be shown to be much greater than the cost of the product. If the cost
to make the product accessible were spread across all of that product sold,
however, the per-unit cost would be negligible. And the increase in cost would
be so small that it would not cause the rest of the customers to not purchase the
product. Further, adding accessibility at a small added cost across all sales
would not cause the manufacturer to lose sales to competitors, because the
competitors will also be compelled to make things accessible. Instead, it would
cause companies to compete (innovate) to figure out how to add the accessibility
into their products in the most cost-effective fashion.
An example of this can be seen in the cell phone industry where
companies are charging individuals who are blind with high costs to make their
individual phones accessible when those costs, if amortized across all the
phones sold, would add a negligible amount to the cost of all the phones and
allow individuals who are blind to purchase phones that were accessible for the
same price as everyone else.
b. Specific Factors (Paragraphs 71-76)
(i) Nature and Cost of Steps Needed with Respect to Specific Equipment
or Service (Paragraph 71): We would concur that it is important to look at the
unique circumstances of each covered entity. However, we believe they should
be looked at absolutely, rather than in a relative fashion. That is, whether it is
achievable for this entity to make its products accessible if the costs are
amortized across the total sales?not whether it is easier for some other company.
A company should not be exempted simply because it is harder for them than it
is for somebody else. If that approach is taken, only one company will be
required to make its products accessible. And no company would design its
products from the ground up to support accessibility at lower cost.
(ii) Technical and Economic Impact on the Operation (Paragraph 72): As
noted above, cost impact should be assessed by looking at the costs amortized
across all of a manufacturer?s products and not just the particular items being
sold to an individual with a disability.
(iii) Type of Operations (Paragraph 73): How recently a company entered
the field should not, in and of itself, provide an automatic exemption or extension.
We believe that the fact that a company just entered the field should be
considered in the total context, but only weighed against other factors. For
example, a very large, well-resourced company entering the field should not be
given a pass. A smaller company, or a small startup that may not realize that its
products even fell into this category, might be given time to learn about the field
and its requirements.
(iv) Extent to Which Offering Has Varied Functions, Features, and Prices
(Paragraph 74-76): We agree that, if features are easy to do, they should be in
all products. It is already possible today to easily incorporate many features
across all products and will become easy for many more in the future. We
disagree that a list of such easy features should be included in the rule, because
what is easy to do is changing so quickly. Things that would have been
expensive and difficult to do four years ago are now done routinely. This is true
for both mainstream features and accessibility features.
We further express agreement with ACB?s statement that ``[i]t is essential
that manufacturers and service providers make available a range of devices that
fit various price ranges along with corresponding accessible features * * * this
may be accomplished by dividing devices into classes and making certain that
each class has at least one option that is fully accessible.'' However, the
?different products across multiple product lines? approach proposed by others is
based on some inaccurate assumptions. The first concern is that company-
chosen sets of devices to be made accessible have not, to date, provided a good
representation of the range of products that the companies offer. Often the
accessible versions don?t even appear in stores, are not available as part of
bundles, and otherwise are much more expensive and difficult to obtain than the
non-accessible products offered to everyone else. Secondly, they don?t
represent the full range of features and prices available to everyone else.
Importantly, employers and others may not allow individuals to purchase any
phone or provide any phone to their customers, but only one or a limited number
of phone models that they want their employees to use and that their IT
department is willing to support. There are also areas of the country and other
factors that can limit the choices available to people with disabilities such that
they cannot get or use the few accessible phones offered.
Any coverage limited to a range of selections needs to specify that it
represents the full feature sets and price ranges and that the accessible phones
will be available in all of the deals and special prices provided. The accessible
phones must be able to be substituted into any deal or special price for similarly-
featured non-accessible devices, including 2-for-1, 5 free with 1, clearance, and
other types of promotions.
2. Industry Flexibility (Paragraphs 77-80)
Nominal Cost: The proposed definition of ?nominal cost? provides insufficient
guidance for manufacturers to be able to assess whether reliance on third-party
accessibility will be acceptable. What is ?nominal? to an industry decision maker,
or even to a person in the general market for an ACS product, will be greater
than what is ?nominal? for a person with a disability, most of whom are poor and
already face greater ?gateway costs? for nearly every aspect of their lives.
Furthermore, cost will not be the only factor that will work to exclude people with
disabilities from getting the needed third-party solutions. We agree with ACB and
the Commission that, for covered entities to meet the ``access'' requirement, they
must ensure that the third party solution not be more burdensome to a consumer
than a built-in solution.
? The third-party solution needs to be readily available along with the ACS
device or service;
? The third-party solution needs to be equally compatible, interoperable, and
simple to set up and use with the ACS device or service;
? The manufacturer seeking to rely on third-party technology for accessibility
should be required to identify, notify customers of, find, install, and support
the third-party technology along with their product ? as they do the built in
features;
? The third-party applications relied on by the manufacturer must have been
tested by the manufacturer for compatibility with other major third-party
applications that will be used on/with the device/service, as would be done
by the manufacturer if the features were built-in;
? Third-party applications must be accompanied by a program to ensure
that the third-party applications the company is relying on (instead of
building the features in) are included in testing models sent to other third
party vendors and used by them in development and compatibility testing
of their software, (where these test models are provided directly by the
manufacturer);
? The third-party accessibility technology relied on by manufacturers must
also be tested and available at the time of the phone?s release, as the
accessibility would be if it were built-in.
If these steps are not taken, then, in fact, the user ends up with a device
that does not work accessibly and there?s nothing the consumer can do at that
point to create compatible access to the device.
3. Accessible to and Usable by (Paragraphs 81-83)
Use of Accessible to and Usable by (81): Given the definitions you are
using, it would create problems if ?usable by? were removed. In addition,
?accessible? is too often equated with ?reachable? (physically or electronically)
and not with it actually being usable in any meaningful or sufficient way.
Preservation of the phrase ?accessible to and usable by? is therefore endorsed.
Definitions of Accessible and usable (82 & 83): We are troubled by
defining conformance to this standard as being ?accessible? but full functionality
being tied to ?usable?. If the standard is to implement the law then conforming to
this set of performance objectives should be defined as making the products
?accessible to and usable by? people with disabilities (for the purpose of this
document). As noted below, conformance to a ?minimum required accessibility
standard? should never be defined as ?accessible? in any absolute sense, only
?as it would relate to this document.?
With regard to differences between the two, the FCC should adopt the
combination that doesn?t leave any disability groups out of protection. Also it
should cover all of the aspects deemed important for product use. Materials and
support are expensive and only provided by companies for mainstream users
because they area deemed important to successful product use. They should
therefore be included in the accessibility coverage here.
5. Compatibility (Paragraphs 85-90)
We agree with the definition of peripheral devices as ?devices employed in
connection with equipment, including software, covered under this part to
translate, enhance, or otherwise transform advanced communications services
into a form accessible to individuals with disabilities.? This reflects more
accurately the situation today where these devices take the form of hardware,
software and services of a broad nature, increasingly involving mainstream
hardware, software, and services. The only suggestion might be to add the term
electronically mediated services to the definition so it reads ?including
software and electronically mediated services.?
We agree that covered entities should not (and could not) maintain an
accurate list of each specialized CPE even if they can track the types and
requirements for supporting compatibility with them.
Regarding definition of customer premises equipment (CPE): the
definition of CPE refers to equipment on the customer?s premises. It is important
to note that their own body is considered part of their premises somewhere in the
definition or notes or all mobile technologies will be excluded.
Regarding TTY compatibility requirements (88): First it is important to
note that TTY is real-time text. TTY-based real time text does not work reliably
on IP based systems and should not be required for IP devices. Instead
compatibility with standard IP-based real-time text format should be required for
IP networked device. Similarly since IP based real time text cannot work at all
on PSTN (except if an IP tunnel is established with a dial-up modem. Even then,
unless the dial-up connection is maintained 24/7, the dial up connection can?t be
used to call someone) the rules should continue to require TTY connectivity and
signal compatibility where IP networks connect to the PSTN.
The four criteria (88): As noted above, TTY does not have any particular
meaning or role in IP based systems (other than compatibility with TTY where the
IP systems connect to the PSTN). The last two criteria should therefore changed
to:
(iii) connectivity to standard IP-based real-time text peripheral devices
where products support voice communication and they do not themselves
provide real-time text send and receive capability
(iv) standard IP-based real-time text signal compatibility
Regarding the definition of compatibility(89): The Access Board definition
is good except that ?assistive technology? should be replaced with ?specialized
CPE and peripheral devices? for this use.
Regarding APIs (90): APIs can facilitate compatibility and reduce the work
needed by both mainstream and assistive technology developers. However,
APIs are neither necessary nor sufficient. It is an excellent idea to encourage
the development and use of APIs. It is not a good idea to require an API nor to
accept that an API, by itself, is sufficient to meet the compatibility guidelines. If
an API is provided that is not supported by any assistive technologies, then the
product is unusable by people with disabilities. Further, a product which does
work with AT, but does not have an API, is usable by people with disabilities. In
fact, in some places (for example compatibility of a device with an assistive
listening device) there is no API involved. An API is only possible with certain
types of AT. Thus an API is a powerful tool for compatibility ? and one that
should be encouraged. However it should not be required or be held as sufficient.
6. Network Features (Paragraphs 91-94)
Impeding accessibility: We agree that the requirement to ?not install
network features, functions, or capabilities that impede accessibility or usability
by people with disabilities? should be included. We do not agree that this
requirement demands extensive outreach on the part of the Commission.
Providers of ACS should be well aware of the regulations applicable to them. To
the extent the Commission desires to remind providers of their responsibilities,
outreach to industry associations should be sufficient. Notably, however, any
lack of outreach by the Commission should not be considered a defense to
meeting the requirements and enforcement should not be delayed or softened
because these are considered ?new? requirements. Industry associations and
trade magazines are well able to get the word out if it is believed that it will be
enforced. And all manner of training programs will appear quickly as well. If
loopholes are provided however, the training programs that appear will, instead,
be training programs in how to exploit loopholes, as evidenced by past
rulemaking.
Industry standards: The past regulatory language highlighted by CTIA (to
only require industry to support standard formats) originated from a desire by
regulators in the past to require industry to support standard modes of
communication with assistive technology, but to not require support of proprietary
formats that AT vendors might create. The Commission should continue to
require that standard formats used in the industry be supported and not require
mainstream industry to adopt every proprietary format that might be introduced
by an AT vendor. There are any number of industry standards in use today for
accessibility (from those used for TTY (TIA-825a) to RTT on SIP (RFC 4103) to
hearing aids (ANSI C.63.19) from a number of sources. (Note that any
restrictions on the requirements (that they be industry standards) should include
both mainstream accessibility standards and standards developed specifically by
or for the AT industry for compatibility and interoperability.
Standards development: The Commission inquired as to who should be
involved in any standards development process. Any standards-development
process for disability access should include equal participation by mainstream
technology company representatives, AT company representatives, and
consumer group representatives. Furthermore the development should be
conducted in such a fashion that travel and other expenses are not a barrier to
participation by consumer groups (e.g., use teleconferences or subsidize
participation by).
Passive inaction: We reaffirm that the rules should prohibit passive
inaction or setting of options and settings that impede access. We should also
note that this problem was brought to our attention by industry (mainstream and
AT industry) who were finding that the passive inaction/setting of options was
blocking communication by people with disabilities. We also join AFB in
highlighting that DRM and network security functions can be installed in a fashion
that is both fully functional and provides accessibility. Conversely, they can be
installed in a fashion that completely makes accessibility impossible despite any
efforts or expense by AT vendors or consumers.
We concur with CTIA that entities need to be able to manage network
traffic. However, it is possible to manage network traffic without degrading
accessibility. The rules should state that network management must be done in
a fashion that does not hinder accessibility.
7. Accessibility of Information Content (Paragraphs 95-98)
In order to respond to the Commission?s concerns, we recommend that
the Commission amend our previous proposed item (i) to read ?the accessibility
information (e.g., captions or descriptions) are not stripped off when information
is transitioned from one medium to another using industry standards.? We have
not included the word ?recognized? because there is no definition of who would
need to have recognized it and it would be easy for any company to say they do
not recognize that industry standard. We did not change it to ?by recognized
industry standards organizations? because many industry standards are created
by industry organizations that are not ?internationally recognized standards
organizations?.
Regarding our proposed item (ii), it is important to include, for example,
that the video and audio channels on a SIP home phone are not blocked.
Blocking those channels contravenes the standard and effectively renders all the
accessibility channels for deafness, hard of hearing or speech disabilities moot.
Regarding our item (iii), it is important to allow, for example, an audio track
with descriptions for people who are blind to be substituted in a movie without
requiring the entire movie to be available from the alternate source.
With regard to encryption and other security measures, encryption actions
should be carried out such that the accessible information can be injected prior to
encryption and extracted after decryption or that a parallel encrypted track with
accessible information be provided. If information is only accessible after
encryption and is behind a proprietary wall, then accessibility can be provided,
but will need to be built in if external AT is not allowed access. Where security
screenings are conducted on audio communications to and from a company, for
example, similarly screenings can be done for text and video channels when they
are used for accessible communication. This should be the strategy, rather than
simply preventing any visual or text communication.
It is not clear what ?survivability? refers to or how it would be impacted by
accessibility.
Use of Access Board Draft Guidelines for the web: All of the Access
Board draft guidelines regarding the web are drawn from an industry standard for
web content. They are based on the Web Content Accessibility Guidelines
(WCAG) developed by the W3C. The W3C has created a large number of
industry standards for the web and WCAG is a standard that is recognized by
many nations internationally and by consumers and industry (e.g., all the industry
and consumer members of TEITAC recommended its use). The WCAG
standard was internationally vetted and developed by a committee representing
most of the major IT companies. These web standards in the proposed Access
Board revisions to 508 and 255 are the highest levels of priority of WCAG and
should definitely be incorporated in the rules.
Liability for embedded or user-contributed content: We agree with CEA
that manufacturers and service providers are generally not liable for user-
contributed content or embedded content that they do not create or control. This
is the same policy/constraint that is included in the WCAG conformance section.
Content that is contracted for should be considered to be under the control of the
manufacturer/service provider, where accessible versions are available from one
or more vendors or an accessible version would be provided by the vendor if
included as part of the purchase requisition. In addition, for user-contributed
content, the manufacturer or service provider should ensure that the tools they
provide to the user for creating the content are capable of allowing the user to
create accessible content if they desire.
IV. IMPLEMENTATION REQUIREMENTS
A. Obligations
1. Manufacturers and Service Providers (Paragraphs 100-102)
General Obligations (Paragraph 100):
Bullet 4: We would add ??or fail to activate or configure network features,
functions or capabilities of the network needed to allow accessibility.?
§ 255 Functional Approach (Paragraph 101-102): We concur with the
proposed provisions in paragraph 101. Access to this information is essential to
the use of these products ? especially since support calls beyond the warrantee
period are now charged for most products. Fortunately, with the Internet, making
such information accessible is easier than it ever has been in the past. We urge
that all information provided with or for a product be available on-line in
accessible form. In addition, the location (URL or clear and stable directions) for
this information should be available in the product documentation in large print.
2. Providers of Applications or Services Accessed Over Service Provider
Networks (Paragraph 103)
Most ACS in the future will be provided by ?providers of applications or services
accessed over service provider networks.? As we move further into cloud computing,
ubiquitous computing, and software as a service, we will migrate away from software
that runs on an OS platform and instead move to more and more software running in the
cloud (over service providers networks) or on software running in a browser page
downloaded from a web server (often using server based services as well). Even
software installed on a computer will often have portions of its functionality provided
over service provider networks.
?Accessed over service provider networks? (Paragraph 103). Applications
or services accessed over service provider?s networks (whether open or closed,
interconnected or not) should be covered. The one exception would be
applications that may be downloaded over a network, but none of their
functionality utilizes the network. That is, software would not be covered if there
is no difference in any aspect of its operation based on whether it is connected to
the service provider network or not connected to the network. A test for this
would be software that could be delivered on CDs and run on a computer that
was disconnected from all networks and still provide all functionality and services
without limitation.
B. Performance Objectives (Paragraphs 104-111)
Performance Objectives (Paragraph 105): We agree that performance
objectives need to be specific enough to be testable, but should not be specific to
the point of naming specific technologies or techniques to use, other than generic
performance based measures or approaches (e.g. a volume level to achieve or
the fact that speech output should be provided). The only exception to this is in
the area of interoperability. It is not possible or reasonable to require that things
be interoperable and then not specify common transport/interconnection format.
This would leave each company with the requirement to be interoperable, but no
guidance as to what they should be interoperable with. If there is only one
choice for the interoperability standard, then specifying it is not a problem. If
there is more than one choice, then specifying one is essential, or all companies
are forced to support all formats ? and any other formats that are introduced in
the future. There is no way to ensure interoperability otherwise.
Note that specifying an interoperability standard does not mean that that is
the only standard that can be used. Any company can implement as many other
or newer standards as they wish, and use them if manufacturers along the entire
call route and at the receiving end support the standard. But if not, the required
interoperability standard will be supported and can be used to guarantee
interoperability.
Definition of Accessible (Paragraph 105): We urge the FCC to not define
?accessible? as meaning ?conforming to these guidelines.? These guidelines will
only provide access to some types, degrees, and combinations of disability. To
define conformance with these guidelines as a definition of the word ?accessible?
can have unwanted consequences down the road. Instead we would suggest
either not defining the term or using the phrasing ?For the purposes of this
rule/standard/document, the term accessible shall mean??
Specific Performance Objectives (Paragraph 106): The language of the
Functional Performance Criteria in the current ANPRM draft guidelines do
include some groups such as those with seizure disabilities that should be drawn
from. But they are missing other groups that are currently in the FCC draft
guidelines. Further the Functional Performance Criteria in the ANPRM draft
comments are not testable and would need to be reworded. We suggest
building off of the FCC proposed Performance Objectives and drawing from the
ANPRM and TEITAC to increase their testability and to make the FCC proposed
Performance Objectives more generic, and applicable across technologies.
Standard for real-time text any time that VoIP is available and supported
(Paragraph 107): We concur with the need for adoption of a common
interoperability standard for real-time text. As noted above ? such a named
standard is necessary for interoperability. Interoperability of voice will be ensured
by market pressures. Video interoperability may also arise from market pressures
over time, but is not likely to occur in the short run in a manner that would
support the specifications needed for sign language communication. Before the
VoIP technologies and networks build out any further, guidance in the form of
named interoperability standards on these two critical communication channels
(real-time text and video) is needed. We are already receiving requests from
industry to press for the naming of a standard so that they can proceed with
product development. Companies are ready to implement, but are held up by
uncertainty created by the FCC?s delay in naming the obvious candidate.
Note that it is only necessary to specify the standard to be used on SIP
systems where they interconnect with other systems. All other systems need
only support real-time text in some internally consistent and reliable fashion as
long as they support the interconnection standard where they connect to systems
and devices from other manufactures using SIP.
Video conferencing equipment and VRS (Paragraph 108-109): We agree
that interoperability between video conferencing and VRS equipment is
important. Achieving this will allow the deaf and hard of hearing to make huge
strides toward the goal of functional equivalence. We maintain that VRS should
move from H.323 to SIP, in order to achieve better interoperability with
mainstream equipment, and that VRS and mainstream equipment should be fully
integrated into the NANP system for relay, point-to-point calls, and emergency
calls. Such equipment should also support other characteristics required for
effective VRS communication. These topics, as well as the functional parameters
needed for effective VRS and sign language communication, have been covered
in detail in the RERC-TA?s recent comments on off-the-shelf interoperability in
CG Docket 10-512 and the associated reply comments.3
2 Comments of the Rehabilitation Engineering Research Center on
Telecommunications Access (April 1, 2011). In the Matter of Structure and
Practices of the Video Relay Service, CG Docket No. 10-51. (Available at
http://fjallfoss.fcc.gov/ecfs/comment/view?id=6016375091)
Multipoint control unit (MCU) capabilities are important for making VRS
functionally equivalent with respect to conference calls, saving on cost
associated with redundant VRS interpreting, and effective 9-1-1 communication.
With current equipment, it is not possible for VRS users to see each other directly
in conference calls, so they either have to find and meet at a common location for
the duration of the call, or they have to call VRS independently and join through
two or more separate VRS interpreters. Neither of these options is functionally
equivalent to the way hearing people can listen to one another directly in
conference calls. Moreover, having to use multiple VRS interpreters
simultaneously during a call wastes money and resources. With respect to next-
generation 9-1-1 calls, MCU also would allow callers to exchange important
information with the PSAP directly via the video feed, while still being able to
view the VRS interpreter.
For these reasons, we strongly recommend that MCU become a
universally available capability in next-generation equipment. The performance
characteristics are similar to the functional parameters described in the RERC-
TA?s recent comments on the matter of Structure and Practices of the Video
Relay Service (see footnote 2 above), particularly with respect to bandwidth and
frame rate.
Working group for interoperability issues relating to video conferencing
services and equipment (Paragraph 110): It is important to note that the
interoperability issues have both a technical and a policy/consumer angle. On the
one hand, video equipment from different vendors must be able to connect to
one another, so the handshake protocols, as well as the audio and video codecs,
must be compatible. This also encompasses other interoperable features
demanded by consumers. However, these issues are highly technical, and it is
3 Reply Comments of the Rehabilitation Engineering Research Center on
Telecommunications Access (April 18, 2011). In the Matter of Structure and
Practices of
the Video Relay Service, CG Docket No. 10-51. (Available at
http://fjallfoss.fcc.gov/ecfs/comment/view?id=6016377546)
not realistic to expect that consumer groups will be involved in working out such
details. On the other hand, it is still necessary to give consumers an avenue to
provide input on what features are required and must be interoperable,
particularly with respect to the goal of functional equivalence between disabled
and non-disabled consumers. Some of the issues that may need to be
considered from a consumer point of view are having multiple phones ring in
response to an incoming call, and interoperable video mail in point-to-point
communications (similar to answering machines), which is not supported by
some of the current generation of VRS-provided equipment.
For these reasons, we suggest following a model similar to the one that
NENA uses. There should be two working groups: one that focuses on involving
consumers, and another one that focuses on working out the technical issues,
using the input from the consumer working group. With respect to VRS
interoperability, efforts should not be focused on only the largest service
providers, because currently one provider holds close to 80% of the market
share, and thus excluding smaller providers would seriously distort the VRS
market and negate much of the progress that has been made with respect to
VRS interoperability in the past. In addition, true functional equivalence can be
achieved only if all types of video equipment interoperate with VRS, just like
PSTN phones interoperate with one another today.
The goals of the suggested working groups should be to achieve interoperability
to such a degree that functional equivalence between disabled and non-disabled
consumers is achieved, including the ability to use off-the shelf equipment to
place calls, in the same way that anyone today can borrow a phone anywhere to
place a call. We suggest setting a timeline of two years from the enactment of the
rules, so as to give the industry time for planning. We cannot delay beyond this
point, because the installed base of video equipment would become too large,
and the costs of retrofitting interoperability would become much higher.
Electronic messaging services and non-interconnected VoIP services:
The lack of comment on electronic messaging services and non-interconnected
VoIP services does not indicate that another working group is needed. There
was little comment because the guidelines for interconnected and non-
interconnected VoIP should basically be the same. With the exception of
compatibility between TTY (on the PSTN) and IP text (on the IP side), there is no
difference in accessibility issues between interconnected and non-interconnected
VoIP services. Therefore, there is no need to establish a working group to
determine what the needs are. One would assume the needs would be the same
if both are to be equally accessible as specified in the law.
Regarding electronic messaging services: Electronic text is the form of
information that is most easily translated into all formats (visual, spoken and,
soon, sign language). The issues around messaging are ensuring that the
capability is present, is not locked, and that there is a standard format so that it is
as interoperable as voice. All of these were commented on and are also included
in our discussion above.
V. Industry Guidance
A. Safe Harbors
We agree there should be no safe harbor technical standards at this time.
The functional performance objectives should have enough detail to be testable.
B. Prospective Guidelines
We do not believe there is a need to create another advisory group to
generate guidelines that will duplicate what was done in TEITAC. The TEITAC
covered the same topics and reconvening another advisory group to retread the
same ground would cause many of the most qualified people involved to shoot
themselves, retire, or otherwise flee participation.
VI. Section 717 Recordkeeping and Enforcement
B. Recordkeeping
We believe it is very important that manufacturers and providers be
required to maintain records regarding any determination that accessibility is not
achievable for a product or service. The recordkeeping requirement should be
specific and consistent from manufacturer to manufacturer, but should not be
reducible to essentially a check-off function. The recordkeeping requirement
should reflect the high level of consideration and thought that should go into a
determination to exclude people with disabilities from accessing a product or
service.
We note that the requirement to produce a required record cannot be tied
solely to the timeline for responding to a Commission complaint. These records
will be needed in other forums, such as litigation and informal pre-complaint
investigations and negotiations, which should be facilitated. Therefore, required
records should be immediately producible.
We also note that producing records is only ever necessary when
products are not accessible.
C. Enforcement
2. General Requirements (Paragraphs 128-133)
Pre-filing notice: We agree that the Commission should not require
complainants to provide pre-filing notice to covered entities prior to filing an
informal or formal complaint. Such pre-filing notice requirements chill
enforcement by creating unnecessary and difficult barriers to people with
disabilities. Pre-filing notice requirements in other disability contexts have been
used as a technicality to prevent enforcement of valid claims. In addition, placing
additional barriers on people who are already facing barriers to access will
discourage people with valid claims from pursuing them. Further, in many cases,
such a notice requirement will be extremely difficult for a consumer to satisfy. As
the Commission discusses above, there are many participants in getting an ACS
to a consumer ? the consumer is unlikely to be able to tell which entity is
responsible and covered entities will be able to, intentionally or unintentionally,
delay enforcement by sending a consumer to the other entities in the chain.
Being bounced from entity to entity will discourage consumers from pursuing
their complaints and will make them give up on accessible products and services.
Standing: We agree that there is no basis in the law for imposition of a
standing requirement. In addition, given that there have been only 3 formal
complaints since 1999, and the Commission does not appear to have been
overwhelmed with informal complaints, it does not seem that standing
requirements are needed.
Sua Sponte Actions: We agree that it is important that the Commission
use all the mechanisms for enforcement that are available to it. The Commission
has a significant law-enforcement function, as well as a complaint resolution
function. An individual complaint in this context is not relevant solely to the
particular individual. Rather, in many cases, individual complainants represent
the many individuals in similar circumstances who were denied access. The
Commission must use its ability to use staff-initiated compliance reviews to
pursue these more global issues.
Remedies and Sanctions: In resolving complaints, it is the Commission?s
role to ensure that accessibility problems are resolved in ways that achieve
accessibility of products and services and prevent the need for future complaints.
In addition to requiring manufacturers and providers of inaccessible equipment
and services to make the next generation of the equipment or service accessible
and requiring forfeiture, when it finds a violation of the Act, the Commission must
require complainants to be made whole and compensated for their inability to use
the technology, as well as their attorneys? fees and costs to pursue the complaint.
The Commission should also require manufacturers and providers in violation of
the Act to make and publicize alternative arrangements for people with
disabilities to gain access to the technology until it is made accessible (e.g.,
requiring the provider to provide its own accessible products at the same price as
the inaccessible product, to provide third-party accessibility technologies at its
own cost, to offer a competitor?s comparable accessible technology to consumers
with disabilities at the same price as its own inaccessible product, or other
alternatives).
3. Informal Complaints
We are concerned that the Commission?s proposed pleading
requirements will make it difficult for consumers with disabilities to pursue
informal complaints. Most consumers do not have attorneys and are do not want
to go through the process of complaining. They simply want an accessible
product or service and they are legally entitled to it. The Commission is in a far
better position to investigate the details of the manufacture and distribution,
accessibility and achievability of any given product or service than is the
consumer. Therefore, the pleading requirements should be designed to be as
simple as possible and not to require the complainant to conduct extensive
investigation. The Commission should endeavor not to burden complainants and
not to create technicalities that will inhibit the filing of complaints. As discussed
above and in the Commission?s proposals, there are often numerous covered
entities in the market chain of a technology product. It will be difficult for a
consumer to identify the responsible party. The Commission is in a much better
position to identify the party responsible for an inaccessible product. Therefore,
a consumer in an informal complaint should only be required to identify the
product/service and the vendor from whom he or she purchased or considered
purchasing the product/service.
The Commission proposes to forward any complete complaint to the
covered entity. However, in some circumstances, such as in rural areas where
there are limited options for communication products and services, complainants
should be able to keep their identities confidential, so as not to subject
themselves to retaliation or loss of service.
We agree with the Commission?s proposal to require identification of a
point of contact for accessibility complaints. We suggest that the Commission
require an appropriate level of publication of these points of contact, so that
consumers may pursue informal resolution of problems without having to file with
the Commission.
We are concerned that delaying remedy determinations until the issuance
of a ?subsequent order? after the 180 day investigation deadline will lead to
?justice denied,? particularly if the complainant must await such a subsequent
order to be made whole or to gain access to an accessible product or service.
What constitutes a reasonable time to bring equipment or services into
compliance will depend on the product/service and on the other circumstances.
Notably, products and services will only be required to be made accessible as a
result of an enforcement action when making them accessible was already
achievable. Moreover, given the short life cycle of today?s technologies,
deadlines for making products accessible that should have been accessible from
the beginning should be short. Otherwise, providers will be encouraged to skip
accessibility because they know that, by the time someone complains, the
Commission investigates for six months, and a ?reasonable time? for compliance
is permitted, the product or service will be obsolete.
We agree that Commission permission or use of the informal complaint
process should not be required before filing a formal complaint. Given that the
Commission has received only three formal complaints, there does not appear to
be a need to further inhibit the formal complaint process.
Respectfully submitted,
On behalf of the
RERC on Universal Interface and Information
Technology Access
and the
RERC on Telecommunications Access4:
/s/ Gregg C. Vanderheiden
Gregg C. Vanderheiden, Ph.D.,
Principal Investigator,
RERC on Universal Interface and Information
Technology Access,
Co-Principal Investigator,
RERC on Telecommunications Access,
Director, Trace R&D Center
University of Wisconsin-Madison
1550 Engineering Drive, 2107 ECB
Madison, WI 53706-1609
(608) 262-6966
and
/s/ Christian Vogler
Christian Vogler, Ph.D.,
Co-Principal Investigator,
RERC on Telecommunications Access,
Director, Technology Access Program
Gallaudet University
800 Florida Ave., NE, SLCC 1116
Washington, DC 20002
(202) 250-2795
4 The contents of these comments were developed with funding from the
National Institute on Disability and Rehabilitation Research, U.S. Department of
Education, grants number H133E090001 and H133E080022 (RERC on
Universal Interface and IT Access and RERC on Telecommunications Access).
However, those contents do not necessarily represent the policy of the
Department of Education, and you should not assume endorsement by the
Federal Government.