视觉是大多数程序员认为理所当然的感官之一。大多数程序员会花几个小时盯着电脑显示器(尤其是在他们全神贯注的时候),但我知道有些程序员是盲人(比如目前在谷歌工作的T.V. Raman)。

如果您是一个盲人(或逐渐失明),您将如何设置您的开发环境来帮助您编程?

(每个回答一个建议。这个问题的目的是把好的想法带到最高层。此外,屏幕阅读器可以更早地阅读到好的想法。)


当前回答

我在大底特律盲人协会工作了三年,经营一个专为盲人访问而设计的BBS,并与许多盲人用户合作,以更好地满足他们的需求,并与新盲人用户合作,让他们适应当时可用的硬件和软件产品。如果不出意外的话,我至少学会了阅读盲文,以避免自己陷入同样的境地!

大多数盲人电脑用户和程序员使用某种屏幕阅读器。《大白鲨》尤其受欢迎。幸运的是,目前大多数主要应用程序都提供了某种形式的残疾人访问。你可能需要稍微调整你的环境来减少杂音,例如考虑在Visual Studio中禁用智能感知。

盲文显示器不太常见,而且相对昂贵得多,可以显示40或80列文本,并且可以在精确定位/标点符号很重要的情况下使用。虽然屏幕阅读器可以配置成快速读出标点符号,但很多人觉得这会分散注意力,而且在很多情况下,你更容易自己摸索。Jaws可以配置为驱动显示,因此您不必同时处理辅助应用程序。

此外,许多合法失明的用户仍有一定程度的视力。使用高对比度背景和放大功能可以帮助这些用户。

在Windows中使用ToggleKeys会让你听到当你不小心点击一个模式“caps lock”,“num lock”,“scroll lock”等键。

I know at least one Haskell programmer who uses a screen reader and who explicitly programs without using Haskell's layout rules, and instead opts to use the rather non-idiomatic, but supported {;}'s instead, because it is easier/less distracting for him to get his screen reader to read off punctuation than for him to figure out exact indentation that complies with Haskell's layout rules. On that same note, I've heard some grumbling from a couple of blind programmers about when they have to write Python.

最终,你学会了发挥自己的优势。

其他回答

在我读研究生的时候,我们的研究团队中有一个盲人。他年纪大一点,大概四十五岁左右。他向我们讲述了他如何编写自己的第一台计算机(那时候文本语音转换还不普及),以莫尔斯电码输出屏幕上的内容。为了克服这个明显的“先有鸡还是先有蛋”的问题,他每次都必须从头开始重写代码,直到代码能够正常工作,可以重新读给他听为止。

现在他使用文本转语音,尽管他在实际编写任何代码之前都非常彻底地计划了代码,以最小化调试循环。

他还非常擅长做ppt演讲,尽管他视力不好,但格式和其他视力正常的演讲者一样好。

来自南伊利诺伊大学爱德华维尔分校和华盛顿州立大学的一组学生正在为盲人开发一种编程语言:

http://www.youtube.com/watch?v=lC1mOSdmzFc

harald van Breederode是荷兰著名的Oracle DBA专家、培训师和演讲者,他是一位盲人。他的博客为视障人士提供了一些有用的建议。

我不记得来源,但我听说过/读过一种可听语法“着色”的形式-这样,而不是字符串赋值被读为

Foo = quote这是一个字符串引号

字符串部分将用不同的音高或声音来读,以使元素的分离更清晰。

我是个盲人,在过去的12年里一直是一名程序员。目前,我是一名高级架构师,在Sapient公司(一家总部位于剑桥的咨询公司,创建基于web和基于厚客户端的企业解决方案)工作。 我使用了几个屏幕阅读器,但大多数情况下都坚持使用Jaws用于窗口和NVDA。

I have mostly worked on the Microsoft platform and visual studio as my environment. I also use tools like the MS Sql enterprise studio and others for DB access, network monitoring etc. I tried to spend some time with emacspeak but since my work was mostly based on the MS platform, never really spent a lot of time there. I have also spent a couple of years working on C++ on linux - mostly used notepad or visual studio on windows for all the coding and then samba to share files with the linux environment. Also used borland C for some experimental stuff. Have recently been playing around with python, which as other people have noted above is particularly unfriendly for a blind user because it is written using indentation as the nesting mechanism. Having said that, NVDA, the most popular open source screen reader is written completely using python and some of the commiters on that project are themself blind. A particularly interesting question I get frequently asked as an architect is how do I deal with diagrams - UML and visio and rational rose etc. Visio is probably the most accessible diagraming tool out there. I was able to write jaws scripts to read rational rose diagrams for me. I've used a tool called T-dub (technical diagram understanding for the blind) developed by some german university for accessing UML 2.0 diagrams. Have used a java-based ugly tool called magic draw for doing model-driven development and was a commiter on the androMDA project and helped develop the .Net code generator from a UML model.

In general, I find that I thrive most in a team environment where I can work on my strengths. For example, while a diagram is extremely useful to communicate/document a design, the actual design process involves a lot of thinking and brainstorming and when the design has been thought out, one of your team mates can help you quickly put together a neatly drawn picture out of it. People incorrectly mis-construe the above to be lack of independence or ability while I see this as pure inter-dependence -- as in I am sure that the team mate alone could never have come up with that design on his/her own and in-turn, if I depend on him to document the design, so be it. Most hurdles I face are tool-based inaccessibility. For example all oracle products have been progressively declining in accessibility over the years (shame on them) and a team environment basically allows me an extra layer of defense against these over and above my screen readers and custom scripts.