Debugging

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:

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

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

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:

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:

• Provide detailed instructions for using the debugger to debug simple issues, using the appropriate keyboard shortcuts and the screen reader.
• Provide a link to common error messages that your compiler or runtime environment might produce. The more guidance you can give the student on how these error messages relate to the student's code, the more useful the error messages will be for debugging.
• Recommend that the student use an incremental development process where they implement at most a few lines of code, and test that code thoroughly before moving on to the next few lines. This will help the student to more quickly locate the errors when they occur, and will also minimize the amount of context that the student must remember during the debugging process. If at all possible, instructions provided to the student should include frequent testing points where work can be verified before proceeding.

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:

• Errors are not displayed in textual format (for example, some IDEs display error messages as stop or yield icons next to the code, or using text coloring or highlighting).
• The debugger is incompatible with screen reader software. When the user hits an error or breakpoint, does the screen reader read the current line? Can the student navigate around with the arrow keys to read line-by-line and character-by-character?
• The debugger does not have appropriate shortcut keys. Many debuggers provide buttons to pause, stop, play, step into, step out of, step over, and so on. Are there shortcut keys for all of these buttons? Alternatively, can the student navigate through these buttons using the keyboard, and will the screen reader read the buttons appropriately?

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.