Student Technology Requirements for Courses or Programs
Before a school, department, program, or faculty member requires students to purchase (or otherwise have access to) computer software or hardware for a course or program, the dean of the appropriate college must approve the requirement. Such approval is required only if the anticipated cost to a student for the required software and hardware exceeds $150. The anticipated cost should be calculated on a non-cumulative basis such that each requirement will be calculated separately regardless of whether multiple requirements will apply to a particular student in a particular class. When calculating this amount, the anticipated cost includes the software and hardware required and the software and hardware necessary to operate or use the required software and hardware.
This policy does not apply when technology is not actually required. The policy does not apply to electronic textbooks. This policy also does not apply when technology is merely suggested or recommended. This policy also does not apply to computer system, web browser, and similar requirements associated with online courses to the extent such requirements are generally necessary for students to successfully participate in online education.
To obtain approval, the appropriate department head must submit a written proposal to the dean (or the dean’s designee) at least nine months before the anticipated implementation of the technology requirement. The dean (or the dean’s designee) will communicate with the Provost’s Office about the proposal and endeavor to approve or deny the proposal within 30 days after receiving it. A proposal must be approved in time to include notification about the technology requirement in the initial version of the course schedule for the term in which the requirement will be implemented.
The written proposal must:
- Describe the technology that will be required and explain the reasons the department head believes the requirement should be implemented (including a discussion of how—and the extent to which—the technology will be used in the course or program).
- Discuss what steps have been taken to interact with faculty, students, and other stakeholders about the technology requirement and describe their reactions, remarks, and recommendations. At a minimum, before submitting the written proposal to the dean (or the dean’s designee), the department head must (1) submit a draft proposal to the Chief Information Officer (or designee), the Director of the Disability Resource Center (or designee), and the Information Technology Council; and (2) give them a meaningful opportunity to review the proposal, propose modifications to it, and give input on and make recommendations regarding the proposal. Department heads should obtain the signature of the above-listed stakeholders on a Student Technology Requirement Proposal Input Form and submit the completed form with their proposal. Unless a stakeholder and the department head agree otherwise, each stakeholder shall have 20 days following receipt of the form to review the draft proposal, complete the form, and return the form to the department head.
- Discuss what steps have been or will be taken to ensure that students receive timely notification of the technology requirement (through formal and informal communications between faculty and students, notations in the catalog and schedule, etc.).
- Estimate the anticipated cost to students for the required technology and discuss what steps have been or will be taken to ensure that students will have access to the required technology even if they are unable to purchase or lease it (through a departmental loaner program or otherwise).
The dean should discuss the proposal with the Provost’s Office and evaluate all relevant factors in determining whether to approve or deny the proposal. No single factor is decisive, and the factors should be weighed so the dean can make an informed decision. Relevant factors include:
- Whether the proposal meets the requirements sets forth above and properly addresses the above listed topics to the dean’s satisfaction. Most notably, the dean should not approve the proposal unless the dean believes there is sufficient justification to implement the requirement and the benefits associated with the requirement outweigh the costs.
- Recommendations received from stakeholders. Most notably, if the Chief Information Officer (or designee) or the Director of the Disability Resource Center (or designee) recommend that the proposal be denied because of issues related to infrastructure capacity and/or compliance with applicable disability discrimination laws, the proposal should rarely (if ever) be approved.
- Whether a less restrictive and/or less expensive requirement would suffice. Less expensive technology should be preferred over more expensive technology when the less expensive technology is sufficient for the proposed use. Students should not be required to purchase technology if it is sufficient for students to legally access the technology through other means. When appropriate, rather than requiring students to have access to particular brands or models of hardware, students should only be required to have access to particular applications or software (along with hardware capable of running the software), and decisions regarding hardware should be left to students’ discretion. Additionally, preference should be given to software that is capable of running on multiple brands or models of hardware and operating systems.
- Whether the requirement creates an undue risk of students having to purchase multiple devices, software, and other technologies that perform similar functions. Effort should be made to minimize situations where students will be required to have a device or software for one course and a different device or software that performs a similar function for another course. These efforts may include (1) approving technology requirements only for upper level courses taken by students who have declared a major, (2) approving software requirements only if the software can be run on all of the commonly used operating systems and brands of hardware, and (3) if it is necessary to approve software capable of running on only one operating system and/or brand of hardware, ensuring that all other software required by the department can also be run on that operating system and/or brand of hardware.
- Whether sufficient funds and plans are in place to provide the required technology to students under appropriate circumstances. In order to respond to student needs, departments should have to expend their own resources to provide required technologies as loaner devices under certain circumstances. The methods by which this should occur vary significantly from situation to situation and depend on the type of technology at issue, the availability of technology on campus for student use (e.g., computer labs), and the expense associated with the required technology. As a general rule, departments should provide students subject to a particular technology requirement with reasonable alternative access to the required technology.
After a technology requirement has been approved, the dean (or the dean’s designee) shall immediately notify the Registrar (or designee), the Director of the Bookstore (or designee), and the Chief Financial Officer (or designee) of the requirement.
The Provost (or designee) has discretion to authorize student technology requirements without following the procedures outlined in this policy. Requests for such a policy exception should be directed to the Office of the Provost.
Regardless of whether dean approval is required by this policy, schools, departments, programs, and faculty are responsible for ensuring that technology they use complies with applicable disability discrimination laws. As appropriate, faculty and administrators should consult with the Disability Resource Center to determine whether technology complies with such laws and is otherwise accessible to persons with disabilities.
Line of authority
Responsible administrator and office: Office of the Provost
February 1, 2013 - Revised April 15, 2013