request for proposal b1000681 - non capital... · 2020. 2. 12. · page 1 of 2 . 2/12/2020 ....

of 2

2/12/2020

Request for Proposal B1000681

Indiana State University is seeking proposals for an LMS system. In submitting a proposal, proposer agrees that Indiana State University has the sole right to determine what is in the best interests of the University. ISU reserves the right to negotiate minor changes or variations to the proposal of the apparent successful bidder. Please provide the University with a proposal on the following: A. ISU’s General Terms and Conditions 1. Prices to include F.O. B. Indiana State University. 2. Freight or other costs will not be allowed unless included in your proposal. 3. Unless otherwise understood, there are no restrictions on the number of items or quantity that may

be ordered. 4. If alternates are offered, full descriptive information and literature must be submitted with proposal. 5. Indiana State University is a political subdivision of the State of Indiana, and is not subject to any

taxes imposed by the State or Federal Government. 6. Material Safety Data Sheets are to be submitted with your proposal for any applicable items or

products. 7. Indiana State University reserves the right to accept or reject any or all proposals and to waive any

formalities or informalities. 8. All items to be as indicated in the RFP or an approved equal. 9. If applicable, please submit, in addition to the base bid, an alternate bid using recycled materials

that meet or exceed the specs above.

B. Debarment, by Signing this document you certify that: 1. Your Company is not presently debarred, suspended, proposed for debarment, declared ineligible,

or voluntarily excluded from transactions by any Federal, State, or local department or agency, in accordance with 2 CFR 200.213 and 2 CFR 180.

C. Terms/ Shipping (Vendor: please complete the following) 1. Prices are firm for _____________days.______ 2. Terms ________

of 2

3. Shipment to the made from ____________ within ____ days.

D. Minority Business Information ( Vendor: please complete the following) 1. Is your business owned and controlled (51% or more of the enterprise) by minorities African

Americans, American Indians, Hispanics, or Asian Americans)? Yes ___ No ____ Minority Owned: Yes ___ No ___ Veteran Owned: Yes ___ No ___

Request for Proposal _ submitted by: Your Company’s Name: __________________________ Company Address: ______________________________________________________ Company Contact Name: _________________________ Phone number: _________________ Fax number: ________________ Email Address: ___________________________________ Signed: ________________________ Date: ____________ (Submit this form with your proposal)

Request for Proposal

B1000681

Learning Management System

Responses Due: March 2, 2020 by 3:00PM EST

2

Learning Management System Request for Proposal B1000681

TABLE OF CONTENTS SECTION I – GENERAL INFORMATION ........................................................................................................................4

Introduction and Background .....................................................................................................................................5

Introduction ............................................................................................................................................................5

Background .............................................................................................................................................................5

Coordination and Schedule ........................................................................................................................................6

RFP Coordination ....................................................................................................................................................6

Schedule of RFP Events ..........................................................................................................................................7

Proposal Selection and Award Process ......................................................................................................................8

Preliminary Evaluation ...........................................................................................................................................8

RFP Evaluation ........................................................................................................................................................8

Demonstrations ......................................................................................................................................................8

Sandbox Experience ...............................................................................................................................................9

Award Process ..................................................................................................................................................... 10

Section II – general Requirements .......................................................................................................................... 10

Issuance of RFP .................................................................................................................................................... 10

Proposal Submission ................................................................................................................................................ 10

Number of Copies ................................................................................................................................................ 10

SUBMISSION ........................................................................................................................................................ 11

Minority/Woman Owned/Veterans Businesses .................................................................................................. 11

Confidential Information ..................................................................................................................................... 12

Insurance ............................................................................................................................................................. 12

Background Checks .............................................................................................................................................. 13

SECTION III – SPECIFIC REQUIREMENTS .................................................................................................................. 13

Requirements Overview .......................................................................................................................................... 13

1.0 Preferred Requirements .......................................................................................................................... 13

2.0 Policies and Legal ..................................................................................................................................... 15

3.0 Functional Requirements ........................................................................................................................ 15

4.0 Technical Requirements .......................................................................................................................... 15

5.0 Usability Requirements ........................................................................................................................... 28

3


6.0 Transitional Requirements ...................................................................................................................... 29

7.0 Data Analysis Requirements .................................................................................................................... 30

8.0 Support Requirements ............................................................................................................................ 30

9.0 Use Case Scenarios .................................................................................................................................. 32

10.0 Cost Proposal ........................................................................................................................................... 45

4


SECTION I – GENERAL INFORMATION

RFP INFORMATION AND CONTACTS

REQUEST FOR PROPOSAL

LEARNING MANAGEMENT SYSTEM

INDIANA STATE UNIVERSITY

Terre Haute, IN 47809

MAIL PROPOSALS TO:

Indiana State University

Purchasing and Receiving

951 Sycamore Street


Attn: LMS RFP B1000681

CONTACT FOR RFP INQUIRIES: PROPOSALS MUST BE RECEIVED NO LATER THAN:

RFP COORDINATOR March 2, 2020

For all questions One (1) signed original and five (5)

copies are required.

Ernest F. Kramer

Indiana State University

Purchasing and Receiving


E-Mail: [email protected]

FAX: 812-237-3599

Phone: 812-237-3600

Please request confirmation of any emails to insure delivery.

The person designated above shall be the only contact(s) for all inquiries regarding any aspect of this RFP and its requirements unless otherwise noted by Indiana State University.

mailto:[email protected]

5


INTRODUCTION AND BACKGROUND

INTRODUCTION

Indiana State University is seeking a next-generation Learning Management System (LMS) to

replace its current LMS, Blackboard Learn Original Experience provided via Software-as-a-

Service. This Request for Proposal (RFP) is a request for the planning, migration, configuration,

implementation, training, and ongoing support of a cloud-based LMS to be used as the primary

learning platform by Indiana State University.

BACKGROUND

Indiana State University was established in 1865 and is a four-year public university in the heart

of the Midwest. We offer a tradition of strong undergraduate and graduate education with a focus

on community and public service. The Carnegie Classification of Higher Education classifies

Indiana State University as a Doctoral/Research University. At Indiana State University, there

are more than 100 majors, 70+ online programs, and endless opportunities for students. We

currently have over 12,000 students, 600 faculty, and 1,200 staff. Our students and faculty utilize

courses in multiple formats including face-to-face, online, and hybrid.

Indiana State University has been with the same vendor for their Learning Management System

(LMS) since the early 2000s. For a large part of that time, there were limited options in the LMS

market. In early summer 2019, we conducted a preliminary review of the current marketplace for

LMSs. The goal was to determine the current state of features and functions for instruction,

course administration, student learning, and student success, as well as a high-level review of

requirements for transitioning to a new LMS. The result of that review strongly encouraged a full

evaluation of LMS applications to be completed via this RFP.

6


For the next 3-5 years, Indiana State University will be particularly focusing on student success

capabilities in our enterprise systems, as well as general strategic enrollment management. We

are interested in systems that promote the advancement of our student success capabilities in the

LMS.

Our current environment consists of production, test, and development servers. We are currently

utilizing upwards of 5 terabytes (TB) of storage and have approximately 3,600 new courses each

semester. Our estimated implementation timeline incorporates a possible two-system approach

where we will be running the current and new LMS in parallel for up to a year. Please keep this

in mind when responding to requirements, particularly transitional and migration requirements.

COORDINATION AND SCHEDULE

RFP COORDINATION

Upon release of this RFP, all Respondent communication concerning this acquisition must be

directed only to Ernie Kramer with Anthony Bradshaw and Louise Montgomery copied. Any

other unauthorized communications may result in rejection of a proposal.

Questions should be submitted by email and will be responded to by email. All questions and

responses will be provided to all potential Respondents who have requested and received a copy

of this RFP. The communication must use the RFP number (B1000681) followed by the

Respondent’s company name in the subject line. Only information directly related to the RFP

can be answered, so please do not ask questions like, “who else is receiving this RFP…” we

cannot reveal that information.

7


Any and all questions should be addressed to [email protected] with

[email protected] and [email protected] copied. In order to

ensure a response all questions must be asked by February 17, 2020.

Do not call, email or contact any persons working for Indiana State University during the bid

period, other than the above or others within the Purchasing Department. Contact with persons

other than the Purchasing Department, or others stated above may result in the rejection of your

bid if your contact was not approved by Indiana State University Purchasing prior to the contact.

If an onsite evaluation is determined to be necessary, it will be in the bid specification and at that

meeting various members of the University community may respond to your questions at this

scheduled meeting.

SCHEDULE OF RFP EVENTS

Please be advised that these dates are subject to change as Indiana State University officials

deem necessary.

1. RFP to vendors February 3, 2020

2. Last day to email questions to RFP Coordinator February 17, 2020

3. RFP questions answered February 24, 2020

4. RFP Responses due (3:00PM EST) March 2, 2020

5. Selected Respondents provide sandbox environments March 16, 2020

6. Selected Respondents demonstrations (the week of) March 30, 2020

7. Contract start date TBD




8


PROPOSAL SELECTION AND AWARD PROCESS

PRELIMINARY EVALUATION

Returned proposals will be reviewed by the committee to determine if preferred requirements are

met. Any Preferred Requirement that is not met by a Respondent will result in rejection of the

proposal. In the event that all Respondents fail to meet one or more preferred requirements,

Indiana State University reserves the right to continue the evaluation of the proposals and to

select the proposal which most closely meets the requirements specified in this RFP.

RFP EVALUATION

Proposals that meet the preferred requirements will be reviewed by the LMS Evaluation Steering

Committee. Respondents that meet the committee’s expectations will be asked to come to

Indiana State University campus and provide demonstrations to faculty, staff, and students. The

campus community will have an opportunity to evaluate the Respondent’s proposed solution

based off their experience at the demonstrations. A rubric will be used to collect evaluative data

from the committee and the campus community to assist in determining a recommendation.

DEMONSTRATIONS

Selected Respondents will be asked to visit and present demonstrations at Indiana State

University campus in Terre Haute, Indiana. The Respondents will each have one (1) day to

present four (4) demonstrations and a two-hour-long meeting with the committee. The

demonstration topics are:

• General Product Overview – 90 minutes

• How Your Solution Supports Student Success – 60 minutes

• Gradebook, Assessments, and Assignments – 60 minutes

9


• Sample Course Migrations – 60 minutes

Each Respondent will have a maximum allotted time of 60 minutes per demonstration topic,

excluding the general product overview demonstration. The demonstrations will need to be

recorded and made available to our campus community for two (2) weeks after the

demonstration date. The Respondent can choose to record the demonstrations and provide a

direct link to access them, or Indiana State University will record the demonstrations and host the

videos through our systems. Respondents will need to confirm that decision during the

demonstration scheduling time. Respondents should be prepared to travel to campus and present

the demonstrations during the week of March 30, 2020 through April 3, 2020. This is subject to

change per Indiana State University’s discretion.

SANDBOX EXPERIENCE

Respondents that are selected to present demonstrations will also be asked to provide sandbox

environments of their proposed solution. These environments will need to be available for the

campus community to interact with. Respondents will also need to provide a technical sandbox

environment for Indiana State University OIT staff to perform a technical evaluation. This will

include (at a minimum) setting up integrations with OIT systems such as the SIS and other third-

party tools to ensure functionality. These environments will need to be provided ahead of the

demonstrations and be available to use until a recommendation is made. Selected Respondents

should be prepared to provide sandbox environments to Indiana State University by March 16,

2020.

10


AWARD PROCESS

The committee will make a recommendation based on the entire RFP process including the

demonstrations and experiences with selected Respondents’ sandbox environments. Indiana State

University may award a contract on the basis of the initial proposals received, without further

discussions or initiate negotiation with a single or multiple Respondent(s). Therefore, submitted

proposals should contain the Respondent’s best offer. Note: Though negotiations are anticipated

if there are adjustments in the configuration, Respondents should submit lowest and best price

for the configuration which is bid. Indiana State University may award a contract based solely on

the RFP responses.

SECTION II – GENERAL REQUIREMENTS

ISSUANCE OF RFP

Issuance of this RFP does not require Indiana State University to enter into a contract with any

vendor. Indiana State University reserves the right to reject any or all proposals, wholly or in

part; to waive any technicalities, informalities, or irregularities in any proposal which does not

materially affect the integrity or effectiveness of the RFP process. Indiana State University

reserves the right to analyze proposals in detail and to award contracts which in its reasonable

discretion believes to be in its best interest. Further, Indiana State University also reserves the

right to cancel or reissue this RFP.

PROPOSAL SUBMISSION

NUMBER OF COPIES

Respondents must mail or deliver an original and five (5) copies of the completed proposal,

including all items indicated herein, to the Indiana State University Purchasing Office. Copies of

11


the proposals SHALL NOT be sent to any other Indiana State University office or department.

All documents should be 8 1/2” x 11” format, either bounded or in a loose-leaf binder. An

electronic copy of the proposal should also be returned via email to Ernie Kramer at the email

from which you received this document, copy [email protected] and

[email protected]. Electronic copies are due on the due date, hard copies should

be received by Indiana State University two days after your electronic submission.

SUBMISSION

Proposals submitted after the closing date and time may not be considered. Indiana State

University reserves the right to determine if conditions beyond the control of the Respondent

caused a late submission and is the sole judge if a late submission is due to factors beyond the

control of the Respondent.

Request a confirmation of receipt when your electronic response is submitted.

Proposals WILL NOT be accepted via fax. If hard copy is delayed, the bid submission will be

accepted if the electronic copy has been delivered in a timely manner.

SUBMISSIONS SHOULD INCLUDE ANSWERS TO EACH SECTION OF THIS RFP,

WHEN REQUIRED, IN THE ORDERED ASKED AND NUMBERED PER NUMBER ON

THIS RFP.

MINORITY/WOMAN OWNED/VETERANS BUSINESSES

In the pricing section of your bid, please include present percentages of any Indiana certified

business which are woman owned, minority owned or veteran owned businesses which would be

applicable to the products you are bidding (i.e., they are tier one suppliers to you).



12


A list of IN certified minority/woman owned/veteran owned businesses can be found at:

https://www.in.gov/idoa/mwbe/2743.htm

Also note if you are using an IN certified minority owned/woman owned/veteran owned business

as a reseller.

CONFIDENTIAL INFORMATION

Vendor is hereby advised that proposals, supporting documents, and any other information

exchanged with ISU in connection with this Request for Proposal could be subject to the Indiana

Access to Public Records Act (“APRA”), IC § 15-14-3 et seq., and may be disclosed upon public

request as required by Indiana law. Any material Vendor considers a trade secret, confidential or

otherwise excepted from disclosure under APRA (“Confidential Information”) must be clearly

marked in boldface type, red font and include the word “CONFIDENTIAL” at the top of the

