The Lab Rubric specifies that output should be primarily static, textual, and screen-reader accessible.
The student must be able to run their program, input data (if appropriate), and review the results. This requires that the interface to their program be keyboard accessible, and that the output from their program be compatible with a screen reader. In particular, output that displays primarily as graphics or animation will not be compatible with screen reader software, and will be difficult or impossible for the student to review without an Assistive Aid.
An example of an assignment that meets this standard is Lab 1 (from many of our CIS 122 course shells) in VBA. The student is provided with a lab form and asked to fill out the code for the assignment. Here is a correctly completed example:
When the program is run, a Lab Form dialog appears with the following interface:
The student is able to navigate to the Run Lab button and press "enter" to click it. The program displays a series of input boxes, such as:
The screen reader reads that there is a Microsoft Word dialog and reads the prompt "Please enter the original cost of the bed." The student is able to type in the requested input and to use the tab key to navigate to the OK button. They can then press "enter" to input the information. After entering the remaining requested input and running the program for three test cases, the lab form dialog contains this output:
The screen reader is able to read the output, and the student is able to verify that the program is working correctly. However, some of our labs have output that isn't primarily textual and will not be accessible to a screen reader program. For example, in CS 133G (Introduction to Computer Games), the first lab asks the student to write a "Catch the Clown" video game. Here, the output from the program will be an image of a room with a clown sprite moving around in a zig-zag fashion. When the student clicks on the clown sprite, their score is increased. A short video of the completed assignment is below:
A blind student will not be able to complete this assignment and verify that their program works correctly without significant help. In addition to the output being primarily graphical and animated, the student will not be able to use keyboard shortcuts to provide input to the program. Other labs might allow for accessible interaction with the running program, but still have output that's not compatible with a screen reader. For example, Assignment 7 in a CIS 233J (Java Programming II) course has the student complete the following application:
Here, the student can navigate using the Fractal menu, the dropdown menu, or the buttons along the bottom, but will not be able to see that the content pane has changed, and will not be able to verify that the program is running correctly. Also, Java Access Bridge must be enabled to make even the navigable interface elements accessible to a screen reader (this setting only needs to be changed once, but the student may need to be told to make this change). Another example of inaccessible program output is a CeeBot program in which a simulated robot grips and moves a titanium cube. The output from successfully running this program is a graphical animation.
It is important to note that accommodations should not require a fundamental change to the learning outcomes for the course. For example, in CS 133G, which is a class on video games, it is an important learning activity to write a functioning video game. Rather than searching for an equally effective alternative for these activities which may not exist, it may be more appropriate for Disability Services to warn the student that there will be accessibility issues in the class. However, it is the student's right to make the ultimate decision as to whether to sign up for the course. In other cases, where it is possible to provide an accessible alternative that still satisfies learning outcomes, this is something that should be seriously considered.