This research project marked my entry into the field of accessibility. We had to conduct interviews with visually impaired programmers, take surveys, contact people from online mailing lists. We asked the same open-ended questions to our users - “What are some of the challenges you encounter while programming?” The design problem here was how can we improve the programming workflow of visually impaired programmers. The project had many challenges - one of which included keeping things into mind while doing user research with visually impaired users. This project was outcome of wealth of knowledge imparted by Professor Joyojeet Pal in his class “Technology and Accessibility”.
1. What challenges do people with visual impairment face while doing programming? 2. How can we improve the programming workflow of people with visual impairments? 3. What are some issues with existing softwares/IDE’s with regard to accessibility?
We conducted user interviews with expert programmers who were visually impaired. We also conducted surveys. After that we analysed the issues and needs in the form of affinity wall. We then came up with some design proposals and identified challenges in implementing those solutions.
We conducted interviews with expert programmers who were visually impaired. One of them was Screen Reader expert, and other was a Professor. We used 'think aloud protocol' while conducting interviews. Conducting contextual inquiry with visually impaired was different from that of sighted users. We had to keep certain things in mind like - 1. Asking consistently through interaction 2. Addressing individuals, not assistants 3. Informing about entrance and exit 4. Offering an elbow as a guide 5. Having blind participants bring their own devices 6. Spoon theory - Their time is valuable and we should appreciate them for taking part in the study
The data from the survey yielded following results in different areas. 14.3% of people described their visual acuity as less than 20/20, 42.9% of users were totally blind and remaining 42.9% had light sensitivity but unable to distinguish objects. In terms of IDEs used, it varied from person to person. More than 50% of them used Visual Studio and Eclipse. On average, they coded 20-30 hours a week. From the survey, we found that 62.5% of users were working on python for the development purposes. This was mainly because many popular screen readers like NVDA and ORCA were based on python. Since these screen readers were open source, it was easy for an expert developer to customize it as per his/her needs.
By conducting qualitative analysis using various techniques like interviews, surveys, online mailing lists and reading blogs, we designed a comprehensive persona covering all the relevant needs and frustrations.
Ali is a twenty-eight years old completely blind back-end programmer from Iraq. He was completely blind from birth, and only can perceive light. His journey into the world of programming began when he was fourteen. Books in braille were expensive so he got hold of some audio-books. One of the books that he enjoyed was ‘Visual Basic 6.0’ but he was not satisfied with simply making UI elements. He wanted to do more … to create games like the ones his brother enjoyed on PlayStation. So, he decided pursue software engineering in school.
This decision came with its own problems: there were no books for his high school or university. Although he faced discrimination in Iraq against the disabled, he achieved a 100% in every programming-related course. The only courses he didn’t get a 100% in were the ones that required illustrating graphs that he obviously can’t do, as he is blind. The law in Iraq does not allow the blind to obtain a certificate of Computer Science or any scientific stream such, so he got a degree in English Literature. He has given up trying to conform to educational systems and thinks he can learn much more by tinkering with software himself.
But life at office is not easy either. Although his technical skills are in the same level as the rest of the team, his soft skills are not as good which means he often ends up on the wrong side of his office manager. Since he is completely blind, he is naturally drawn to the back-end of web development. He uses Zend Studio (IDE for PHP) based on Eclipse to do his backend using a screen reader (he doesn’t prefer Braille as its slow). While reading code written by other programmers, he gets irritated by screen reader’s inability to understand whitespace and indentation which negatively affects his performance.
He has tricks to improve his efficiency: for instance, sometimes he turns off notification sounds for parenthesis and brackets, unless its time to debug, so that he doesn’t go crazy from repetitive descriptions. He might also substitute the default ‘left brace’ for something like ‘Lace’ or ‘begin” to save milliseconds. However, having a screen reader that reads at about 520 words per minute is a blessing for him which enables him to write books, blog and increase awareness about accessibility issues. Apart from blogging and gaming, Ali enjoys going to orchestra and makes sound effects for his games. People on the internet forums call him “Alimiracle” for his programming.
By identifying patterns from our user research, we found that main issues were related to improper feedback of screen reader in the indentation and unable to navigate code (where am I problem). We proposed a design solution for each problem.
1. Sounds of varying frequencies for navigations
We tried using sounds like “beep” with different frequencies and the sounds like “indent 1,2,..”. Each sound represented the distance of the line from the code.
2. Content Mapping
After conducting interviews, we found that for most of the general tasks, like email/file general navigation, they used a tree like file structure which helps him map the content on the screen. Taking advantage of this habit, we thought of a similar navigation style in code.
Further research can be done by analyzing the preferences of different types of sound combinations - (Beeps), (TAB TAB TAB) (Indent 1, Indent 2...and so on). Also, the sound idea didn’t suit to everyone’s style. Some people had habit of memorizing code and they wanted to stick to that way. Due to limitation in time, we were able to interview 3 people and survey 7 people. With more time and resources, more comprehensive research can be done in future. Also, our solution to sound was suitable for users programming in python, which relies on indentation heavily.