corresponding page(s) in fourteen (14) point font. The basis of the claim must be stated. ISU

reserves the right to make determinations of confidentiality in its discretion. If the Vendor fails to

identify Confidential Information, ISU may not consider the material confidential, or an excepted

from disclosure.

INSURANCE

Attach a copy of your certificate of insurance. Please make this a separate section of your bid.

Indiana State University must be added as also insured to your Cyber/Technology/E&O/Gap

(coverage for over limit in any category) insurance. Note: Differing names may be used for the

insurance above. The intent is for ISU to be also insured for breaches, infringement, etc. ISU will

be responsible to renew the certificates of insurance on an annual basis.

https://www.in.gov/idoa/mwbe/2743.htm

13


BACKGROUND CHECKS

Do you perform background checks on your employees? (circle) Yes No

SECTION III – SPECIFIC REQUIREMENTS

REQUIREMENTS OVERVIEW

The following sections (1-10) are Indiana State University’s requirements and expectations of

the Respondent and the Respondent’s products and services capabilities. Each section will start

with important information that may include expectations and instructions. Please make sure to

read through that information before responding.

1.0 PREFERRED REQUIREMENTS

The following requirements in section 1.0 are preferred, and the Respondent must satisfy

them.

1.1 Respondent must have a minimum of three (3) years proven experience in the

provision of similar products and services to institutions of Higher Education that are

the same or similar to the requirements by this solicitation.

1.2 Respondent must provide a general company overview that includes at least: a

detailed description of your experience and capabilities with the requested products

and services to higher educational institutions, the length of time your company has

been offering these services, and the number of customers that have utilized them.

1.3 Respondent must indicate the number and description of any cancelled or terminated

contracts within the last five (5) years.

14


1.4 Respondent must include a list of at least four (4) organizations for whom the

Respondent has provided products or services that are the same or similar to the

requirements by this solicitation within the last three (3) years. The reference must

include the current name, title, address, email, and telephone numbers of a contact

person along with a brief description of the project or assignment which was the basis

for the business relationship. Indiana State University is currently utilizing a SaaS

(Software-as-a-Service) package. Therefore, an ideal reference is one that

transitioned from a SaaS provider to the Respondent’s SaaS package. Indiana

State University will determine, as its sole discretion, which, if any references to

contact to assess the quality of work performed and personnel assigned to the project.

The results of any references will be provided to the evaluation committee and used

in scoring the proposal.

1.5 Indiana State University has multiple mission critical applications and technologies

that directly interface with the LMS. Each Respondent must define how their

proposed solution supports the compatibility with these systems. These systems and

technologies include: Ellucian Banner SIS (Student Information System), Multi-

Factor Authentication, and Security Assertion Markup Language (SAML).

1.6 Respondent must include an example of a standard contract for the services requested

in this solicitation for Indiana State University to review early in the RFP process.

This will allow Indiana State University the opportunity to review language before

entering official contract negotiations.

15


2.0 POLICIES AND LEGAL

For 2.0 Policies and Legal Requirements, Respondents should review Addendum A and

respond with any concerns they may have. As a part of the final contract negotiations, the

winning Respondent should expect to complete and return Addendum A.

3.0 FUNCTIONAL REQUIREMENTS

For 3.0 Functional Requirements, Respondents should complete the attached Addendum B –

Feature List. Respondents should pay close attention to the instructions and complete the

spreadsheet completely.

4.0 TECHNICAL REQUIREMENTS

Please provide a narrative response to each item below. Your response should fully address

how your proposed solution supports the corresponding item. To maximize present

investments, it is desirable that your proposed solution integrates with existing technologies

operated by Indiana State University. As you prepare your responses, please indicate how

your product can integrate/leverage our existing systems and technologies as listed in

Preferred Requirement - 1.5. If the solution has an additional cost to accommodate it, please

list it.

4.1 Accessibility

4.1.1 Describe how the solution is attempting to comply with the U.S. Federal

Rehabilitation Act, Section 508 (36 CFR Part 1194,

http://www.section508.gov). Please complete the provided Voluntary

Product Accessibility Template (VPAT) found in Addendum C.

http://www.section508.gov/

16


4.1.2 Describe how the solution is attempting to comply with American with

Disabilities Act (ADA) including Web Content Accessibility Guidelines

(WCAG 2.1) to support web content accessibility.

4.1.3 Describe how your proposed solution’s change management control

processes address accessibility compliance when releasing feature changes

and updates (i.e., product release cycle).

4.2 Account Management

4.2.1 Describe the roles, ability to assign permissions, options for

customization, and any limitations for user accounts. This should include

system roles, as well as course-level roles.

4.2.2 Describe in detail the process of provisioning and deprovisioning user

accounts, including accounts created locally and through an integration

system.

4.2.3 Describe in detail the process to set up integration and the user interfaces

for management of enrollment, entitlements, and permissions.

4.2.4 Describe the process for creating and deleting users manually or through a

batch process independent of integrations. Detail if the information is

permanently removed and how it affects reporting.

4.2.5 Describe how your solution supports disabling accounts through Ellucian

Banner SIS (Student Information System).

4.2.6 Describe how your solution handles the account logout process. Include

timeouts, logging, and if the solution allows for external forced logout

policies from other systems.

17


4.3 Analytics

4.3.1 Describe the process of accessing raw data from the source systems.

4.3.2 List the standard reports and data elements available to users to build

custom reports.

4.3.3 List the canned reports available to users. This should include reports that

show information and statistics on the system, courses, organizations, and

users.

4.3.4 Describe the manner in which user reports and associated data can be

exported and list supported formats.

4.3.5 Describe reports that can be used for student success in regard to retention

and on-time graduation (i.e., student has not logged in for ‘x’ number of

days, a student’s grade has been trending downward over ‘x’ number of

days).

4.3.6 Describe how the solution is compatible with external reporting tools,

specifically Argos Enterprise Reporting.

4.3.7 Does your solution offer real-time reporting of the environment? If so,

describe what this entails and the process of getting that information.

4.3.8 Describe how your solution logs all user activity within your solution and

how that data is accessible.

4.3.9 Describe how your system logs authentication information of users, what

information that entails, and how that data is accessible.

4.3.10 Describe how your solution offers reporting to administrative leadership

and supervisors/department heads.

18


4.4 Authentication

4.4.1 Describe the solution’s compatibility with different single sign-on (SSO)

providers and methods. At a minimum, the solution will be compatible

with Security Assertion Markup Language (SAML).

4.4.2 Describe how the solution supports Windows Active Directory (AD)

integration.

4.4.3 Describe how your solution supports the use of Microsoft Azure Multi-

Factor Authentication.

4.4.4 Does the solution allow the creation of local accounts?

4.4.5 Describe how your solution handles account password management and

how the passwords are protected.

4.5 Data Management

4.5.1 The solution should be able to provide Indiana State University with a

complete copy of its learning environment data within 30 days of the

request. The data must be in a reusable form to be determined at the time

of the request. Explain how your solution addresses this need.

4.5.2 Does your solution provide real-time access to data? If so, please describe

how this is done.

4.5.3 Describe in detail your solution’s database support. This should at a

minimum include if it’s direct access, real-time, database type, reporting,

database schema information, and database communication protocols.

4.5.4 Describe in detail your processes for ensuring the confidentiality,

integrity, and availability of data within your solution.

19


4.5.5 Describe your retention policy for deleted data. Do you offer restoration

for deleted data?

4.5.6 Describing your process for maintaining data. Include the process for

deleting content, users, and courses in the LMS and how this affects the

database.

4.5.7 Does your proposed solution provide a content repository for content

storage and management?

4.5.8 Describe any batch processes your solution provides that support creating

and deleting courses from the system administrator-level.

4.5.9 Describe in detail how your proposed solution handles logging of

information. Include information regarding audit trails, access-level to

view and search logs, type of information included to utilize the logs (i.e.,

does it provide sufficient information to ensure traceability?).

4.5.10 Describe your process for purging and archiving courses from a system

administrator-level and instructor-level.

4.6 Data Migration

4.6.1 Describe in detail your data migration strategies and support for moving

from one SaaS provider to your solution.

4.6.2 Describe an estimated length of time it will take to migrate Indiana State

University’s current environment to your proposed solution.

4.6.3 Does your solution support an import of an exported postgres database to

your solution? If so, describe how this works.

4.7 System Architecture and Components

20


4.7.1 Describe if there are any hardware, software, or technology components

required to be installed at Indiana State University in order to use your

proposed solution.

4.7.2 Does your solution require Java or Flash installations from end users in

order to use your LMS?

4.7.3 Describe any stand-alone desktop software required to utilize all features

of your solution.

4.7.4 Provide an overview of the technical resources required including but not

limited to: storage, compute, security, DNS, firewalls, VPN tunnels,

bandwidth and storage usage estimates, and any other key components. Be

sure to include any available diagrams.

4.7.5 Describe the licensing model associated with your solution (i.e., Per

defined user verses simultaneous users, storage used, etc.).

4.7.6 Describe the requirements for the supported systems that your solution

operates on (i.e., Amazon Web Services, Microsoft Azure, proprietary

turnkey solutions, on premise resource, etc.).

4.7.7 Describe your solution’s cloud service provider.

4.7.8 Describe the process through which requests from Indiana State

University for new functionality or changes to existing functionality will

be addressed.

4.7.9 If your solution utilizes Open Source software or technologies, describe

how contributions from the Open Source community are incorporated into

releases.

21


4.7.10 Provide an overview of your proposed solution’s environment (i.e., we

will have a production, test, development environment. We will have a

database, etc.).

4.7.11 Describe any limitations of cloning environments (i.e., production can

only be cloned once a year).

4.7.12 Describe any limitations to storage, including system-level, course-level,

and user-level. Include information regarding any limitations or

restrictions that may apply (i.e., daily usage, quota restrictions, etc.).

4.7.13 Describe the process for establishing a database communication link and

what is required of Indiana State University to do this.

4.7.14 Describe how security certificates are handled and what requirements are

needed of Indiana State University.

4.8 System Integration

4.8.1 Describe in detail how your solution supports the integration of Student

Information Systems (SIS). Indiana State University currently utilizes

Ellucian Banner for SIS. Please include at a minimum the following:

4.8.1.1 How data imports and exports.

4.8.1.2 Integration information (i.e., automated, real-time, etc.).

4.8.1.3 File formats, tasks scheduling mechanisms, any limitations.

4.8.1.4 Is there a GUI screen for integrations? If so, does it support

the following:

4.8.1.4.1 Enable course enrollments

4.8.1.4.2 Disable course enrollments

22


4.8.1.4.3 Enable courses

4.8.1.4.4 Disable courses

4.8.1.4.5 Is there an alert for integration failures and successes?

4.8.1.4.6 What are the available integrations – do they support

courses, enrollments, new accounts, terms, instructors,

and custom integrations?

4.8.1.5 What is the accepted key identifier for courses? Indiana State

University currently uses an 11-byte key that is comprised of

year, term, and CRN. Describe how your solution supports

this or something similar.

4.8.1.6 Describe the syncing capabilities for SIS and your proposed

solution (i.e., does it support final grade transmission).

4.8.1.7 Does your solution support the integration of user photos

from the SIS system? If so, how does it look in the system

(i.e., can instructors see a picture roster of their students in

your solution)?

4.8.1.8 Is your solution compatible with Ellucian Intelligent

Learning Platform?

4.8.2 Does your solution support integrations with CRMs (i.e., Slate and

Talisma)?

4.8.3 Describe how your solution is compatible and/or offers equivalent services

with the following 3rd party tools. Be sure to describe the supported

integration type (i.e., LTI, API, or another type):

23


4.8.3.1 Blackboard Collaborate Ultra

4.8.3.2 Blue by Explorance

4.8.3.3 ExamSoft

4.8.3.4 Films on Demand

4.8.3.5 Labster

4.8.3.6 Microsoft Office365

4.8.3.7 Qwickly Attendance

4.8.3.8 Respondus 4.0

4.8.3.9 Respondus LockDown Browser

4.8.3.10 SoftChalk

4.8.3.11 TK20

4.8.3.12 TurningPoint

4.8.3.13 Turnitin

4.8.3.14 Yuja

4.8.4 Describe how your solution is compatible with the following publisher

integrations:

4.8.4.1 Cengage

4.8.4.2 Elsevier

4.8.4.3 Hawkes Learning

4.8.4.4 Knewton

4.8.4.5 MacMillan

4.8.4.6 McGraw-Hill

4.8.4.7 Pearson

24


4.8.4.8 Wiley

4.8.4.9 W.W. Norton

4.8.5 Describe how your solution handles publisher content regarding

allowing/not allowing users to make purchases within the LMS (i.e., if

your solution allows users to make purchases, how is that managed?).

4.8.6 Is your product compatible with any additional Assessment Management

Systems not listed above? If so, describe which ones. If not, is it in

development?

4.8.7 Describe the technologies used to extend the functionality of your solution

(including scripts, APIs, and other similar technologies). Be sure to

provide examples documenting these extensions.

4.8.8 Describe how the provider ensures integrations with your proposed

solution remain compatible with new releases.

4.8.9 Provide examples of solution components that currently use the API

framework.

4.8.10 Describe the process for combining and separating of one or more

courses/sections brought over from the SIS within your proposed solution.

Indiana State University allows instructors to merge course enrollments

which creates a new course. The combined courses need to still sync with

the SIS, while also allowing the instructors to work from one master

course. Describe how your solution supports this.

25


4.8.11 Describe how your solution supports exclusivity contracts with bookstores

(i.e., does your solution allow end users to purchase textbook content from

other publishers or stores and can you manage that?).

4.9 System Performance and Scalability

4.9.1 Describe the estimated required components and resources that would be

allocated to operate, maintain, and support Indiana State University’s

current environment in your proposed solution.

4.9.2 Describe how your solution supports the scalability of resources per

Indiana State University’s future growth and demand. Detail how you

adjust for enrollment growth and any costs associated with that. Describe

any limitations to scalability that may exist.

4.9.3 Describe how your solution dynamically allocates additional resources to

the environment during peak loads. Detail if there are any additional costs

to allocated additional resources due to system overutilization. Be sure to

include how Indiana State University is alerted when the system is

overutilized, how the utilization is monitored by your support, and any

reports of utilization that are available to Indiana State University.

4.9.4 Describe in detail any limitations of maximum number users, courses,

storage, and other components.

4.9.5 Describe how your proposed solution offers system end user performance

and response time analytics in both real-time and historical.

26


4.9.6 Describe how system performance is monitored and the tools available

natively within your product. Also describe the performance target

benchmarks used for determining satisfactory performance delivery.

4.9.7 Describe your terms for Service-Level Agreements (SLA). Include details

for uptime, security incident resolution procedures, outages, and your

business continuity plan. Be sure to detail how system outages are

reported and how we are notified of them (i.e., social media, status web

pages, etc.).

4.9.8 Describe the definition of acceptable performance for the solution, how it

is measured, and how the solution infrastructure (software and hardware)

can be scaled to maintain acceptable performance.

4.9.9 Describe your back-up and recovery procedures.

4.9.10 Describe your change management process for pushing product fixes,

improvements, and updates. Detail any downtime for updates, how often

they occur, how and when you notify customers, and any other important

information. Detail any packages or versions that are available that allow

Indiana State University to control when updates are released to

production environments.

4.9.11 Does your proposed solution support integrations with performance

monitoring applications and servers such as Open Monitoring Distribution

(OMD), Nagios, and Zabbix?

27


4.9.12 Describe how your proposed solution manages error handling and input

validation (i.e., errors that may occur for end users when uploading files

that have possible restricted characters such as &*,] etc.)

