Subject Area Accessibility Study in Computer Science, CIS and CAS
During winter term, 2014, the following instructors from different computer technical fields collaborated with Disability Services and Online Learning to study the accessibility of their subject area:
- Marc Goodman, Computer Information Systems
- Gayathri Iyer, Computer Science
- Susan Watson, Computer Application Systems
Funding for instructor time was generously provided by Deans of Instruction.
Read the full report from the study or use the rubric below to evaluate your computer programming or design course for accessibility.
Programming Lab Accessibility Rubric for Visually Impaired Students
The following rubric has been developed to assess whether a programming lab is accessible to blind students. The rubric lists a set of standards that can play a role in making programming labs accessible. Each standard has been assigned one of three levels of importance: Essential, Important, and Helpful. The importance level relates to accessibility in the following ways:
- Essential: Each essential standard must be met for a blind student to complete the programming lab substantially on their own. If an essential standard is not met, then an Assistive Aid or the course instructor will be required through the entire process of completing the lab, or the student will need to be provided with an equally effective, equally integrated alternative.
- Important: If all essential standards are met, but one or more important standard is unmet, then the student will be able to complete most of the lab on their own, but will require help from an Assistive Aid or the course instructor to overcome some accessibility obstacles.
- Helpful: The student will be able to complete the lab substantially on their own if all essential and important standards are met, but will be able to work more effectively if helpful standards are also met.
The rubric consists of the following standards:
|Programming Language||Essential||The programming language is text based. Languages that are insensitive to capitalization errors and indentation are comparatively more accessible than other languages1.||The language is primarily graphical or uses a drag-and-drop metaphor for programming.2|
|Keyboard Shortcuts||Essential||The development environment provides keyboard shortcuts for all commonly used actions. Workarounds3 are available for less commonly used actions that don’t have keyboard shortcuts.||Keyboard shortcuts are unavailable and no workarounds exist.|
|Screen Reader Compatibility||Essential||Screen reader software will provide descriptive text for most user interface elements (such as buttons, menus, text labels, etc.) in the development environment. Interface elements without tab stops or other keyboard shortcuts are readable with the JAWS cursor or NVDA Object Navigation, Screen Review and Document Review.||Screen reader software does not read the majority of user interface elements, or required actions can only be performed using visual information.|
|Document Formatting||Important||Assignment documents are properly formatted for maximum compatibility with screen reader software.||Assignment documents are improperly structured and will appear as a “blob of text” to screen reader software4.|
|Diagrams||Important||If information is provided in the form of a system diagram, UML Class diagram, Use-case diagram, or other visual format, then descriptive text or tactile graphics5 are provided as an alternative to this information.||Information required to complete the lab is provided in graphical format without alternative text or descriptions.|
|Video||Important||If a video walkthrough or lecture is provided, then narration describes all of the actions that the student must perform to complete the lab.||Actions are shown in the video but not described in the narration.|
|Example Code||Important||If example code or code fragments are given, they should be presented in text format or as a screen capture with descriptive text.||Lab requires the student to manually type in text from a screen capture or other graphical format.|
|Debugging||Important||Compiler or runtime interpreter should provide errors in textual format. Breakpoints, stepping, variable values, etc. should all be compatible with keyboard shortcuts and screen readers.||Error information relies on highlighting or other visual presentation of information that is not compatible with screen readers.|
|Interface Design||Important||If the assignment requires designing and laying out user interface elements, the student will be able to do so using code.||The student is required to use a GUI-based interface design tool, which requires the use of the mouse and the screen.|
|Output Requirements||Important||Output is primarily static, textual, and is screen-reader accessible.||Output is primarily graphical or animated6.|
|Sample Output||Important||If sample output is provided, it is given in text format or as a screen capture with descriptive text that fully specifies the output requirements.||A screen capture of sample output is provided without an accompanying description or suitable alternative text.|
|Shortcuts List||Helpful||Frequently used keyboard shortcuts are provided as a separate document and are suitable for printing in Braille.||No documentation on keyboard shortcuts is provided, or an exhaustive list is provided that requires the student to search for each shortcut.|
|Instructions||Helpful||If a series of actions must be performed by the student, these instructions should be provided as a numbered list. It is also helpful to provide the keyboard shortcuts in these instructions7.||Instructions are provided in paragraph format or other unstructured block of text.|
- Textual languages that rely on indentation level for meaning, such as Python, can be used by visually impaired students with refreshable Braille displays, or using a screen reader to read character-by-character. However, this does provide an additional obstacle to accessibility.
- Some examples of primarily graphical programming languages in use at PCC include Scratch, LabVIEW and GameMaker. These languages will be extremely difficult to use for visually impaired students.
- The exact form of the workaround depends on the type of assignment and the development environment. Please see the Case Studies section for some examples.
- Document formatting is listed as “Important” in the rubric rather than as “Essential,” because if everything in the lab is accessible except the document formatting, the student will likely be able to complete most of the lab on their own, with some help from an Assistive Aid. However, the Quality Matters Rubric that PCC uses to evaluate online course shells includes additional requirements in Standard 8 that must be met for a course to be considered “ready to teach online.”
- Please see the section on Tactile Graphics for more information on this technology and its limitations.
- Examples of primarily graphical or animated output include the output from a Scratch or CeeBot program, or an interactive game written in GameMaker.
- An example of providing keyboard shortcuts in the instructions would be to specify “Type Alt+F followed by S in order to save the document,” instead of “Select Save from the File menu.”