{"id":447384,"date":"2017-12-11T16:13:11","date_gmt":"2017-12-12T00:13:11","guid":{"rendered":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/?p=447384"},"modified":"2017-12-11T16:13:11","modified_gmt":"2017-12-12T00:13:11","slug":"codetalk-rethinking-ide-accessibility","status":"publish","type":"post","link":"https:\/\/newed.any0.dpdns.org\/en-us\/research\/blog\/codetalk-rethinking-ide-accessibility\/","title":{"rendered":"CodeTalk: Rethinking IDE accessibility"},"content":{"rendered":"
\"\"

From left, Gopal Srinivasa, Manohar Swaminathan, Venkatesh Potluri, Suresh Parthasarathy, and Priyan Vaithilingam.<\/em><\/p><\/div>\n

It is a bright afternoon in the Microsoft Research India lab<\/a>. Research Fellow, Venkatesh Potluri (opens in new tab)<\/span><\/a>, sits at his computer, frantically racing against the clock to fix one last bug before the end of the day. The computer blares into his headphones\u2014not music, but a robotic rendition of the code, as Venkatesh\u00a0uses a program called a screen reader to access applications on his computer.<\/em><\/p>\n

As his hands glide over the keyboard, the computer reads the current line of code and the contents of the various windows that adorn\u00a0the integrated development environment (IDE), a state of the art environment he uses for authoring and testing code. Venkatesh steps through the code, listening carefully and concentrating hard to retain in his mind the structures of the code file. He executes the program and after a few seconds the screen reader goes silent. Did the program complete successfully or did it terminate with an exception? Has it hit a break point? Venkatesh is not sure. He groans and decides to add log statements to his program to debug it, frustrated that he would have to spend additional time removing them before submitting his code. Meanwhile, his colleagues invite Venkatesh to join them for a tea break. He refuses, fearing he would lose the context of the file that he painstakingly created in his mind; context that would take precious time to regain\u2014time Venkatesh cannot spare. He types furiously but ends up making a mistake in the code and doesn\u2019t see the squiggly the IDE introduced to highlight the mistake. When he builds his code, he faces a plethora of new errors he has to fix before continuing to fix the original bug. \u201cAt this rate, I\u2019m having dinner in the office,\u201d he muses, as he proceeds to find the root cause for the errors on the screen.<\/em><\/p>\n

IDEs are immensely powerful tools made specifically to improve developer productivity. So why is this one not helping Venkatesh as much? It is mostly because Venkatesh is\u00a0visually impaired (VI), and many features of IDEs that are a boon to sighted developers are inaccessible to him. He is not alone. In a Stack Overflow survey of programmers, 1 percent of respondents self-identified themselves as being blind, greater than the 0.4 percent of their numbers in the general population.\u00a0To get a feel\u00a0for how visually impaired programmers work, check out this demo (opens in new tab)<\/span><\/a> from\u00a0a\u00a0teammate, Saqib Shaikh.<\/p>\n

While many IDEs, including Visual Studio and\u00a0VS Code, are accessible using a screen reader, much of the information from these systems is still conveyed visually.\u00a0Code is syntax highlighted in bright colors; errors are automatically highlighted using squiggles, and the debugger uses several windows to provide full context of a running program. Performance analysis tools use charts and graphs to highlight performance bottlenecks and architecture analysis tools use graphical models to show the\u00a0structure of code. These advanced features are generally not accessible to developers with visual impairments, because of which they cannot exploit IDEs to the fullest.<\/p>\n