4.9.13 Does your proposed solution allow for Indiana State University

administrators (system and database) to query the database using any

desired language (SQL) or reporting tool?

4.10 Training and Technical Documentation

4.10.1 Describe training available for Indiana State University system

administrators, including any cost involved.

4.10.2 Describe training support materials for your proposed solution that are

available, including additional fees.

4.10.3 Describe any technical guides and support for developers that you provide,

including API development and LTI integrations.

4.10.4 Describe the process for training users and administrators. Detail the

process for ensuring Indiana State University’s support staffed become

subject-matter experts in your proposed solution and are able to support

and train end users.

4.10.5 Provide a list of any training and technical documentation that is available

to Indiana State University system administrators.

4.11 Usability

4.11.1 Describe how consistency of the user interface and functions are

maintained across all supported desktop platforms.

28


4.11.2 Describe whether end user and administrative functionality is accessible

via web interfaces.

4.11.3 Describe the functionality differences between the different clients and

interfaces you offer for your proposed solution (i.e., desktop vs mobile).

Responses should be focused towards ease of use.

4.11.4 Describe any required or optional browser plug-ins and add-

ons/extensions, and why they are needed.

4.11.5 Describe how your solution supports the most common Internet browsers

and mobile devices (e.g., Safari, Chrome, Firefox, iPhone, Android, etc.).

Detail how your proposed solution ensures product functionality with

frequent updates from browsers and mobile devices.

4.11.6 Describe any customizations your proposed solution has available for

Indiana State University to apply branding, themes and more (i.e.,

allowing customization of user interface design and/or brand experience

that appears for users).

5.0 USABILITY REQUIREMENTS


how your proposed solution supports the corresponding item. If the solution has an additional

cost to accommodate it, please list it.

5.1 Describe in detail how your solution supports course designers (i.e., instructional

designers, instructors, etc.) in the development of courses incorporating universal

design best practices.

29


5.2 Describe in detail how your solution allows non-tech savvy users to easily navigate

through the system to access current courses, past courses, support resources, grades,

organizations, and more.

5.3 Describe how your solution is easy to use and limits the number of clicks a user has

to do to get to a destination.

6.0 TRANSITIONAL REQUIREMENTS




6.1 Provide a detailed overview of your transitional plan for moving to your proposed

solution. Include the following:

6.1.1 Detailed project plan

6.1.2 Detailed migration plan

6.1.3 Detailed implementation plan

6.1.4 Detailed support plan

6.2 Describe in detail how your solution supports a faculty member migrating a

Blackboard Learn Original Experience course site into your proposed solution.

6.3 Describe any additional services and training not yet mentioned that you offer to end

users for transitioning from Blackboard Learn Original Experience to your solution.

30


7.0 DATA ANALYSIS REQUIREMENTS




7.1 Describe reports available for students that support student success (i.e., a report that

displays a student’s progress in a course).

7.2 Describe reports available for instructors that support student and instructor success

(i.e., activity in a course).

7.3 Describe reports available for advisors that support student success (i.e., early

warning alerts).

7.4 Describe how your solution allows for administrators (Deans, Chairs, assessment,

etc.) to outline program and course learning outcomes so that instructors can easily

align assignments and assessments; include how this can be monitored and reported

on.

7.5 Describe any dashboards available and detail the user role needed to access them.

7.6 Describe any reporting that integrates with SIS data, and include the system-level of

access needed to run the report (i.e., an administrator could run a report that shows all

freshmen students taking a foundational study course that are receiving As).

8.0 SUPPORT REQUIREMENTS




31


8.1 Describe in detail an overview of your model for supporting customers. Include

information about how administrators report issues, request changes, access

documentation, escalate issues, and any other pertinent information that relates to

supporting customers. Detail support personnel that are assigned to Indiana State

University during the migration/implementation and ongoing support of the system.

8.2 Describe any support communities that you offer and/or support if they are external to

your company.

8.3 Indiana State University’s primary support for the LMS resides in the Office of

Information Technology, but there are other units (instructional designers, faculty

fellow, library, etc.) that assist in supporting the LMS and there may be additional

units in the future that may need support-level access (i.e., Financial Aid, Registration

and Records, etc.). Describe how your solution supports and assists these individuals.

8.4 Describe any pedagogical and instructional technical “how-to” guides you provide for

faculty, instructors and support staff.

8.5 Describe any pedagogical training and technical support for new instructional data-

driven models you supply, including competency-based learning, self-paced

instruction, self-directed learning, learning analytics, adaptive learning, and

personalized instruction. Include any materials or instruction addressing pedagogical

and technical support for different modes of delivery, including flipped, blended,

online, and hybrid.

8.6 Describe how your support materials for students, instructors, and administrators are

accessible. Meaning they meet ADA compliance and other accessibility needs, are

32


easily accessible – public facing and not requiring authentication, are searchable, and

are available on multiple devices.

9.0 USE CASE SCENARIOS

The following Use Case Scenarios are specific examples of functionality, features, and

expectations Indiana State University requires in an LMS. These were formed from

surveying and meeting with faculty and students. For each use case below, Respondents must

submit a narrative describing how its proposed solution would address the given scenario and

a video or animation of less than 5 minutes duration illustrating the solution described in the

narrative. These videos or animations should be placed on a DVD and mailed to Indiana

State University with the proposal submission.

9.1 Course Merge

Each semester, Professor Bird teaches up to 20 sections of PE 101. His Fall 2019 course

had 12 sections. There are over 400 total students enrolled in all the sections for his

Spring 2020 course. He needs to be able to easily work in these courses without having to

duplicate content over and over again. He also needs an easy way to use content from his

Fall 2019 course. Lastly, with having over 400 students, there needs to be an easy way to

manage grades.

Indiana State University currently merges courses in the LMS using the following

information:

• Course ID = year, term, course registration number

o Professor Bird’s Spring 2020 Courses:

PE-101-001, Course ID = 20200110301

33


PE-101-002, Course ID = 20200110302

PE-101-003, Course ID = 20200110303

PE-101-004, Course ID = 20200110304

PE-101-005, Course ID = 20200110305

PE-101-006, Course ID = 20200110306

PE-101-007, Course ID = 20200110307

PE-101-008, Course ID = 20200110308

PE-101-009, Course ID = 20200110309

PE-101-010, Course ID = 20200110310

o ISU system administrators will then create a new course using the course

IDs. The above course merge would have a new course ID of:

202001_10301_10302_10303_10304_10305_10306_10307_10308_10309

_10310

o Once the merge is complete, a course copy from the Fall 2019 course

would be processed.

- Include how course links work from the course copy, how previous

discussion boards copy to the new course, how to identify which

students are enrolled in which section, and how

assignment/assessment due dates are adjusted.

With the above information, describe and demonstrate how your solution supports this.

Be sure to detail work required from the system administrator and instructor roles.

9.2 Importing Exams

34


Dr. Dwyer utilizes test banks from publishers to create his exams. He needs an easy way

to import those test banks and exams from an external source directly into his LMS

course.

Ms. Knope is a part-time lecturer that utilizes word documents for all of her exams. She

usually likes to print the exams off and provides physical copies to her students to take

the exam. She is looking for a way to make her work more efficient. She heard that you

can put your Word document exams in the LMS but doesn’t know where to start.

Describe and demonstrate how your solution supports each process.

9.3 Nested Folders

Dr. Perkins teaches several nursing courses each semester. She loves the current LMS’s

nested folder structure. She likes that she can create a tab called Learning Modules and

then store 16 weeks of learning modules within it. Once she’s in the Learning Modules

tab, she creates 16 weekly module folders. Then, within each module, she adds the

corresponding weekly module’s objectives, content, and assessments. Sometimes she

even adds additional folders within the modules that students can use to reference

additional materials. This creates a nested folder structure where the students may find

themselves in Learning Modules – Week 1 – Resources – Introduction to Nursing.pdf.

Describe and demonstrate how your solution helps Dr. Perkins organize her course

content.

9.4 Clinical Grading

35


Professor Meagle is an instructor from the speech language pathology program. She

teaches a class called CD-600. She and 4 clinical supervisors are enrolled as instructors.

Her students have two primary requirements for one of the graduate level courses. They

must complete course and clinical requirements. For the course requirement, students are

required to complete assignments throughout the semester and Professor Meagle is

responsible for grading those. For the clinical piece, students are required to complete

off-campus clinical hours and a separate clinical supervisor is responsible for completing

their grades. At the end of the semester, the clinical supervisors email Professor Meagle

the students’ clinical grades. She then takes those grades and applies them to the

students’ final grade. This is a time-consuming process and a lot of it happens outside of

the LMS in a separate spreadsheet.

Describe and demonstrate how your solution can help Professor Meagle save time and

resources with her grading.

9.5 Instructor Efficiency

One of the benefits of an LMS is to reduce repetitive tasks and use data in ways that

increase an instructor’s efficiency, allowing them more time to devote to teaching,

mentoring, and other tasks. Some examples of this are 1) the ability to reach out to

selected groups of students while maintaining individual confidentiality, 2) being able to

hide assignment grades while grading is still in progress, 3) setting a default grade if an

assignment isn’t submitted by a certain date, 4) using templates in various ways to

automate commonly used phrases, 5) the ability to edit a master document and have

36


changes updated in certain courses, and 6) identify core concepts that the majority of

students are struggling to comprehend.

Without limiting yourself to the examples cited, describe and demonstrate how your

solution supports this.

Instructors are busy people who may occasionally make a mistake. This can create

difficulties when exams and assignments are created with incorrect settings that may not

be discovered until after a student has submitted a response. How could a professor

correct assignment or exam settings after a student submission in your solution?

9.6 Video Conferencing

Professor Atreides has a hybrid class of both online and face-to-face students, with about

40 total students. Once a week they meet as a group for discussion. Describe and

demonstrate how your solution facilitates student-to-student discussion under these

conditions.

Dr. Leto teaches an online course of 80 students. During their synchronous sessions, he

would like to divide them into small groups to work on a solution to a problem. They

should have a whiteboard design completed at the end of their group work. At the end of

class, Dr. Leto wants a representative from each group to show and explain their

whiteboard design. He will then need to save that work and assign group grades.

Describe and demonstrate how this type of activity would work in your solution.

37


Reviewing film clips is an important component of Professor Usul’s online course. He

has found that highlighting specific clips helps engage students in directed discussions.

Describe and demonstrate how your solution allows this activity.

9.7 Lecture Capture

Dr. Paul teaches his online class asynchronously and teaches a second section of the same

class in a face-to-face setting. He prefers to record his lectures during the on-campus

class and then put them online for the distance students to watch. Describe and

demonstrate how your solution can assist Dr. Paul in teaching his online section.

Professor Shaddam has a Guild representative available to give a special lecture during

one of his classes. This is a rare opportunity, and he wants to keep a recording of the

event to share with future students. Describe and demonstrate how your solution makes

this possible.

Dr. Bene-Gesserit has found that students benefit from watching math problems be

solved, so they can see each step-by-step. She would like to find a way to demonstrate

the solutions where the students could review the material during their study

time. Describe and demonstrate your recommendation for how she can use your solution

to help students.

Attendance is important to Professor Harkonnen. He has resisted teaching his online class

asynchronously because he cannot clearly tell that students fully review all of his posted

video lectures. Describe and demonstrate how your solution would help him track

students who are and are not reviewing the videos.

38


9.8 Rubric Integration and Sharing

Professor Snow is a new Chair in the College of Technology. He’s been teaching courses

at ISU for a decade now but wanted more responsibility. As a professor, he always uses

rubrics throughout his courses to help evaluate assessments. Now that he has more

responsibility, he would like to implement the use of rubrics throughout his department.

Professor Snow and a few of his colleagues created a rubric template that they would like

to apply to a core set of courses. In the future, they may do the same thing in other

classes. They would also like to present it to the Dean so it could be used college-wide.

Describe and demonstrate how your solution supports Professor Snow’s ambitions.

9.9 Annotated Grading

Previously, the LMS supported an application that allowed instructors to make

annotations to assignments when grading. They could add annotations in multiple ways,

including highlighting, comments, and drawing. They could also download the

assignment with the included annotations. Additionally, it would be beneficial if the

instructors could save comments for future use. Also, detail if your solution supports

annotating in any other areas such as for exams and if it allows additional features like

adding audio feedback.

Describe and demonstrate how your solution supports this. Be sure to include any

features that assist instructors with annotated grading and students with viewing those

annotations.

9.10 Student Collaboration Distance & Face-to-Face

39


Many courses use student-to-student collaboration as part of the instructional

method. Describe the various ways students can use your solution to engage with each

other over the course material. How are those solutions different for online courses versus

face-to-face courses? Include the following:

Student Perspective:

Students working as a small group to write a paper.

Students in a small group who will do a presentation on their research.

Students working on a community service project.

Students debating a topic for course credit.

Instructor Perspective:

Intuitively and easily deploy discussion boards and assignments to groups.

Create and manage groups easily and efficiently.

Describe and demonstrate how your solution supports this.

9.11 Advisors Supporting Students

As an academic advisor, Dale Doback supports over 50 students at a time. He is in

regular contact with his students to ensure they remain on track and on-time for

graduation. Mr. Doback needs access to several resources in order to best assist his

advisees. Ideally, he would be given access to his specific advisees’ course information in

the LMS but wouldn’t be able to see other students’ information.

40


What are some ways your solution supports academic advisors in regard to supporting

students and ensuring student success? Describe and demonstrate how your solution

supports this.

9.12 LMS SIS Sync

It is crucial that student grades are entered into the LMS by instructors. At the end of

each semester, instructors use a tool that allows them to download the final grades and

submit them to our SIS (Ellucian Banner). While this process works, it would be

convenient if there was a capability to directly sync the final grades from the LMS to

Banner. Ideally, this would be a feature maintained by system administrators. As in, the

instructors can select in their course that their final grades are ready to sync, but the

