CVAA – Manufacturer Responsibilities

As part of the rule-making process, the FCC recognized that systems involved in ACS are commonly described as having five components or layers: (1) hardware (commonly referred to as the “device”); (2) operating system; (3) user interface layer; (4) application and (5) network services. In addition, in ensuring the accessibility of ACS, a variety of additional components also come into play: (1) assistive technology (AT) utilized by the end user; (2) the accessibility application programming interface (API); and (3) the web browser. For individuals with disabilities to use an advanced communications service, all of these components have to work together to support accessibility features and capabilities.The FCC makes it clear that it expects the key responsibility for ensuring these components work together lies with the end-user equipment manufacturer (FCC 11-151¶69). This manufacturer, in collaboration with the developers of other components, is ultimately responsible for ensuring the accessibility of the entire application stack. This places a special burden on the manufacturer of the final, branded equipment to ensure the entire experience of the device is accessible.

This, however, raises a practical issue: for systems that contain ACS services as part of their operating system, what level of responsibility does an organization have? For example, what responsibility does an organization have for a desktop computer system that runs Windows and contains Skype as part of the OEM setup? The FCC regulations certainly cover Microsoft as the manufacturer of the operating system and the Skype software. This software, however, ships as part of the default configuration of an organization-branded system. In this scenario, what is an organization’s responsibility to ensure the accessibility of Skype on the system? How do an organization’s responsibilities overlap with that of Microsoft, and where do an organization’s responsibilities end and Microsoft’s begin?

Fundamentally, the regulatory language in this scenario implies that, ultimately, anything that provides ACS that ships on an organization-branded device’s default configuration – be that a laptop’s default system setup or phone’s out of the box configuration – is an organization’s responsibility. The FCC’s logic is that “the manufacturer is the one that purchases those components and is therefore in a position to require that each of those components supports accessibility. (FCC 11-151¶69)” The FCC’s stated goal in this is to foster industry collaboration between the suppliers of end user equipment, software, operating systems and service providers to ensure accessibility of the entire ecosystem. In one of the examples cited in the report and order “Microsoft states, ‘a laptop manufacturer that builds ACS into its device will need to consult with the developer of the operating system to develop [accessibility], and in that way the operating system provider will be deeply involved in solving these problems and promoting innovations in accessibility(FCC 11-151¶70).’”

In practice, a conservative interpretation of these components of the Report and Order means that an organization should be prepared to perform due diligence to ensure that all components that provide ACS on machines are accessible. This includes both components that an organization directly codes and those that an organization merely includes that are provided by other manufacturers. This also includes ACS features provided in the operating system and any installed applications that provide ACS.

As noted in the Report and Order, for software-based services, manufacturers have significant discretion in how they implement the requirements of the Act. As an example provided in the Report and Order, “a provider of a web-based e-mail service could meet its obligations by ensuring its services are coded to web accessibility standards (such as the Web Content Accessibility Guidelines (WCAG).” In the same vein, “services downloaded onto the OS of a desktop or mobile device, service providers could meet their obligations by ensuring, if achievable, that their services are coded so they can work with the Accessibility API for the OS of the device.” This implies some limitation in terms of the level of accessibility that need be applied to ensure that software applications are made accessible. This also inherently provides for a method to define accessibility with respect to widely followed normative industry standards for accessibility.

Please note that these responsibilities are intended to be interpreted in the context of the entire CVAA requirements. These include specific requirements relating to recordkeeping and product level responsibilities.

Put yourself on the path to complete accessibility!

Just fill out the form below and we’ll contact you to set up your free consultation with an expert specializing in your industry.

If you need more immediate assistance, please send an email to info@ssbbartgroup.com or call (800) 889-9659. We look forward to helping you!