Electronic Comment Filing System

ECFS Filing Proceeding: 10-213
Name of Filer: RERCs on IT and Telecom Access
Author: Gregg Vanderheiden & Christian
View Filing:
View (44)
Type of Filing: COMMENT
Exparte Presentation: NO
Date Received: 4/25/11
Date Posted: 4/26/11 10:54 AM
Address: Trace R&D Center U of Wisconsin-Madison 1550 Engineering Dr Madison, WI 53706

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.