system administrators are the ones to initiate the sync.


9.13 Email Design

Phishing is a risk that every organization with resources connected to the Internet has to

manage. Email is a common form for these attacks to occur. It’s important that emails

coming from Indiana State University maintain their integrity. In particular, the sender

email information (i.e., name) needs to look official and not suspicious. This includes

emails coming from the LMS. It is important that any email initiated from the LMS looks

like an official email.

Professor Huff communicates with his students directly through the LMS. From posting

course announcements that are also emailed, to sending individual emails to students

41


about their assignments. Unfortunately, the emails that come from the LMS look

suspicious. They include Professor Huffs information, but they also include the web

server’s information. An example of this looks like this: [email protected] do-

[email protected] Professor Huff’s students are

concerned that this may be a phishing attempt. Ideally, he would want the email to say

just [email protected].

Demonstrate and describe how your solution supports this.

9.14 Guest Access

Dr. Gates teaches a few psychology courses each semester. Near the end of the semester

she likes to invite a guest lecturer to work with the students remotely. The guest lecturer

needs access to most course information excluding student grades. Dr. Gates only needs

the guest to have access for one week and then their account should be disabled or

inactive. Describe and demonstrate how your solution supports this.

Winnie helps faculty with development and training. She frequently hosts training

sessions, webinars, and one-on-ones for those that want to learn something new. She also

supports all new faculty with on-boarding. Every semester she has to request that the new

faculty are enrolled into her LMS course site so she can provide them valuable

information. Ideally, she would like to have her course site public to Indiana State

University faculty so they can join on their own. She also has an additional course site

that she would like to allow external users to be able to access materials, but they

wouldn’t have access to any protected information.





42



9.15 Library Access

Dr. Chani is a researcher in the library. She provides supplemental material for several

programs. She may need to utilize reserves, subscription resources, subject guides,

databases, and more. How would your solution allow her to present her course content to

many courses?

She also offers online Q&A to students working on research. In the past, the course

instructor has had to manually enroll her in the course, and they set up a discussion board

post for the interactions. How would you recommend using your solution to achieve this

end?

Students often need to access library materials and resources. How can your solution

facilitate this process? Describe and demonstrate how your solution supports this.

9.16 Academic Integrity

Professor Idaho has a student in his class who claims that he submitted an assignment,

but it is gone now. How could he use your solution to verify the accuracy of the student's

account? Are there any features that ensure an assignment could not get 'lost'?

Dr. Hawat has a difficult suspicion that one of his students might be paying someone to

take their online exams. How could your solution help verify a user's identity? Are there

any features that actively check for multiple people using the same account?

Dr. Irulan was told by a student that a group in her class has been cheating on exams by

sharing answers. What tools are available in your solution to verify this story? Are there

43


any tools in your solution that could help prevent this activity? Describe and demonstrate

how your solution supports this.

A student found an online site that allows them to purchase research papers for them to

submit as their own. They decided to make the purchase and submitted the paper directly

to LMS. Are there tools in your solution that can assist with plagiarism?


9.17 Attendance

Attendance tracking is an important feature and need to be easy to use. Indiana State

University offers varying sizes and types of courses. Some courses may be on campus

with only 10 students and others may be online with 80 students. Instructors need a way

to easily track attendance through an LMS no matter the size or type of course.

Describe and demonstrate how your solution supports the following:

Take attendance in different face-to-face class sizes

• Small classroom with less than 15 students.

• Medium classroom with less than 40 students.

• Large classroom with more than 40 students. Could have upwards of 200

students in one class.

Report attendance at the 3-week mark of a semester that includes students who

are currently enrolled and who have dropped the course.

Measure ‘regular and substantive’ interaction for online attendance purposes.

9.18 Dropped Students

44


Michael Scott is a student in Mr. Howard’s BUS-101 course. At about week 9

(out of 16), Michael decides that he’s not doing very well and drops the course.

At the end of the semester, Mr. Howard needs to run a report that will show all

activity from Micheal even though he dropped the course. Financial Aid and the

Registration and Records also need the ability to see information about the

dropped student. How does your solution support the needs of Mr. Howard,

Financial Aid, and Registration and Records? Describe and demonstrate how your

solution supports this.

Students add and drop classes before and during the semester. Instructors are

added and removed before and during the semester as well. Describe and

demonstrate how your solution supports this. Be sure to include (at a minimum)

how dropping and adding initiated from the SIS works and course-level reporting

data on dropped users.

9.19 Universal Design

With a diverse student population, Indiana State University is committed to

designing and developing courses that will meet the varying needs of learners. Dr.

Metic, therefore, wants to ensure that her on-campus and online education

courses, which rely exclusively on open educational resources, meet not only

accessibility (ADA, Section 508, and WCAG) requirements but also universal

design expectations. In addition to including regular text-based content within her

course, Dr. Metic employs a great deal of multimedia, including instructor-created

and online videos, audio files, PDFs, images, and synchronous chats in the

45


materials, assessments, and feedback. Occasionally, despite her concerted efforts,

some students still find it difficult to find, read, or hear the on-screen materials.

Additionally, she must accommodate at least two students in the program who

have documented disabilities and require time and a half on their exams. Describe

and demonstrate how your solution can help Dr. Metic reach her goal of a course

compliant with accessibility regulations and universal design.

Dr. Smith teaches campus and online courses in the Deaf and Hard of Hearing

Certificate program with smaller class sizes to an increasingly larger online

population that is deaf, vision impaired, or wish to earn a certificate in teaching

deaf students. In order for them to fully experience the same services as others,

what accommodations can they receive in Dr. Smith’s course that allows them to

obtain the same information as fully, equally, and independently as others even in

synchronous meetings? Describe and demonstrate how your solution supports

this.

10.0 COST PROPOSAL

For 10.0 Cost Proposal Requirements, Respondents should complete the attached

Addendum D.

46


of 11

ADDENDUM A THIS ADDENDUM IS HEREBY MADE BETWEEN INDIANA STATE UNIVERSITY (hereinafter referred to as “ISU” OR “Indiana State University”) AND VENDOR LEGAL NAME (hereinafter referred to as the “VENDOR”.)

LIMITATIONS ON LIABILITY

ANY LIMITATIONS ON LIABILITY CLAIMED BY THE VENDOR SHALL NOT APPLY TO INFRINGEMENT BY THE VENDOR OF ANY PATENTS OR COPYRIGHTS. ANY LIMITATIONS ON THE LIABILIY OF THE VENDOR IN THE CONTRACT SHALL APPLY EQUALLY AS A LIMITATION TO THE LIABILITY OF INDIANA STATE UNIVERSITY.

Infringement Vendor is solely liable for any infringement of a patent or copyright unless infringement is caused by ISU modifications to the software or ISU attaching equipment to the software causing the infringement, provided the equipment attached was not based upon the recommendation or direction of the vendor. Vendor agrees to indemnify, hold harmless and defend Indiana State University from any actual or anticipated claims of infringement that are brought about due to the vendor’s actions or negligence. Promptly, upon becoming aware of any actual or anticipated claims of infringement vendor shall advise ISU of the actual or claimed infringement. Vendor shall also advise ISU of the course of action the vendor intends to take regarding any infringement issues to allow ISU’s continued use of the software. Vendor has the right to modify the software so it becomes non-infringing and must provide a non-infringing copy of the software as soon as possible if company modifies the software due to infringement or a claim of infringement. If, however, modification to the software is such that it no longer fulfills the initial purpose intended, as determined by ISU, then ISU reserves the right to cancel the contract. If a lawsuit is filed against vendor for infringement, or if it is anticipated a lawsuit may be filed against vendor for infringement, vendor will immediately inform ISU of the pending or potential lawsuit so ISU may limit liability by ceasing to use the software.

of 11

Concerning any litigation holds on data (also called a litigation cooperation clause). The vendor shall provide Indiana State University with any legal requests and shall ensure that the data is preserved in its entirety during the duration of any litigation. Indiana State University has the right to participate in any defense at its own expense. The terms and conditions may not be changed by the signing of any of the following: a renewal notice, or an invoice, or a quote. Changes to an existing contract shall only be made upon the mutual agreement and signature by both parties to a contract amendment.

End user license agreement (EULA) A EULA binds only the end user not the university. This addendum modifies any EULA and or any contract between the end user and the vendor. The vendor is bound by this addendum concerning any modifications to the EULA as regards both the university and the end user.

Secure data protection and handling of data

Vendor agrees at all times to maintain network security that at a minimum includes: network firewall provisioning, intrusion detection, and regular (two or more annual) third party vulnerability assessments. Likewise, vendor agrees to maintain network security that conforms to generally recognized industry standards and best practices that vendor then applies to its own network. Vendor warrants that all confidential ISU data and confidential ISU end user data will be encrypted during transmission of the data.

Application security Vendor agrees at all times to provide, maintain and support its software and subsequent updates, upgrades and bug fixes such that the software is, and remains secure from those vulnerabilities by using best practices or standards to protect and secure the application. Vendor agrees to preserve the confidentiality, integrity and accessibility of Indiana State University data with administrative, technical and physical measures that conform to generally recognized industry standards and best practices that vendor then applies to its own processing environment. Maintenance of a secure processing environment includes, but is not limited to, the timely application of patches, fixes, and updates to operating systems and applications as provided by vendor, or developer or open source support.

of 11

Vendor agrees to have conducted reasonably frequent, industry standard, audits concerning penetration and vulnerabilities of the system and shall provide ISU with reports and certificates as the audits are concluded. ISU may from time to time request an audit of the vendor, or any third party.

Data storage and hosted computing Vendor agrees that any and all Indiana State University data will be stored, processed and maintained solely on designated target servers and that no Indiana State University data at any time will be processed on or transferred to any portable or laptop computing device or any portable storage medium, unless the device or storage medium is in use as part of the vendor’s designated backup and recovery processes. Vendor agrees that all data exchanged which is specifically identifiable as ISU data shall be used expressly for the purpose of fulfilling its duties under this agreement and for ISU’s sole benefit, and will not share such data or disclose it to any third party without the prior written consent of ISU or as otherwise required by law. Indiana State University owns all data residing within a hosted environment.

All data storage shall be confined to the United States.

Vendor shall regularly back up ISU and ISU end user data. Indiana State University shall have available a mechanism for requiring that the hosted provider destroy specified ISU records as requested. ISU shall be able to access and retrieve all ISU stored data, at any time while the contract is in force and not less than 30 days following the termination of the contract. The contract shall provide clear instructions concerning how Indiana State University data can be returned or retrieved in the event of contract termination and a common data format for the return/retrieval shall be available.

Security breach notification Vendor agrees to comply with all applicable laws that require the notification of individuals in the event of an unauthorized release of personally identifiable data or other

of 11

event requiring notification under applicable law. This includes, but is not limited to, PCI (credit card) data, HIPAA data, and FERPA data. Vendor agrees to: Notify Indiana State University Legal Department by telephone and email of such an event promptly upon discovery. Assume responsibility for informing all such individuals in accordance with applicable law after consultation with Indiana State University regarding the method of notification. Except as otherwise required by law, vendor shall not provide notice of the incident directly to the persons whose data were involved, without prior written permission from ISU. Provide free credit monitoring service for a year to each end user where personal financial information may have been exposed. Indemnify, hold harmless and defend Indiana State University and its trustees, officers, and employees from and against any and all claims, damages, attorney fees, court costs, and legal costs or other harm related to such notification event.

Accessibility Vendor represents and warrants that deliverables comply with Web Content Accessibility Guidelines (WCAG) version 2.0 level AA, and agrees to provide written documentation verifying accessibility, to promptly respond to and resolve accessibility complaints received from the university, and to indemnify and hold the university harmless in the event of claims arising from accessibility. Vendor agrees to comply with updated versions of WCAG as revised federal guidelines become available.

Service availability

Vendor warrants an operational uptime of 98% of the time in any given month, exception being when outage is caused by a force majeure event. A prorated credit amount shall be applied to the vendor’s next invoice to ISU proportional to the amount of time system was unavailable for use by ISU. Vendor shall notify ISU a sufficient time in advance when there is scheduled downtime.

of 11

Students

Indiana State University assumes no responsibility for the acts of student users of vendor’s product(s), systems, and software.

Data retention & termination process Vendor agrees that Indiana State University has 30 days after the contract ends to request return of data in the possession of vendor. Both parties shall work to insure the data is delivered in an acceptable format to both parties. Vendor is responsible to securely destroy all data after the contract expires after it has shared the data with the university, or 60 days after the end of the contract, whichever comes first.

Third party software Vendor is solely responsible for any third party software which vendor uses in conjunction with vendor product or which vendor supplies or recommends to Indiana State University

Signature authority The purchasing department at Indiana State University must sign this contract, the purchase order and all changes or future amendments to this contract. Other persons working for Indiana State University do not have the authority to bind the university to this contract. The terms and conditions of this agreement may not be changed by the signing of any of the following: a renewal notice, or an invoice, or a quote. Changes to an existing contract shall only be made upon the mutual agreement and signature by both parties to a contract amendment.

Purchase order required A purchase order is required for any contract changes which increase the cost of this project. A purchase order is also required for renewals.

of 11

Sole authority Both parties agree that other than termination under the terms of this contract that neither party has the sole discretion or sole authority to determine any acts or compliance with the contract by the other party.

Arbitration Any and all arbitration clauses are stricken from any contract between the parties signing this agreement.

Taxes

Indiana State University is a tax exempt entity. Indiana state university will supply vendor with proof of exemption upon request. Upon verification of tax exemption, vendor agrees that all taxes resulting from this contract are the responsibility of the vendor.

Laws This agreement will be governed by and construed in accordance with the laws in force in the state of Indiana. The parties hereto agree that any action to enforce the provisions of this agreement shall only be brought in the courts of the state of Indiana irrespective of the fact that one or more of the parties is, or may hereafter become, a resident of a different locale. The parties hereby consent to the exclusive jurisdiction of the above-referenced courts and to service of process by registered mail, return requested or by any other manner provided by law.

of 11

Confidential Information Confidential information means all confidential information as described under federal and Indiana law. Specifically, confidential information does not include any agreements, any order form, or any other document which includes pricing. Indiana law protects trade secrets and customer lists. Vendor shall clearly mark as confidential any information in any correspondence, documents, proposals, and other writings, or sections of such, that are confidential as described by Indiana or Federal law. This agreement, any attachments and quotes and other writings associated with this agreement are subject to FOIA requests.

Conflicts If any conflict exists between the terms of the agreement/contract between the vendor and Indiana State University and this addendum, the terms of this addendum shall govern.

