Collaborators: Claire Kearney-Volpe, Mathura Govindarajan, Atul Varma and Chancey Fleet
P5 Accessibility Project
Making creative coding accessible.
Spring 2016 - Fall 2016
Coding is a means of production and self-expression that should be accessible to everyone. This project is an attempt to level the playing field with people that have low vision or blindness and want to learn to code. In line with The Processing Foundation’s mission to “promote software literacy” and “empower people of all interests and backgrounds to learn how to program and make creative work with code”, the Processing Accessibility Project is a community-based research and development effort involving a large stakeholder network from academia, target end-user’s interested in learning how to code and Processing’s open-source community. This document details the research done to facilitate a redesign of the Processing Foundation’s learning resources and code editors to ensure that they are accessible to people with low vision and blindness.Implementation:
Mathura Govindarajan and Claire Kearney-Volpe have been working to make the p5 IDE accessible for people with low vision and blindness. This has involved a great deal of learning, experimenting and testing.
Below are the various components of this project:
1) Cross-platform (Browser+Assistive Tech+OS combination) testing
Our P5 web IDE prototype works best in the following Browser+Assistive Tech+OS combinations:
JAWS + Internet Explorer 11+ Windows
VoiceOver + Safari + OSX
(Also works on ChromeVox+Chrome+OSX/WIndows)
2) Code Editor
One of the main components of the IDE is its edit field. The editor that was selected was CodeMirror and this was tested with various OS and screen reader combinations to determine its usability by people with low-vision and blindness.
* CodeMirror was one of the most accessible editors that is currently widely supported
* We needed to add some extra features such as line number recognition for screen readers
Results from testing codeMirror
User testing comments
Making the UI accessible
Making the UI accessible involves ensuring that all elements present in the webpage/IDE are accessible to screen readers without sacrificing any functionality. Some of the things we are implementing include:
* creating accessible elements and ensuring semantic HTML (buttons/labels/links/tables)
* including aria-live regions
* ensuring the user knows which line number they are on
* making lint messages accessible
Testing the aria-label attribute
Contribution to the IDE to help increase its accessibility
3) Creating accessible content for the output
Although the content of the canvas is impenetrable by the screenreader, it is important to ensure that the visual and spatial content be explained in some way. To do this, we added a textual counterpart to every object drawn on the canvas. This decision was made by Claire after discovering the WCAG Task Force on Canvas Accessibility ’s recommendation around the creation of Shadow DOMs.
The output contains a summary, or gist description of what is present in the canvas along with a table that contains details of objects. Both summary and table update in realtime with the sketch.
Accessible Canvas Output Scenarios
In addition to this shared implementation documentation, Mathura has documented her internship process and thoughts in her personal blog.
4) In Process/Future Directions
Inclusion of the monkey patching in the p5 IDE Website Accessibility (image alt tags and semantic HTML structuring) Inclusion of accessible IDE theme for people with low vision (High contrast mode).