The Lab Rubric specifies that the compiler or runtime interpreter should provide errors in textual format, and that breakpoints, stepping, variable names, etc. should all be compatible with keyboard shortcuts and screen readers.

The ability to test and debug code is a learning outcome in many of our programming classes. It is also one of the most difficult skills for many of our students to master (both students with impairments and students without impairments). In addition, debugging is likely to provide special accessibility challenges in many IDEs. Most debuggers provide the ability to set breakpoints, watch variable values, and to step thorough the code. In addition, highlighting errors is common. Even in development environments that are mostly accessible, much of this information may not be compatible with screen reader programs. For example, here is a screen capture of a VBA program with a bug:

A screen capture of a VBA program with a bug.

When I press F5 to run this code, the Lab Form dialog pops up:

A screen capture of the Lab Form dialog.

When I press the Run Lab button, I get the following error message:

A screen capture of the Lab Form dialog.

This error dialog is compatible with the screen reader, and I hear that I have a compile error, "Method or data member not found." When I click OK, I am returned to the Visual Basic Developer's Window. What I see is that ".Value" has been highlighted:

A screen capture of the Lab Form dialog.

however, that isn't what the screen reader reads. Instead, it reads the entirety of the following two lines:

Private Sub DriverModule_Click() '<<< DO NOT CHANGE THIS LINE
    LabelOut.Caption = LabelOut.Value & "Hello World!" & vbNewLine

As you can imagine, this presents additional difficulty for a student who is unable to see the highlighting. However, it is possible for the student to navigate through the code using the arrow keys, toggle breakpoints, and step through the code using keyboard shortcuts. Generally speaking, it is likely that a blind student will need some help from an Assistive Aid to debug their code, and will likely need your help as the instructor as well (the Assistive Aid is unlikely to have the necessary subject matter expertise to help the student debug their code fully). There are three techniques you can use to make this process somewhat easier for the student:

It is worth noting that providing detailed examples of using the debugger and using an incremental development process may also help your sighted students to gain proficiency when debugging their code.

Whenever possible, avoid development environments where:

Note that if the debugger is not accessible, then the student may still be able to complete the lab with your help, but will probably not be able to satisfy a learning outcome that specifies that the student will be able to test and debug their code.

Accessibility Survival Guide for Instructors, © 2014 by their respective authors, Marc Goodman, Gayathri Iyer, Supada Amornchat, Karen Sorensen, and Susan Watson