Cap on recurring charges Recurring charges, maintenance, license renewal and any other charges which Indiana State University has to pay on a recurring bases are capped at no more than 5% over the prior year. Vendor and ISU shall negotiate pricing to cover the purchase of any additional modules. If the licensing model is based on users, proportional adjustments to number of users will be made. If vendor uses bracketed user quantities, adjustments will be made as quantities rise or fall to another user bracket.

FERPA

If your software involves any “Family Educational Rights & Privacy Act of 1974” (FERPA) concerns, then vendor agrees to the following provisions:

FERPA Confidential information

Any and all information shared with vendor by ISU or I S U ’s employees or students should be treated as confidential information. Vendor acknowledges that some of the information shared may be considered student educational records as defined by the family educational rights and privacy act of 1974, as amended.

of 11

Limitation on use and disclosure

Vendor will not knowingly disclose to any third party, or make any use of ISU’s confidential information. Vendor will use at least the same standard of care and security to maintain the confidentiality of the ISU’s confidential information that it uses to maintain the confidentiality of its own confidential information of equal importance, but in no event may the standard of care and security be below that customary and reasonable under the circumstances. At a minimum vendor shall maintain the confidential information (i) in a secure, location or (ii) if stored on vendor’s computer networks, under circumstances requiring secure password access. Only employees of vendor who have a reasonable need to know of the confidential information in order to perform their responsibilities may be given access to ISU’s confidential information.Vendor shall only use such confidential information for the purpose of fulfilling its duties under this agreement and shall not further disclose such data to any third party without prior written consent of ISU or otherwise required by law.

FERPA compliance

Vendor agrees to abide by the limitations on re-disclosure of personally identifiable information from education records set forth in the family educational rights and privacy act (34 CFR § 99.33 (a)(2). Vendor shall not use or disclose student education record information received from or on behalf of Indiana State University or its students, except as permitted or required by the agreement, as required by law, or as otherwise authorized in writing by institution. Vendor shall, within one day of discovery, report to institution any use or disclosure of personally identifiable student education records not authorized by this agreement or in writing by Indiana State University. Vendor acknowledges and agrees that it will comply at all times with ISU’s policies on maintenance and disclosure of student educational information, as may be amended from time to time.

PCI compliance If your software involves any “Payment Card Industry” (PCI) data security concerns, then vendor agree to the following provisions: During the term of the agreement, the vendor agrees to provide, upon written request from Indiana State University, a letter of confirmation that the delivered solution still complies with the set forth conditions of this addendum and agreement. If at any time, credit card processing and or other payment methods are added to or are present in the vendors’ software, the vendor shall be solely responsible for any breach of security.

of 11

If the vendor has credit card or end user payment capabilities: PCI-DSS compliance: vendor’s delivered software solution for Indiana State University shall not use any Indiana State University merchant id. Vendor agrees to ensure the payment solution shall continue to operate in a PCI-DSS compliant manner at all times and will provide advance notice to Indiana State University of any changes regarding credit card processing. Upon receipt of a request from Indiana State University, vendor will provide all necessary information required to ascertain vendor’s PCI compliancy and/or resolve any PCI related issues identified in the vendor solution during Indiana State University’s annual PCI-DSS assessment. This information includes, but is not limited to, an annual attestation document, appropriate self-assessment questionnaire, or attestation of compliance. In the event of a breach of vendor’s security obligations or any other event which requires notification under applicable law, Vendor agrees to assume responsibility of informing all individuals in accordance with applicable law and to indemnify, hold harmless and defend Indiana State University from and against any and all claims, damages, or other harm related to such a breach. If your software does not currently involve any “Payment Card Industry” (PCI) data security concerns, but might be capable of performing PCI transactions in the future, then vendor agree to the following provisions: PCI compliance - where the vendor does not currently have credit card capability and does not accept, process, transmit or store (permanently or temporarily) any PCI related data: Vendor states that any website furnished by the vendor does not currently contain any links, which accept credit cards, nor does the website contain a link to other websites, which accept credit cards. Should the vendors software contain the ability to take payments from the end users in the future, the vendor shall notify ISU prior to adding or activating any PCI data functionality within their software and the vendor is required to have signed, by ISU’s purchasing director, an addendum to the contract allowing such capability. Should ISU and the vendor be unable to agree upon this addendum to the contract, then ISU shall

of 11

have the right to cancel any then current contract.

HIPAA compliance

If your software involves any “Health Insurance Portability and Accountability Act (Public Law 104-91” (HIPAA) concerns, then vendor agrees to the following provisions:

To the extent applicable vendor agrees that at all times during this agreement vendor and its products or services will comply in all material respects with all federal and state mandated regulations, rules or orders applicable to the parties, including but not limited to regulations promulgated under the Health Insurance Portability and Accountability Act (public law 104-91 “HIPAA”) as amended.

Indemnification Vendor hereby agrees to release, indemnify, hold harmless, and forever discharge ISU and its related parties, including their respective predecessors and successors in interest, and each past or present parent, subsidiary, affiliated entity, officer, trustee, partner, principal, shareholder, agent, employee, vendor, attorney, representative or assign of any of them (collectively, the “released parties”) from any and all known or unknown grievances, disputes, actions, causes of action; claims of appointment, employment, reemployment or reinstatement, claims at law or in equity, or sounding in contract or tort, arising under the common law; any federal, state, or local statute or ordinance that arise out of, or are connected with, in any way, vendor’s performance of services under this agreement.

of 11

Debarment

Debarment, by signing this document you certify that: Your Company is not presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from transactions by any Federal, State, or local department or agency, in accordance with 2 CFR 200.213 and 2 CFR 180. By signing, you are agreeing that this “Addendum A” shall be incorporated into the contract/ agreement between vendor and Indiana State University. Signature: ____________________________ Date: ____________ Company Legal Name_________________________ Street Address_________________ City________________ State_______________ Phone______________ Email of above signatory __________________________ Indiana State University _____________________ Kevin Barr Director or Purchasing [email protected] ____________________________ Date

Instructions:

Item Number Feature DescriptionDoes this exist in your proposed solution? (Yes/No)

Is this feature available in your mobile app(s)? (Yes/No)

3.1.1 Ability to create assignments.

3.1.2 Ability to edit assignments.

3.1.3 Ability to attach rubrics to assignments.

3.1.4 Ability to use plagiarism detection with assignments.

3.1.5 Ability to add availability exceptions to assignments.

3.1.6 Ability to delete assignments.

3.1.7 Ability to grade, clear, and exempt assignment attempts.

3.1.8

Ability to add feedback to submitted assignments using text, files, multimedia, and rubrics.

3.1.9 Ability to create and modify rubrics.

-When checking "Yes" to whether or not a feature exists in your proposed solution (colum additional features not included in your proposed costs. If the feature requires any of the column.

-If you have other types of additional comments to make about any feature in this list, ple

-Any row where the "Yes/No" column is left blank, or marked with something other than

-When checking "Yes" to whether or not a feature is available in your mobile app(s) (colu functionality is available on at least one app without custom programming.

3.1.10 Ability to copy rubrics from one course to another course.

3.1.11 Ability to add rubric feedback.

3.1.12 Ability to create and import surveys.

3.1.13

Ability to create rules and criteria that is checked before allowing access to an assignment.

Additional Requirements

mn C), you are stating that this feature will work without custom ese, you should mark "No" and include what would be necessary

ease do so in the "Comments" column.

Yes or No, will be considered a "no" for purposes of our evaluat

mn D), you are stating that 1) your app will work on current mod

Comments

programming, third-party integration, or the purchase of y to make that feature work in the "Additional Requirements"

ion.

del iOS, iPadOS, and Android devices; and 2) that this

of 51

Voluntary Product Accessibility Template® (VPAT®)

International Edition Version 2.3 (Revised) - April 2019

About This Document................................................................................................................. 1

Essential Requirements and Best Practices for Information & Communications Technology (ICT) Vendors ............................................................................................................................ 3

Getting Started ....................................................................................................................... 3

Essential Requirements for Authors ....................................................................................... 3

Best Practices for Authors ...................................................................................................... 7

Posting the Final Document .................................................................................................... 9

Table Information for VPAT® Readers ...................................................................................10

[Company] Accessibility Conformance Report...........................................................................11

About This Document The VPAT is provided in four editions based on the guidelines/standards being evaluated. The editions are WCAG, Revised 508, EN 301 549 and International that includes all of the standards.

This is the International edition of the VPAT. It includes the following standards/guidelines:

• Web Content Accessibility Guidelines 2.0

• Web Content Accessibility Guidelines 2.1; use is optional; included for reference purposes

• Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018

• EN 301 549 Accessibility requirements suitable for public procurement of ICT products and services in Europe, - V2.1.2 (2018-08)

If you do not need to report on all the standards/guidelines then use the appropriate standard-specific VPAT edition found on the ITI Accessibility web page.

This document is broken into two main sections:

http://www.w3.org/TR/2008/REC-WCAG20-20081211

https://www.w3.org/TR/WCAG21

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines


https://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.02_60/en_301549v020102p.pdf


https://www.itic.org/policy/accessibility/vpat

of 51

• Essential Requirements and Best Practices for using the VPAT® to complete an Accessibility Conformance Report

• The VPAT Template

Please carefully review the Essential Requirements and Best Practices sections before using the VPAT to create an Accessibility Conformance Report. “Voluntary Product Accessibility Template” and “VPAT,” including the template format, are Federally Registered Service Marks of the Information Technology Industry Council (ITI). VPAT users agree not to deviate materially from the template format provided by ITI, and to use the service mark (“®”) where appropriate.

of 51

Essential Requirements and Best Practices for Information & Communications Technology (ICT)

Vendors

This section provides guidance for reporting product conformance for three major accessibility standards and guidelines using the VPAT® to produce the Accessibility Conformance Report. Deviating from these guidelines precludes vendors from referencing the template by name and/or the VPAT acronym. The purpose of these essential requirements and best practices are to promote accurate and consistent reporting of product accessibility information.

The VPAT is a template used to document a product's conformance with accessibility standards and guidelines. The purpose of the VPAT is to assist customers and buyers in making preliminary assessments regarding the availability of commercial "Electronic and Information Technology," also referred to as “Information and Communication Technology” (ICT) products and services with features that support accessibility.

Getting Started 1. Before creating a report, read all of the materials provided in this document.

2. The Information Technology Industry Council (ITI) provides the VPAT. Use of the template and service mark does not require membership in ITI.

3. Determine which accessibility standards/guidelines will be included in the product conformance report.

4. It is the vendor’s responsibility to maintain the integrity of the data in the report.

Essential Requirements for Authors The following are the minimum requirements to be a VPAT®.

1. The VPAT name and template are registered service marks of ITI. Use of the VPAT template and name requires the inclusion of the registered service mark (i.e., “VPAT®”). Users of the VPAT agree not to deviate from the Essential Requirements for Authors.

2. The template file can be used as is or replicated in a different delivery format, for example as HTML or PDF. The final conformance report must be accessible.

of 51

3. A report may contain a minimum of one applicable Standard/Guideline or any combination of the three Standards/Guidelines that are applicable to the product being reported.

4. A report must contain the following content at a minimum:

• Report Title – In the heading format of “[Company Name] Accessibility Conformance Report”

• VPAT Heading Information – Template version

• Name of Product/Version – Name of Product being reported, including version of the product

• Product Description – A brief description of the product

• Report Date – Date of report publication. At a minimum, provide the month and year of the report publication. For example, “May 2016”. If date is included ensure it is clear “4 May 2016” or “May 4, 2016”.

• Contact Information – Contact Information for follow-up questions. Listing an email is sufficient.

• Notes – Any details or further explanation about the product or the report. This section may be left blank.

• Evaluation Methods Used – Include a description of what evaluation methods were used to complete the VPAT for the product under test.

• Applicable Standards/Guidelines – A clear indication of which Standards/Guidelines this Conformance Report covers.

• The list must include only the Standards/Guidelines that were used to develop the product.

• A report must contain a minimum of one Standard/Guideline or any combination of the three Standards.

• The applicable Standards/Guidelines that may be included are:

Revised Section 508 standards – the U.S. Federal accessibility standard, published by the U.S. Access Board in the Federal Register on January 18, 2017 and corrected on January 22, 2018

Web Content Accessibility Guidelines 2.0 or WCAG 2.0 (ISO/IEC 40500)

Web Content Accessibility Guidelines 2.1 or WCAG 2.1




of 51

EN 301 549 Accessibility requirements suitable for public procurement of ICT products and services in Europe, V2.1.2 (2018-08)

• This information can be in a table format at the top of the report with the table heading ‘Standards/Guidelines’ and the reported Standards/Guidelines identified.

• Alternatively, the Standard/Guideline being reported can be clearly identified in the introductory text of the report. If multiple Standards or Guideline tables are included, each table should also be clearly identified as to the Standard or Guideline the criteria that table represents.

• Terms – Conformance level terms description section

• Tables for Each Standard or Guideline – Tables showing the responses to the criteria.

5. WCAG Conformance Information – The answers in the WCAG success criteria are based on the level of conformance being reported (Level A, AA or AAA).

o These tables are used to answer: Revised Section 508:

• Chapter 5 Software • Chapter 6 Support Documentation

EN 301 549 Standard: • Chapter 9 Web • Chapter 10 Non-Web • Chapter 11 Software • Chapter 12 Documentation and Support Services

The selected levels of WCAG 2.x Guidelines.

o The WCAG 2.1 conformance information can be included as a separate table which is referenced from the EN 301 549 responses, or as responses to specific criteria within the EN 304 549 table that map to WCAG success criteria.

o If using a summary table, due to answers applying to multiple criteria, when answering for the Revised Section 508 or EN 301 549, the answers need to be clear in what individual criteria the answer applies to. It is possible to either use a summary, selecting the worst case for the criteria, or to have separate answers or even tables for software, support documentation, authoring tools, etc., so long as the methodology used is made clear.



of 51

o If not completing a set of Standards such as Section 508 or EN 301 549, then remove the breakdown information and answer only for the WCAG criteria.

o When reporting on WCAG 2.0 criteria it is acceptable to remove the WCAG 2.1-specific criteria from the table. These are marked ‘2.1 only’ within the row.

6. Conformance Levels – The report must list the definition of the terms used in the Conformance Level column. ITI recommends the following terms. If a vendor deviates from the ITI definitions, the vendor shall reference this change in the heading Notes section. If a term is not used it can be removed from the list. The ITI definitions are:

• Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.

• Partially Supports: Some functionality of the product does not meet the criterion.

• Does Not Support: The majority of product functionality does not meet the criterion.

• Not Applicable: The criterion is not relevant to the product.

• Not Evaluated: The product has not been evaluated against the criterion. This can only be used in WCAG 2.x Level AAA.

Note: When filling in the WCAG tables, a response may use 'Supports' where one might otherwise be inclined to use 'Not Applicable'. This is in keeping with WCAG 2.0 Understanding Conformance: 'This means that if there is no content to which a success criterion applies, the success criterion is satisfied.

7. Remarks and Explanations – Detailed remarks should be provided in the Remarks and Explanations column to justify your answer in the Conformance Level column.

• When the conformance level is ‘partially supports’ or ‘does not support’, the remarks should identify:

1. The functions or features with issues

2. How they do not fully support

• If the criterion does not apply, explain why.

• If an accessible alternative is used, describe it. 8. In the Section 508 tables, when subsections of criteria do not apply to the

product, the section may be summarized or removed as long as an explanation is

https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

of 51

provided explaining why a criterion does not apply. Another alternative is to leave the table and add a summary why the section doesn’t apply. For example, in Chapter 5 the criteria in 502 and 503 will not apply to a web only application, thus those sections can be removed with a summary in the notes for the chapter, or a row in the table.

Best Practices for Authors ITI suggests that authors adopt the following best practices when using the VPAT® to create an Accessibility Conformance Report.

• Branding Header: Company logo or branding information

• Date Changes: If a report is revised, change the report date and explain the revision in the Notes section. Alternately, create a new report and explain in the Notes section that it supersedes an earlier version of the report.

• Notes: Add any notes applicable to product or the report • Additional information about the product version that the document

references • Any revisions to the document • Links to any related documents • Additional information describing the product • Additional information about what the document does or does not

cover • Information suggested by the WCAG 2.0 Conformance Claim • Information needed to satisfy ISO/IEC 17050-1:2004, Supplier’s

Declaration of Conformity

• Evaluation Methods Used – Information to enter may include the following: • Testing is based on general product knowledge • Similar to another evaluated product • Testing with assistive technologies • Published test method (provide name, publisher, URL link) • Vendor proprietary test method • Other test method

• Remarks and Explanations: This section may include: • Information regarding the testing of a given criteria.

http://www.w3.org/TR/WCAG20/#conformance-claims

http://www.w3.org/TR/WCAG20/#conformance-claims

of 51

• Information on application dependencies to support accessibility (e.g. OS, app frameworks, browsers recommended).

• How the customer can find more information about accessibility issues. One method can be to include the bug ID where customers can call the company’s customer support to get additional information.

• Known workarounds for accessibility issues.

• Legal Disclaimer: Area for any legal disclaimer text required by your organization.

• Saving Space: To reduce the size of the report it is acceptable to remove sections. Individual criteria cannot be removed, only sections at a time. Section removal is acceptable in four situations:

• When an entire standard is not being reported on, for example EN 301 549, there should be no references of it in the report.

• When an entire section is not being reported on because it doesn’t apply to the product, for example:

Chapter 4: Hardware. Information should be included in the notes for that section why it has been removed.

A card reader that doesn’t have sound could remove the criteria in section 413 Closed Caption Processing Technologies and just note the why the criteria doesn’t apply.

• When reporting on WCAG 2.0 criteria it is acceptable to remove the WCAG 2.1-specific criteria from the table. These are marked ‘2.1 only’ within the row.

• If the product is not being evaluated for a level of the criteria (for example Level AAA) then that table may be deleted.

• If a requesting customer has identified that a section of the standard does not apply, information should be included in the notes that the section has been removed.

• WCAG 2.x Tables: The WCAG 2.x criteria are shown in three tables, Level A, Level AA, and Level AAA.

• If desired, these tables can be combined into one table.

• When reporting on a level (A, AA or AAA) all criteria for that level must be answered for the particular version of WCAG that the report includes.

• Language: Use text appropriate for your audience.

of 51

• Multiple Reports: When using the VPAT to create an Accessibility Conformance Report for complex products it may be helpful to separate answers into multiple reports. For example, when a product is an Authoring Tool that also has web content and documentation. When multiple reports are used for a complex product, it is required to explain this and how to reach the other reports in the Notes section of each report.

• Criteria Text: To help conserve space in the ITI template only the criteria ID number and a short title have been included. Where possible, links have been included to the standard/guideline.

• It is acceptable to add the full text of the criteria into the cell if desired to help with understanding.

• The links to the standards/guidelines can be removed.

• Ordering of Tables: The order that the standards/guideline tables appear may be changed to facilitate reading. For example, if the Accessibility Conformance Report is for Section 508 only, the WCAG tables may be moved to follow the numbering scheme used in the Section 508 criteria.

• Guideline Section Heading Rows in Tables: The tables include heading rows to facilitate understanding the context of the criteria.

o The cells in these rows do not require answers as indicated by “Heading cell – no response required.”

o It is optional to add a response if desired. o The shading of the row is also optional. o If removing the heading rows, edit the criteria titles so it’s clear where they

apply.

Posting the Final Document • Remove the Essential Requirements and Best Practices for Information &

Communications Technology (ICT) Vendors section from the template when publishing your Accessibility Conformance Report in final form. A link on page one in the template footnotes contains a hyperlink to this document on the Information Technology Industry Council (ITI) website at: http://www.itic.org.

• Check for each required item in the VPAT® document:

• The report title [Company Name] Accessibility Conformance Report

• The “VPAT® Version 2.3 (Revised)” heading

• Name of Product/Version

of 51

• Product Description

• Report Date

• Contact Information

• Notes

• Evaluation methods used

• Applicable Standards/Guidelines

• Terms

• Report Information Check that there is a response for each criterion for ‘Conformance

Level’ and ‘Remarks and Explanations.’

• Post your final document on your company’s web site, or make the document available to customers upon request.

• Your final document should be accessible.

Table Information for VPAT® Readers For each of the standards, the criteria are listed by chapter in a table. The structures of the tables are: the first column contains the criteria being evaluated, the second column describes the level of conformance of the product regarding the criteria and the third column contains any additional remarks and explanations regarding the product.

• When sections of criteria do not apply, or deemed by the customer as not applicable, the section is noted as such and the rest of that table may be removed for that section.

• When multiple standards are being recorded in this document, the duplicative sections are noted and responded to only one time. The duplicate entry will note the cross reference to the data.

__________________________________ “Voluntary Product Accessibility Template” and “VPAT” are registered service marks of the Information Technology Industry Council (ITI) Page 11 of 51

[Company] Accessibility Conformance Report International Edition VPAT® Version 2.3 (Revised) – April 2019

Name of Product/Version:

Product Description:

Report Date:

Contact Information:

Notes:

Evaluation Methods Used:

Applicable Standards/Guidelines This report covers the degree of conformance for the following accessibility standard/guidelines:

Standard/Guideline Included In Report Web Content Accessibility Guidelines 2.0 Level A (Yes / No )

Level AA (Yes / No ) Level AAA (Yes / No )

Web Content Accessibility Guidelines 2.1 Level A (Yes / No )



of 51

Level AA (Yes / No ) Level AAA (Yes / No )

Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018

(Yes / No )

EN 301 549 Accessibility requirements suitable for public procurement of ICT products and services in Europe, - V2.1.2 (2018-08)

(Yes / No )

Terms The terms used in the Conformance Level information are defined as follows:

• Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.

• Partially Supports: Some functionality of the product does not meet the criterion. • Does Not Support: The majority of product functionality does not meet the criterion. • Not Applicable: The criterion is not relevant to the product. • Not Evaluated: The product has not been evaluated against the criterion. This can be used only in WCAG 2.0 Level AAA.

WCAG 2.x Report Tables 1 and 2 also document conformance with:

• EN 301 549: Chapter 9 - Web, Sections 10.1-10.4 of Chapter 10 - Non-Web documents, and Sections 11.1-11.4 and 11.8.2 of Chapter 11 - Non-Web Software (open and closed functionality), and Sections 12.1.2 and 12.2.4 of Chapter 12 – Documentation

• Revised Section 508: Chapter 5 – 501.1 Scope, 504.2 Content Creation or Editing, and Chapter 6 – 602.3 Electronic Support Documentation.

Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.0 Conformance Requirements.





https://www.w3.org/TR/WCAG20/#conformance-reqs

of 51

Table 1: Success Criteria, Level A Notes:

Criteria Conformance Level Remarks and Explanations 1.1.1 Non-text Content (Level A)

Also applies to: EN 301 549 Criteria

• 9.1.1.1 (Web) • 10.1.1.1 (Non-web document) • 11.1.1.1.1 (Open Functionality Software) • 11.1.1.1.2 (Closed Functionality Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)

Revised Section 508 • 501 (Web)(Software) • 504.2 (Authoring Tool) • 602.3 (Support Docs)

Web: Electronic Docs: Software: Closed: Authoring Tool:


1.2.1 Audio-only and Video-only (Prerecorded) (Level A) Also applies to: EN 301 549 Criteria

• 9.1.2.1 (Web) • 10.1.2.1 (Non-web document) • 11.1.2.1.1 (Open Functionality Software) • 11.1.2.1.2.1 and 11.1.2.1.2.2 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)




1.2.2 Captions (Prerecorded) (Level A) Web: Web:

http://www.w3.org/TR/WCAG20/#text-equiv-all

http://www.w3.org/TR/WCAG20/#media-equiv-av-only-alt

http://www.w3.org/TR/WCAG20/#media-equiv-captions

of 51

Criteria Conformance Level Remarks and Explanations Also applies to: EN 301 549 Criteria

• 9.1.2.2 (Web) • 10.1.2.2 (Non-web document) • 11.1.2.2 (Open Functionality Software) • 11.1.2.2 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)


Electronic Docs: Software: Closed: Authoring Tool:


1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) Also applies to: EN 301 549 Criteria

• 9.1.2.3 (Web) • 10.1.2.3 (Non-web document) • 11.1.2.3.1 (Open Functionality Software) • 11.1.2.3.2 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)




1.3.1 Info and Relationships (Level A) Also applies to: EN 301 549 Criteria

• 9.1.3.1 (Web) • 10.1.3.1 (Non-web document) • 11.1.3.1.1 (Open Functionality Software)



http://www.w3.org/TR/WCAG20/#media-equiv-audio-desc

http://www.w3.org/TR/WCAG20/#content-structure-separation-programmatic

of 51

Criteria Conformance Level Remarks and Explanations • 11.1.3.1.2 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)


1.3.2 Meaningful Sequence (Level A) Also applies to: EN 301 549 Criteria





1.3.3 Sensory Characteristics (Level A) Also applies to: EN 301 549 Criteria


Revised Section 508



http://www.w3.org/TR/WCAG20/#content-structure-separation-sequence

http://www.w3.org/TR/WCAG20/#content-structure-separation-understanding

of 51

Criteria Conformance Level Remarks and Explanations • 501 (Web)(Software) • 504.2 (Authoring Tool) • 602.3 (Support Docs)

1.4.1 Use of Color (Level A) Also applies to: EN 301 549 Criteria





1.4.2 Audio Control (Level A) Also applies to: EN 301 549 Criteria





2.1.1 Keyboard (Level A) Web: Web:

http://www.w3.org/TR/WCAG20/#visual-audio-contrast-without-color

http://www.w3.org/TR/WCAG20/#visual-audio-contrast-dis-audio

http://www.w3.org/TR/WCAG20/#keyboard-operation-keyboard-operable

of 51






2.1.2 No Keyboard Trap (Level A) Also applies to: EN 301 549 Criteria





2.1.4 Character Key Shortcuts (Level A 2.1 only) Also applies to: EN 301 549 Criteria

• 9.2.1.4 (Web) • 10.2.1.4 (Non-web document) • 11.2.1.4.1 (Open Functionality Software)



http://www.w3.org/TR/WCAG20/#keyboard-operation-trapping

https://www.w3.org/TR/WCAG21/#character-key-shortcuts

of 51

Criteria Conformance Level Remarks and Explanations • 11.2.1.4.2 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)

Revised Section 508 – Does not apply 2.2.1 Timing Adjustable (Level A)






2.2.2 Pause, Stop, Hide (Level A) Also applies to: EN 301 549 Criteria





http://www.w3.org/TR/WCAG20/#time-limits-required-behaviors

http://www.w3.org/TR/WCAG20/#time-limits-pause

of 51

Criteria Conformance Level Remarks and Explanations 2.3.1 Three Flashes or Below Threshold (Level A)


• 9.2.3.1 (Web) • 10.2.3.1 (Non-web document) • 11.2.3.1 (Open Functionality Software) • 11.2.3.1(Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)




2.4.1 Bypass Blocks (Level A) Also applies to: EN 301 549 Criteria

• 9.2.4.1 (Web) • 10.2.4.1 (Non-web document) – Does not apply • 11.2.4.1 (Open Functionality Software) – Does not apply • 11.2.4.1 (Closed Software) – Does not apply • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)

Revised Section 508 • 501 (Web)(Software) – Does not apply to non-web software • 504.2 (Authoring Tool) • 602.3 (Support Docs) – Does not apply to non-web docs

Web: Electronic Docs: Authoring Tool:


2.4.2 Page Titled (Level A) Also applies to: EN 301 549 Criteria

• 9.2.4.2 (Web) • 10.2.4.2 (Non-web document)

Web: Electronic Docs: Software: Authoring Tool:


http://www.w3.org/TR/WCAG20/#seizure-does-not-violate

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-skip

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-title

of 51

Criteria Conformance Level Remarks and Explanations • 11.2.4.2 (Open Functionality Software) - Does not apply • 11.2.4.2 (Closed Software) – Does not apply • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)


2.4.3 Focus Order (Level A) Also applies to: EN 301 549 Criteria





2.4.4 Link Purpose (In Context) (Level A) Also applies to: EN 301 549 Criteria

• 9.2.4.4 (Web) • 10.2.4.4 (Non-web document) • 11.2.4.4 (Open Functionality Software) • 11.2.4.4 (Closed Software • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs)



http://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-order

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-refs

of 51

Criteria Conformance Level Remarks and Explanations • 12.2.4 (Support Docs)


2.5.1 Pointer Gestures (Level A 2.1 only) Also applies to: EN 301 549 Criteria


Revised Section 508 – Does not apply



2.5.2 Pointer Cancellation (Level A 2.1 only) Also applies to: EN 301 549 Criteria





2.5.3 Label in Name (Level A 2.1 only) Also applies to: EN 301 549 Criteria

• 9.2.5.3 (Web) • 10.2.5.3 (Non-web document) • 11.2.5.3 (Open Functionality Software)



https://www.w3.org/TR/WCAG21/#pointer-gestures

https://www.w3.org/TR/WCAG21/#pointer-cancellation

https://www.w3.org/TR/WCAG21/#label-in-name

of 51

Criteria Conformance Level Remarks and Explanations • 11.2.5.3 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)

Revised Section 508 – Does not apply 2.5.4 Motion Actuation (Level A 2.1 only)


• 9.2.5.4 (Web) • 10.2.5.4 (Non-web document) • 11.2.5.4 (Open Functionality Software) • 11.2.5.4 (Closed Software • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)




3.1.1 Language of Page (Level A) Also applies to: EN 301 549 Criteria





3.2.1 On Focus (Level A) Also applies to: EN 301 549 Criteria

Web: Electronic Docs: Software:

Web: Electronic Docs: Software:

https://www.w3.org/TR/WCAG21/#motion-actuation

http://www.w3.org/TR/WCAG20/#meaning-doc-lang-id

http://www.w3.org/TR/WCAG20/#consistent-behavior-receive-focus

of 51

Criteria Conformance Level Remarks and Explanations • 9.3.2.1 (Web) • 10.3.2.1 (Non-web document) • 11.3.2.1 (Open Functionality Software) • 11.3.2.1 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)


Closed: Authoring Tool:

Closed: Authoring Tool:

3.2.2 On Input (Level A) Also applies to: EN 301 549 Criteria





3.3.1 Error Identification (Level A) Also applies to: EN 301 549 Criteria

• 9.3.3.1 (Web) • 10.3.3.1 (Non-web document) • 11.3.3.1.1 (Open Functionality Software) • 11.3.3.1.2 (Closed Software)



http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change

http://www.w3.org/TR/WCAG20/#minimize-error-identified

of 51

Criteria Conformance Level Remarks and Explanations • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)


3.3.2 Labels or Instructions (Level A) Also applies to: EN 301 549 Criteria





4.1.1 Parsing (Level A) Also applies to: EN 301 549 Criteria

• 9.4.1.1 (Web) • 10.4.1.1 (Non-web document) • 11.4.1.1.1 (Open Functionality Software) • 11.4.1.1.2 (Closed Software) – Does not apply • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)

Revised Section 508 • 501 (Web)(Software)



http://www.w3.org/TR/WCAG20/#minimize-error-cues

http://www.w3.org/TR/WCAG20/#ensure-compat-parses

of 51

Criteria Conformance Level Remarks and Explanations • 504.2 (Authoring Tool) • 602.3 (Support Docs)

4.1.2 Name, Role, Value (Level A) Also applies to: EN 301 549 Criteria

• 9.4.1.2 (Web) • 10.4.1.2 (Non-web document) • 11.4.1.2.1 (Open Functionality Software) • 11.4.1.2.2 (Closed Software) – Not required • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)




Table 2: Success Criteria, Level AA Notes:

Criteria Conformance Level Remarks and Explanations 1.2.4 Captions (Live) (Level AA)





http://www.w3.org/TR/WCAG20/#ensure-compat-rsv

http://www.w3.org/TR/WCAG20/#media-equiv-real-time-captions

of 51

Criteria Conformance Level Remarks and Explanations Revised Section 508

• 501 (Web)(Software) • 504.2 (Authoring Tool) • 602.3 (Support Docs)

1.2.5 Audio Description (Prerecorded) (Level AA) Also applies to: EN 301 549 Criteria





1.3.4 Orientation (Level AA 2.1 only) Also applies to: EN 301 549 Criteria





1.3.5 Identify Input Purpose (Level AA 2.1 only) Also applies to: EN 301 549 Criteria

• 9.1.3.5 (Web)

Web: Electronic Docs: Software: Closed:

Web: Electronic Docs: Software: Closed:

http://www.w3.org/TR/WCAG20/#media-equiv-audio-desc-only

https://www.w3.org/TR/WCAG21/#orientation

https://www.w3.org/TR/WCAG21/#identify-input-purpose

of 51

Criteria Conformance Level Remarks and Explanations • 10.1.3.5 (Non-web document) • 11.1.3.5 (Open Functionality Software) • 11.1.3.5 (Closed Software) • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)


Authoring Tool: Authoring Tool:

1.4.3 Contrast (Minimum) (Level AA) Also applies to: EN 301 549 Criteria





1.4.4 Resize text (Level AA) Also applies to: EN 301 549 Criteria


Revised Section 508 • 501 (Web)(Software)



http://www.w3.org/TR/WCAG20/#visual-audio-contrast-contrast

http://www.w3.org/TR/WCAG20/#visual-audio-contrast-scale

of 51

Criteria Conformance Level Remarks and Explanations • 504.2 (Authoring Tool) • 602.3 (Support Docs)

1.4.5 Images of Text (Level AA) Also applies to: EN 301 549 Criteria

• 9.1.4.5 (Web) • 10.1.4.5 (Non-web document) • 11.1.4.5.1 (Open Functionality Software) • 11.1.4.5.2 (Closed Software) – Does not apply • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)




1.4.10 Reflow (Level AA 2.1 only) Also applies to: EN 301 549 Criteria





1.4.11 Non-text Contrast (Level AA 2.1 only) Also applies to: EN 301 549 Criteria




http://www.w3.org/TR/WCAG20/#visual-audio-contrast-text-presentation

https://www.w3.org/TR/WCAG21/#reflow

https://www.w3.org/TR/WCAG21/#non-text-contrast

of 51


Revised Section 508 – Does not apply 1.4.12 Text Spacing (Level AA 2.1 only)






1.4.13 Content on Hover or Focus (Level AA 2.1 only) Also applies to: EN 301 549 Criteria





2.4.5 Multiple Ways (Level AA) Also applies to: EN 301 549 Criteria

• 9.2.4.5 (Web) • 10.2.4.5 (Non-web document) – Does not apply • 11.2.4.5 (Open Functionality Software) – Does not apply



https://www.w3.org/TR/WCAG21/#text-spacing

https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-mult-loc

of 51

Criteria Conformance Level Remarks and Explanations • 11.2.4.5 (Closed Software) – Does not apply • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)


2.4.6 Headings and Labels (Level AA) Also applies to: EN 301 549 Criteria





2.4.7 Focus Visible (Level AA) Also applies to: EN 301 549 Criteria


Revised Section 508



http://www.w3.org/TR/WCAG20/#navigation-mechanisms-descriptive

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible

of 51

Criteria Conformance Level Remarks and Explanations • 501 (Web)(Software) • 504.2 (Authoring Tool) • 602.3 (Support Docs)

3.1.2 Language of Parts (Level AA) Also applies to: EN 301 549 Criteria

• 9.3.1.2 (Web) • 10.3.1.2 (Non-web document) • 11.3.1.2 (Open Functionality Software) – Does not apply • 11.3.1.2 (Closed Software) – Does not apply • 11.8.2 (Authoring Tool) • 12.1.2 (Product Docs) • 12.2.4 (Support Docs)




3.2.3 Consistent Navigation (Level AA) Also applies to: EN 301 549 Criteria





3.2.4 Consistent Identification (Level AA) Web: Web:

http://www.w3.org/TR/WCAG20/#meaning-other-lang-id

http://www.w3.org/TR/WCAG20/#consistent-behavior-consistent-locations

http://www.w3.org/TR/WCAG20/#consistent-behavior-consistent-functionality

of 51




Electronic Docs: Authoring Tool:

Electronic Docs: Authoring Tool:

3.3.3 Error Suggestion (Level AA) Also applies to: EN 301 549 Criteria





3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) Also applies to: EN 301 549 Criteria




http://www.w3.org/TR/WCAG20/#minimize-error-suggestions

http://www.w3.org/TR/WCAG20/#minimize-error-reversible

of 51



4.1.3 Status Messages (Level AA 2.1 only) Also applies to: EN 301 549 Criteria





Table 3: Success Criteria, Level AAA Notes:

Criteria Conformance Level Remarks and Explanations 1.2.6 Sign Language (Prerecorded) (Level AAA)

Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

1.2.7 Extended Audio Description (Prerecorded) (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply

Web: Web:

https://www.w3.org/TR/WCAG21/#status-messages

http://www.w3.org/TR/WCAG20/#media-equiv-sign

http://www.w3.org/TR/WCAG20/#media-equiv-extended-ad

of 51

Criteria Conformance Level Remarks and Explanations Revised Section 508 – Does not apply

1.2.8 Media Alternative (Prerecorded) (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

1.2.9 Audio-only (Live) (Level AAA) Also applies to: EN 301 549 Criteria– Does not apply Revised Section 508 – Does not apply

Web: Web:

1.3.6 Identify Purpose (Level AAA 2.1 only) Also applies to: EN 301 549 Criteria– Does not apply Revised Section 508 – Does not apply

Web: Web:

1.4.6 Contrast Enhanced (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

1.4.7 Low or No Background Audio (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

1.4.8 Visual Presentation (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

1.4.9 Images of Text (No Exception) Control (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.1.3 Keyboard (No Exception) (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

http://www.w3.org/TR/WCAG20/#media-equiv-text-doc

http://www.w3.org/TR/WCAG20/#media-equiv-live-audio-only

https://www.w3.org/TR/WCAG21/#identify-purpose

http://www.w3.org/TR/WCAG20/#visual-audio-contrast7

http://www.w3.org/TR/WCAG20/#visual-audio-contrast-noaudio

http://www.w3.org/TR/WCAG20/#visual-audio-contrast-visual-presentation

http://www.w3.org/TR/WCAG20/#visual-audio-contrast-text-images

http://www.w3.org/TR/WCAG20/#keyboard-operation-all-funcs

of 51

Criteria Conformance Level Remarks and Explanations 2.2.3 No Timing (Level AAA)

Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.2.4 Interruptions (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.2.5 Re-authenticating (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.2.6 Timeouts (Level AAA 2.1 only) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.3.2 Three Flashes (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.3.3 Animation from Interactions (Level AAA 2.1 only) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.4.8 Location (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.4.9 Link Purpose (Link Only) (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.4.10 Section Headings (Level AAA) Web: Web:

http://www.w3.org/TR/WCAG20/#time-limits-no-exceptions

http://www.w3.org/TR/WCAG20/#time-limits-postponed

http://www.w3.org/TR/WCAG20/#time-limits-server-timeout

https://www.w3.org/TR/WCAG21/#timeouts

http://www.w3.org/TR/WCAG20/#seizure-three-times

https://www.w3.org/TR/WCAG21/#animation-from-interactions

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-location

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-link

http://www.w3.org/TR/WCAG20/#navigation-mechanisms-headings

of 51

Criteria Conformance Level Remarks and Explanations Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

2.5.5 Target Size (Level AAA 2.1 only) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

2.5.6 Concurrent Input Mechanisms (Level AAA 2.1 only) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

3.1.3 Unusual Words (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

3.1.4 Abbreviations (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

3.1.5 Reading Level (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

3.1.6 Pronunciation (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

3.2.5 Change on Request (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

3.3.5 Help (Level AAA) Also applies to: Web: Web:

https://www.w3.org/TR/WCAG21/#target-size

https://www.w3.org/TR/WCAG21/#concurrent-input-mechanisms

http://www.w3.org/TR/WCAG20/#meaning-idioms

http://www.w3.org/TR/WCAG20/#meaning-located

http://www.w3.org/TR/WCAG20/#meaning-supplements

http://www.w3.org/TR/WCAG20/#meaning-pronunciation

http://www.w3.org/TR/WCAG20/#consistent-behavior-no-extreme-changes-context

http://www.w3.org/TR/WCAG20/#minimize-error-context-help

of 51

Criteria Conformance Level Remarks and Explanations EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

3.3.6 Error Prevention (All) (Level AAA) Also applies to: EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply

Web: Web:

http://www.w3.org/TR/WCAG20/#minimize-error-reversible-all

of 51

Revised Section 508 Report Notes:

Chapter 3: Functional Performance Criteria (FPC) Notes:

Criteria Conformance Level Remarks and Explanations 302.1 Without Vision 302.2 With Limited Vision 302.3 Without Perception of Color 302.4 Without Hearing 302.5 With Limited Hearing 302.6 Without Speech 302.7 With Limited Manipulation 302.8 With Limited Reach and Strength 302.9 With Limited Language, Cognitive, and Learning Abilities

Chapter 4: Hardware Notes:

Criteria Conformance Level Remarks and Explanations 402 Closed Functionality Heading cell – no response required Heading cell – no response required 402.1 General Heading cell – no response required Heading cell – no response required 402.2 Speech-Output Enabled Heading cell – no response required Heading cell – no response required 402.2.1 Information Displayed On-Screen 402.2.2 Transactional Outputs 402.2.3 Speech Delivery Type and Coordination 402.2.4 User Control 402.2.5 Braille Instructions 402.3 Volume Heading cell – no response required Heading cell – no response required

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#302-functional-performance-criteria

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#401-general

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#402-closed-functionality

of 51

Criteria Conformance Level Remarks and Explanations 402.3.1 Private Listening 402.3.2 Non-private Listening 402.4 Characters on Display Screens 402.5 Characters on Variable Message Signs 403 Biometrics Heading cell – no response required Heading cell – no response required 403.1 General 404 Preservation of Information Provided for Accessibility Heading cell – no response required Heading cell – no response required 404.1 General 405 Privacy Heading cell – no response required Heading cell – no response required 405.1 General 406 Standard Connections Heading cell – no response required Heading cell – no response required 406.1 General 407 Operable Parts Heading cell – no response required Heading cell – no response required 407.2 Contrast 407.3 Input Controls Heading cell – no response required Heading cell – no response required 407.3.1 Tactilely Discernible 407.3.2 Alphabetic Keys 407.3.3 Numeric Keys 407.4 Key Repeat 407.5 Timed Response 407.6 Operation 407.7 Tickets, Fare Cards, and Keycards 407.8 Reach Height and Depth Heading cell – no response required Heading cell – no response required 407.8.1 Vertical Reference Plane 407.8.1.1 Vertical Plane for Side Reach 407.8.1.2 Vertical Plane for Forward Reach 407.8.2 Side Reach 407.8.2.1 Unobstructed Side Reach 407.8.2.2 Obstructed Side Reach 407.8.3 Forward Reach

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#403-biometrics

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#404-preservation-information

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#405-privacy

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#406-standard-connections

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#407-operable-parts

of 51

Criteria Conformance Level Remarks and Explanations 407.8.3.1 Unobstructed Forward Reach 407.8.3.2 Obstructed Forward Reach 407.8.3.2.1 Operable Part Height for ICT with Obstructed Forward Reach 407.8.3.2.2 Knee and Toe Space under ICT with Obstructed Forward Reach

408 Display Screens Heading cell – no response required Heading cell – no response required 408.2 Visibility 408.3 Flashing 409 Status Indicators Heading cell – no response required Heading cell – no response required 409.1 General 410 Color Coding Heading cell – no response required Heading cell – no response required 410.1 General 411 Audible Signals Heading cell – no response required Heading cell – no response required 411.1 General 412 ICT with Two-Way Voice Communication Heading cell – no response required Heading cell – no response required 412.2 Volume Gain Heading cell – no response required Heading cell – no response required 412.2.1 Volume Gain for Wireline Telephones 412.2.2 Volume Gain for Non-Wireline ICT 412.3 Interference Reduction and Magnetic Coupling Heading cell – no response required Heading cell – no response required 412.3.1 Wireless Handsets 412.3.2 Wireline Handsets 412.4 Digital Encoding of Speech 412.5 Real-Time Text Functionality Reserved for future Reserved for future 412.6 Caller ID 412.7 Video Communication 412.8 Legacy TTY Support Heading cell – no response required Heading cell – no response required 412.8.1 TTY Connectability 412.8.2 Voice and Hearing Carry Over 412.8.3 Signal Compatibility 412.8.4 Voice Mail and Other Messaging Systems 413 Closed Caption Processing Technologies Heading cell – no response required Heading cell – no response required

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#408-display-screens

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#409-status-indicators

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#410-color-coding

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#411-audible-signals

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#412-two-way-communication

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#413-closed-caption

of 51

Criteria Conformance Level Remarks and Explanations 413.1.1 Decoding and Display of Closed Captions 413.1.2 Pass-Through of Closed Caption Data 414 Audio Description Processing Technologies Heading cell – no response required Heading cell – no response required 414.1.1 Digital Television Tuners 414.1.2 Other ICT 415 User Controls for Captions and Audio Descriptions Heading cell – no response required Heading cell – no response required 415.1.1 Caption Controls 415.1.2 Audio Description Controls

Chapter 5: Software Notes:

Criteria Conformance Level Remarks and Explanations 501.1 Scope – Incorporation of WCAG 2.0 AA See WCAG 2.x section See information in WCAG 2.x section 502 Interoperability with Assistive Technology Heading cell – no response required Heading cell – no response required 502.2.1 User Control of Accessibility Features 502.2.2 No Disruption of Accessibility Features 502.3 Accessibility Services Heading cell – no response required Heading cell – no response required 502.3.1 Object Information 502.3.2 Modification of Object Information 502.3.3 Row, Column, and Headers 502.3.4 Values 502.3.5 Modification of Values 502.3.6 Label Relationships 502.3.7 Hierarchical Relationships 502.3.8 Text 502.3.9 Modification of Text 502.3.10 List of Actions 502.3.11 Actions on Objects 502.3.12 Focus Cursor

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#414-audio-description

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#415-user-controls-captions-audio-descriptions


https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#502-interoperability-assistive-technology

of 51

Criteria Conformance Level Remarks and Explanations 502.3.13 Modification of Focus Cursor 502.3.14 Event Notification 502.4 Platform Accessibility Features 503 Applications Heading cell – no response required Heading cell – no response required 503.2 User Preferences 503.3 Alternative User Interfaces 503.4 User Controls for Captions and Audio Description Heading cell – no response required Heading cell – no response required 503.4.1 Caption Controls 503.4.2 Audio Description Controls 504 Authoring Tools Heading cell – no response required Heading cell – no response required 504.2 Content Creation or Editing (if not authoring tool, enter “not applicable”) See WCAG 2.x section See information in WCAG 2.x section

504.2.1 Preservation of Information Provided for Accessibility in Format Conversion

504.2.2 PDF Export 504.3 Prompts 504.4 Templates

Chapter 6: Support Documentation and Services Notes:

Criteria Conformance Level Remarks and Explanations 601.1 Scope Heading cell – no response required Heading cell – no response required 602 Support Documentation Heading cell – no response required Heading cell – no response required 602.2 Accessibility and Compatibility Features 602.3 Electronic Support Documentation See WCAG 2.x section See information in WCAG 2.x section 602.4 Alternate Formats for Non-Electronic Support Documentation 603 Support Services Heading cell – no response required Heading cell – no response required 603.2 Information on Accessibility and Compatibility Features 603.3 Accommodation of Communication Needs

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#503-applications

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#504-authoring-tools


https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#602-support-documentation

https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines#603-support-services

of 51

EN 301 549 Report Notes:

Chapter 4: Functional Performance Statements (FPS) Notes:

Criteria Conformance Level Remarks and Explanations 4.2.1 Usage without vision 4.2.2 Usage with limited vision 4.2.3 Usage without perception of colour 4.2.4 Usage without hearing 4.2.5 Usage with limited hearing 4.2.6 Usage without vocal capability 4.2.7 Usage with limited manipulation or strength 4.2.8 Usage with limited reach 4.2.9 Minimize photosensitive seizure triggers 4.2.10 Usage with limited cognition 4.2.11 Privacy

Chapter 5: Generic Requirements Notes:

Criteria Conformance Level Remarks and Explanations 5.1 Closed functionality Heading cell – no response required Heading cell – no response required 5.1.2 General Heading cell – no response required Heading cell – no response required 5.1.2.1 Closed functionality See 5.2 through 13 See information in 5.2 through 13 5.1.2.2 Assistive technology See 5.1.3 through 5.1.6 See information in 5.1.3 through 5.1.6 5.1.3 Non-visual access Heading cell – no response required Heading cell – no response required

https://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.02_60/en_301549v020102p.pdf#page=17


of 51

Criteria Conformance Level Remarks and Explanations 5.1.3.1 General 5.1.3.2 Auditory output delivery including speech 5.1.3.3 Auditory output correlation 5.1.3.4 Speech output user control 5.1.3.5 Speech output automatic interruption 5.1.3.6 Speech output for non-text content 5.1.3.7 Speech output for video information 5.1.3.8 Masked entry 5.1.3.9 Private access to personal data 5.1.3.10 Non-interfering audio output 5.1.3.11 Private listening 5.1.3.12 Speaker volume 5.1.3.13 Volume reset 5.1.3.14 Spoken languages 5.1.3.15 Non-visual error identification 5.1.3.16 Receipts, tickets, and transactional outputs 5.1.4 Functionality closed to text enlargement 5.1.5 Visual output for auditory information 5.1.6 Operation without keyboard interface Heading cell – no response required Heading cell – no response required

5.1.6.1 Closed functionality See 5.1.3.1 through 5.1.3.16 See information in 5.1.3.1 through 5.1.3.16

5.1.6.2 Input focus 5.2 Activation of accessibility features 5.3 Biometrics 5.4 Preservation of accessibility information during conversion 5.5 Operable parts Heading cell – no response required Heading cell – no response required 5.5.1 Means of operation 5.5.2 Operable parts discernibility

of 51

Criteria Conformance Level Remarks and Explanations 5.6 Locking or toggle controls Heading cell – no response required Heading cell – no response required 5.6.1 Tactile or auditory status 5.6.2 Visual status 5.7 Key repeat 5.8 Double-strike key acceptance 5.9 Simultaneous user actions

Chapter 6: ICT with Two-Way Voice Communication Notes:

Criteria Conformance Level Remarks and Explanations 6.1 Audio bandwidth for speech

6.2 Real-time text (RTT) functionality Heading cell – no response required Heading cell – no response required 6.2.1.1 RTT communication

6.2.1.2 Concurrent voice and text

6.2.2.1 Visually distinguishable display

6.2.2.2 Programmatically determinable send and receive direction

6.2.3 Interoperability

6.2.4 Real-time text responsiveness

6.3 Caller ID

6.4 Alternatives to voice-based services

6.5 Video communication Heading cell – no response required Heading cell – no response required 6.5.1 General (informative) Heading cell – no response required Heading cell – no response required 6.5.2 Resolution

6.5.3 Frame rate

6.5.4 Synchronization between audio and video

6.6 Alternatives to video-based services (advisory only) Advisory – no response required Advisory – no response required


of 51

Chapter 7: ICT with Video Capabilities Notes:

Criteria Conformance Level Remarks and Explanations 7.1 Caption processing technology Heading cell – no response required Heading cell – no response required 7.1.1 Captioning playback

7.1.2 Captioning synchronization

7.1.3 Preservation of captioning

7.2.1 Audio description playback

7.2.2 Audio description synchronization

7.2.3 Preservation of audio description

7.3 User controls for captions and audio description

Chapter 8: Hardware Notes:

Criteria Conformance Level Remarks and Explanations 8.1.1 Generic requirements Heading cell – no response required Heading cell – no response required 8.1.2 Standard connections

8.1.3 Colour

8.2 Hardware products with speech output Heading cell – no response required Heading cell – no response required 8.2.1.1 Speech volume range

8.2.1.2 Incremental volume control

8.2.2.1 Fixed-line devices

8.2.2.2 Wireless communication devices

8.3 Physical access to ICT Heading cell – no response required Heading cell – no response required 8.3.2.1 Change in level

8.3.2.2 Clear floor or ground space

8.3.2.3.1 General



of 51

Criteria Conformance Level Remarks and Explanations 8.3.2.3.2 Forward approach

8.3.2.3.3 Parallel approach

8.3.2.4 Knee and toe clearance width

8.3.2.5 Toe clearance

8.3.2.6 Knee clearance

8.3.3.1.1 Unobstructed high forward reach

8.3.3.1.2 Unobstructed low forward reach

8.3.3.1.3.1 Clear floor space

8.3.3.1.3.2 Obstructed (< 510 mm) forward reach

8.3.3.1.3.3 Obstructed (< 635 mm) forward reach

8.3.3.2.1 Unobstructed high side reach

8.3.3.2.2 Unobstructed low side reach

8.3.3.2.3.1 Obstructed (≤255 mm) side reach

8.3.3.2.3.2 Obstructed (≤610 mm) side reach

8.3.4 Visibility

8.3.5 Installation instructions

8.4 Mechanically Operable parts Heading cell – no response required Heading cell – no response required 8.4.1 Numeric keys

8.4.2.1 Means of Operation of mechanical parts

8.4.2.2 Force of operation of mechanical parts

8.4.3 Keys, tickets and fare cards

8.5 Tactile indication of speech mode

Chapter 9: Web (see WCAG 2.x section) Notes:


of 51

Chapter 10: Non-Web Software Notes:

Criteria Conformance Level Remarks and Explanations 10.0 General Heading cell – no response required Heading cell – no response required 10.1.1.1 through 10.4.1.3 See WCAG 2.x section See information in WCAG 2.x section 10.5 Caption positioning 10.6 Audio description timing

Chapter 11: Software Notes:

Criteria Conformance Level Remarks and Explanations 11.0 General Heading cell – no response required Heading cell – no response required 11.1.1.1 through 11.4.1.3 See WCAG 2.x section See information in WCAG 2.x section 11.5 Interoperability with assistive technology Heading cell – no response required Heading cell – no response required 11.5.1 Closed functionality (informative) Heading cell – no response required Heading cell – no response required 11.5.2 Accessibility services Heading cell – no response required Heading cell – no response required 11.5.2.1 Platform accessibility service support for software that provides a user interface

See 11.5.2.5 through 11.5.2.17 See information in 11.5.2.5 through 11.5.2.17

11.5.2.2 Platform accessibility service support for assistive technologies See 11.5.2.5 through 11.5.2.17 See information in 11.5.2.5 through 11.5.2.17

11.5.2.3 Use of accessibility services

11.5.2.4 Assistive technology

11.5.2.5 Object information

11.5.2.6 Row, column, and headers

11.5.2.7 Values

11.5.2.8 Label relationships

11.5.2.9 Parent-child relationships



of 51

Criteria Conformance Level Remarks and Explanations 11.5.2.10 Text

11.5.2.11 List of available actions

11.5.2.12 Execution of available actions

11.5.2.13 Tracking of focus and selection attributes

11.5.2.14 Modification of focus and selection attributes

11.5.2.15 Change notification

11.5.2.16 Modifications of states and properties

11.5.2.17 Modifications of values and text

11.6 Documented accessibility usage Heading cell – no response required Heading cell – no response required 11.6.1 User control of accessibility features

11.6.2 No disruption of accessibility features

11.7 User preferences

11.8 Authoring tools Heading cell – no response required Heading cell – no response required 11.8.1 Content technology Heading cell – no response required Heading cell – no response required 11.8.2 Accessible content creation (if not authoring tool, enter “not applicable”)

See WCAG 2.x section See information in WCAG 2.x section

11.8.3 Preservation of accessibility information in transformations

11.8.4 Repair assistance

11.8.5 Templates

Chapter 12: Documentation and Support Services Notes:

Criteria Conformance Level Remarks and Explanations 12.1 Product documentation Heading cell – no response required Heading cell – no response required 12.1.1 Accessibility and compatibility features

12.1.2 Accessible documentation See WCAG 2.x section See information in WCAG 2.x section 12.2 Support Services Heading cell – no response required Heading cell – no response required


of 51

Criteria Conformance Level Remarks and Explanations 12.2.2 Information on accessibility and compatibility features

12.2.3 Effective communication

12.2.4 Accessible documentation See WCAG 2.x section See information in WCAG 2.x section

Chapter 13: ICT Providing Relay or Emergency Service Access Notes:

Criteria Conformance Level Remarks and Explanations 13.1 Relay services requirements Heading cell – no response required Heading cell – no response required 13.1.2 Text relay services

13.1.3 Sign relay services

13.1.4 Lip-reading relay services

13.1.5 Captioned telephony services

13.1.6 Speech to speech relay services

13.2 Access to relay services

13.3 Access to emergency services

Legal Disclaimer (Company) Include your company legal disclaimer here, if needed.


Addendum D

Cost Proposal Form

Indiana State University RFP Number: B1000681

Please provide the following:

Year 1 Year 2 Year 3 Years 4-5 Initiation, Set-Up, or Membership Fees

Enterprise Software, Annual Fee

Custom Services: Annual Fee

Additional Products or Services Required For Proposed Solution to Function As Proposed (Itemize and Describe)

Additional Recommended but not Required Products or Services (Itemize and Describe)

All Other Charges and Fees (Itemize and Describe)

Proposed Cap on License, Fee, Subscription, or Service Increases: Years 6-7

TOTAL FIRST Year COST of Proposed Solution $

TOTAL 3 Year COST of Proposed Solution $



41

February 12, 2020 ADDENDUM #1 This addendum gives supplemental information to the Specification B1000681 LMS System , and becomes part of the contract document.

To All Bidders: Question: We also had one question internally in regards to the video submissions. Would a web accessible or USB version be acceptable versus the requested DVD?

Answer:

This is something we missed on the RFP. Not only is a web accessible or USB version acceptable, it is actually preferred. A DVD is acceptable though and will not affect the review of your bid.

February 12, 2020 ADDENDUM #2 This addendum gives supplemental information to the Specification B1000681 LMS System , and becomes part of the contract document.

To All Bidders: Question: Additional information requested: Please indicate in your RFP response how and where you store data How you use and/or transfer the data/analytical information that is collected or maintained in your system This information is critical to ISU, so please include and label as response to addendum 2 in a separate section of your bid.

request for proposal b1000681 - non capital... · 2020. 2. 12. · page 1 of 2 . 2/12/2020 ....

Documents