Як можна програмувати, якщо ти сліпий?

Приціл - одне з почуттів, яке більшість програмістів сприймає як належне. Більшість програмістів проводять години, переглядаючи монітор комп’ютера (особливо в часи, коли вони перебувають у зоні ), але я знаю, що є сліпі програмісти (наприклад, ТВ Раман, який наразі працює в Google).

Якби ви були сліпими (або повільно ставали сліпими), як би ви створили своє середовище розвитку, щоб допомогти вам у програмуванні?

(Одне пропозиція на відповідь, будь ласка. Мета цього питання - довести хороші ідеї до початку. Крім того, читачі екрану можуть прочитати гарні ідеї раніше.)

Я абсолютно сліпий студент коледжу, який мав кілька стажувань з програмування, тому моя відповідь буде грунтуватися на цих. Я використовую Windows xp як свою операційну систему та Jaws, щоб прочитати те, що з’являється на екрані для мене в синтетичному мовленні. Для програмування java я використовую eclipse, оскільки це доступний повнофункціональний IDE.

На мій досвід, як загальне правило, програми java, які використовують SWT як інструментарій GUI, є більш доступними, ніж програми, які використовують Swing, тому я тримаюся подалі від netbeans. Для будь-якого програмування .net я використовую візуальну студію 2005 року, оскільки це була стандартна версія, що використовується в моєму стажуванні, і вона дуже доступна за допомогою Jaws та набору сценаріїв, розроблених для того, щоб зробити такі речі, як дизайнер форми, більш доступними.

Для програмування на C і C ++ я використовую cygwin з gcc як мій компілятор і emacs або vim як мій редактор залежно від того, що мені потрібно зробити. Багато мого стажування стосувалося програмування для Z / OS. Я використовував сеанс "rlogin" через Cygwin для доступу до підсистеми USS на мейнфреймі та C3270 як мій емулятор 3270 для доступу до ISPF частини мейнфрейму.

Зазвичай я покладаюся на синтетичну промову, але на екрані є шрифтом Брайля. Я вважаю, що зазвичай швидше працюю з мовою, але використовую брайлівський дисплей у ситуаціях, коли пунктуація має значення і ускладнюється. Приклади цього є, якщо висловлювання з великою кількістю вкладених дужок та JCL, де пунктуація є надзвичайно важливою.

Оновлення

Я граю з Emacspeak під cygwin http://emacspeak.sourceforge.net Я не впевнений, чи це буде корисно як редактор програмування, оскільки воно виглядає дещо невідповідальним, але я не переглянув жоден із параметрів конфігурації поки що.

Я сліпий, і близько 13 років програмую на Windows, Mac, Linux та DOS, мовами C / C ++, Python, Java, C # та різних менших мовах. Хоча початкове питання стосувалося налаштування середовища, я думаю, що найкраще відповісти, поглянувши на те, як сліпа людина буде користуватися комп’ютером.

Деякі люди використовують середовище розмов, наприклад, телевізор Раман та середовище Emacspeak, згадане в інших відповідях. Більш поширеним рішенням на сьогоднішній день є наявність екранного зчитувача, який працює у фоновому режимі моніторингу діяльності ОС та попереджає користувача за допомогою синтетичної мови або фізичного дисплея шрифтом Брайля (зазвичай показує десь від 20 до 80 символів одночасно). Це означає, що сліпа людина може користуватися будь-яким доступним додатком.

Отже, я особисто зараз використовую Visual Studio 2008 і запускаю його з дуже невеликими модифікаціями. Я вимикаю певні функції, такі як відображення помилок під час введення тексту, оскільки мені це відволікає. До приходу в Майкрософт усі мої розробки проходили в стандартному текстовому редакторі, як «Блокнот», так що знову не було налаштувань.

Можна налаштувати зчитувач екрану, щоб оголосити відступи. Я особисто цим не користуюся, оскільки Visual Studio опікується цим, а C # використовує брекети. Але це було б дуже важливо для такої мови, як Python, де пробіли мають значення. Нарешті, Emacspeak використовує різні голоси / підказки для позначення різних частин синтаксису (ключові слова, коментарі, ідентифікатори тощо).

Я сліпий і був програмістом протягом останніх 12 років. В даний час я є старшим архітектором і співпрацюю з Sapient Corporation (консалтингова компанія, що базується на Кембриджі, створюючи як бізнес-рішення, що базуються на веб-основі, так і товсті клієнти). Я використовую кілька зчитувачів екранів, але в основному дотримуюся щелеп для вікон та NVDA.

Я в основному працював над платформою Microsoft та візуальною студією як своїм оточенням. Я також використовую такі інструменти, як корпоративна студія MS Sql та інші для доступу до БД, моніторингу мережі тощо. Я намагався витратити деякий час на emacspeak, але оскільки моя робота в основному базувалася на платформі MS, ніколи насправді там не проводив багато часу. Я також провів пару років, працюючи над C ++ на Linux - в основному використовувався блокнот або візуальна студія на Windows для всього кодування, а потім самби для обміну файлами з середовищем Linux. Також використовується борленд С для деяких експериментальних речей. Нещодавно пограли з python, що, як зазначали інші люди, є особливо недоброзичливим для сліпого користувача, оскільки він написаний з використанням відступу як механізму вкладання. Сказавши це, NVDA, найпопулярніший зчитувач екрану з відкритим кодом написаний повністю за допомогою python, а деякі учасники цього проекту сліпі. Особливо цікавим питанням, яке мені часто задають як архітектора, є те, як я маю справу з діаграмами - UML та visio та раціональною трояндою тощо. Visio - це, мабуть, найдоступніший інструмент для діаграм. Я зміг написати сценарії щелеп, щоб прочитати для мене раціональні діаграми троянди. Я використовував інструмент під назвою T-dub (технічне розуміння діаграм для сліпих), розроблений деяким німецьким університетом для доступу до діаграм UML 2.0. Використовував некрасивий інструмент на базі Java, який називався магічним малюнком, щоб робити керовану моделлю розробку, і був виконавцем проекту androMDA і допоміг розробити генератор коду .Net з моделі UML. Особливо цікавим питанням, яке мені часто задають як архітектора, є те, як я маю справу з діаграмами - UML та visio та раціональною трояндою тощо. Visio - це, мабуть, найдоступніший інструмент для діаграм. Я зміг написати сценарії щелеп, щоб прочитати для мене раціональні діаграми троянди. Я використовував інструмент під назвою T-dub (технічне розуміння діаграм для сліпих), розроблений деяким німецьким університетом для доступу до діаграм UML 2.0. Використовував некрасивий інструмент на базі Java, який називався магічним малюнком, щоб робити керовану моделлю розробку, і був виконавцем проекту androMDA і допоміг розробити генератор коду .Net з моделі UML. Особливо цікавим питанням, яке мені часто задають як архітектора, є те, як я маю справу з діаграмами - UML та visio та раціональною трояндою тощо. Visio - це, мабуть, найдоступніший інструмент для діаграм. Я зміг написати сценарії щелеп, щоб прочитати для мене раціональні діаграми троянди. Я використовував інструмент під назвою T-dub (технічне розуміння діаграм для сліпих), розроблений деяким німецьким університетом для доступу до діаграм UML 2.0. Використовував некрасивий інструмент на базі Java, який називався магічним малюнком, щоб робити керовану моделлю розробку, і був виконавцем проекту androMDA і допоміг розробити генератор коду .Net з моделі UML. Я зміг написати сценарії щелеп, щоб прочитати для мене раціональні діаграми троянди. Я використовував інструмент під назвою T-dub (технічне розуміння діаграм для сліпих), розроблений деяким німецьким університетом для доступу до діаграм UML 2.0. Використовував некрасивий інструмент на базі Java, який називався магічним малюнком, щоб робити керовану моделлю розробку, і був виконавцем проекту androMDA і допоміг розробити генератор коду .Net з моделі UML. Я зміг написати сценарії щелеп, щоб прочитати для мене раціональні діаграми троянди. Я використовував інструмент під назвою T-dub (технічне розуміння діаграм для сліпих), розроблений деяким німецьким університетом для доступу до діаграм UML 2.0. Використовував некрасивий інструмент на базі Java, який називався магічним малюнком, щоб робити керовану моделлю розробку, і був виконавцем проекту androMDA і допоміг розробити генератор коду .Net з моделі UML.

Взагалі, я вважаю, що найбільше процвітаю в командному середовищі, де можу працювати над своїми силами. Наприклад, хоча діаграма є надзвичайно корисною для спілкування / документації дизайну, власне процес проектування передбачає багато роздумів і мозкових штурмів, і коли дизайн був продуманий, один з ваших товаришів по команді може допомогти вам швидко скласти акуратно складений проект малюнок із нього. Люди неправильно трактують вищезазначене як відсутність незалежності чи здібностей, хоча я вважаю це чистою взаємозалежністю - так як я впевнений, що один товариш по команді ніколи не міг придумати таку розробку самостійно та в -поверніть, якщо я буду залежати від нього, щоб він задокументував дизайн, так і нехай буде. Більшість перешкод, з якими я стикаюся, - це недоступність на основі інструментів.

Я сліпий розробник і працюю під Windows, GNU Linux та MacOS X. Кожна платформа має різні робочі процеси для незрячих користувачів. Це залежить від екранного зчитувача, який використовує сліпий розробник. Інструменти розробки не повністю доступні для незрячих розробників. Я можу вводити код і використовувати функції компіляції у всіх IDE, але виникає багато проблем, якщо мені доведеться розробити інтерфейс, використовуючи інструменти проектування, як Interface Builder, XGlade або інші. Коли я розробляв Borland Delphi, я міг би додати елемент керування, наприклад, кнопку, і я міг змінити кожен візуальний атрибут елемента керування за допомогою вікна інспектора об'єктів. Багато IDE використовують вікна інспектора об'єктів для зміни візуальних та невізуальних атрибутів, але проблема для сліпого розробника полягає в додаванні нових елементів керування, оскільки метод для додавання нового елемента управління полягає в перетягуванні та перевантаженні елемента управління з палітри на полотно. Visual studio 200x використовує альтернативні методи для цього, але інтерфейс IDE змінюється в кожній новій версії, і це є великою проблемою, оскільки для читання екранів для Windows потрібна спеціальна підтримка, використовуючи сценарії, для визначення кожної області деяких нестандартних програм. Сліпий розробник може використовувати Visual studio 2008 зі своїм читачем екранів, але коли з’являється нова версія цього IDE, він повинен чекати нової версії сценаріїв для цієї версії IDE. Xcode with Builder Interface поки що не має альтернативи для перетягування та відкидання завдань. Я багато разів просив це в Apple, але вони працюють над іншими речами. Я опублікував 3 додатки в магазині додатків (Доступний тральщик, доступний фруктовий апарат та програмування RSS-програм ciegas) і мені довелося розробити весь інтерфейс за кодом. Це важка робота, але я можу керувати всіма можливостями кожного елемента управління. Eclipse має доступний редактор коду, але інші інструменти розробки, як консоль налагодження, плагіни для проектування або області документації, створюють проблеми для допоміжних інструментів для незрячих користувачів.

Документація є проблемою і для сліпих розробників. Багато зразків і демонстрацій використовують зображення, щоб показати пояснення (встановіть налаштування навколишнього середовища, як можна на малюнку)

Я думаю, що питання не бути сліпим. Питання полягає в тому, що компанії та групи розробників вважають, що доступність впливає на остаточне програмне забезпечення, але це не впливає на розробку програмного забезпечення. Вони вважають, що сліпий користувач повинен бути клієнтом, але сліпий не може бути партнером у розробці.

Сліпі асоціації задають доступність продуктів і послуг, але вони забули сліпих розробників. Сліпі люди можуть працювати юристами, журналістами, викладачами, але сліпий розробник - це дивне поняття навіть для сліпих. Багато разів я відчуваю себе самотнім, бо деякі мої сліпі друзі не можуть зрозуміти мою роботу.

Ви можете прочитати мою думку з цього приводу в цій статті, іспанською мовою, в моєму блозі http://www.programaraciegas.net/2010/11/05/la-accesibilidad-en-crisis-para-los-desarrolladores-ciegos/ на веб-сторінці є інструмент перекладу. Вибачте, але я не переклав.

Emacs має ряд розширень, які дозволяють незрячим користувачам маніпулювати текстовими файлами. Вам доведеться проконсультуватися з експертом по цій темі, але emacs має можливості тексту в мовлення. І, мабуть, більше.

Крім того, є BLinux:

http://leb.net/blinux/

Linux для сліпих. Був довгий час. Більше десяти років я думаю, і дуже зрілий.

Майте на увазі, що "сліпий" - це ряд умов - є такі, хто є юридично сліпими, які могли б прочитати дійсно великий монітор або за допомогою збільшення, а є такі, у кого взагалі немає зору. Я пам’ятаю однокласника в коледжі, який мав спеціальний пристрій для збільшення книг, і спеціальне програмне забезпечення, яке вона могла використовувати для збільшення частини екрана. Вона наполегливо працювала, щоб закінчити коледж, бо зір погіршувався і збирався повністю піти.

Програмування також має спектр потреб - деякі люди гарні, щоб викрутити багато і багато коду, а деякі люди краще дивляться на велику картину та архітектуру. Я б міг уявити, що зважаючи на труднощі, які накладає інтерфейс екрану, сліпота може покращити вашу здатність отримати широку картину ...

У Hanselman нещодавно був дійсно цікавий подкаст зі сліпим розробником .

Я три роки працював у Товаристві Великого Детройту для сліпих, керуючи BBS, пристосованим для сліпого доступу, і працював з низкою незрячих користувачів над тим, як краще задовольнити їхні потреби, а також із новоспеченими користувачами, щоб ознайомити їх із наявним обладнанням та пропозиції програмного забезпечення, які були доступні в той час. Якщо нічого іншого, я, принаймні, навчився читати Брайль як огородження проти випадку, коли я коли-небудь опинився в тій же ситуації!

Більшість незрячих користувачів комп’ютерів та програмістів використовують певний екран зчитування. Зокрема щелепи популярні. На щастя, більшість основних додатків сьогодні пропонують певну форму обмеженого доступу. Можливо, вам доведеться трохи налаштувати своє оточення, щоб зменшити балаканину, наприклад, подумайте про відключення Intellisense у Visual Studio.

Дисплей Брайля є менш поширеним і порівняно набагато дорожче і може показати 40 або 80 стовпців тексту, і може бути використаний , коли точне позиціонування / пунктуація важлива. Хоча зчитувач екрана можна налаштувати, щоб відбивати розділові знаки, багато людей вважають його відволікаючим, і в багатьох випадках простіше відчути свій шлях через нього. Щелепи можуть бути налаштовані для керування дисплеєм, так що ви не жонглюєте програмами доступності.

Крім того, у багатьох законно сліпих користувачів все ще залишається деяка кількість зору. Використання фонів з високою контрастністю та функцією збільшення може допомогти багатьом цим користувачам.

Використання ToggleKeys у Windows дозволить вам почути, коли ви випадково натисніть одну з модальних клавіш "caps lock", "num lock", "scroll lock" тощо.

Я знаю щонайменше одного програміста Haskell, який використовує зчитувач екрану і який явно програмує, не використовуючи правила компонування Haskell, і замість цього вирішує використовувати натомість неідіоматичні, але підтримувані {;}, замість цього, тому що йому легше / менш відволікати увагу його читачеві екрана читати розділові знаки, ніж йому, щоб з'ясувати точний відступ, який відповідає правилам компонування Haskell. На цій же ноті я почув кілька бурчання від пари сліпих програмістів про те, коли їм доводиться писати Python.

Зрештою, ти вчишся грати на свої сильні сторони.

Я не можу згадати джерело, але я чув / читав про форму звукового синтаксису "забарвлення" - так що замість призначення рядка читати як

foo дорівнює цитаті це строкова цитата

частина рядка читатиметься з різною тональністю чи голосом, щоб зробити розділення елементів чіткішим.

Слід почати проект Blinux:

http://leb.net/blinux/

У цьому проекті описано, як отримати Emacspeak (редактор з текстовим мовленням) та має багато інших ресурсів.

Я працював з однією людиною, яка зорово бачила все, але не заважала їм використовувати монітор - вони чудово працювали з програмним забезпеченням для читання екранів і витратили багато часу, використовуючи текстові програми та оболонку.

У Вікіпедії перелік пакунків для читання екранів - ще одне місце, де можна почати: http://en.wikipedia.org/wiki/List_of_screen_readers

Я аспірант в Пекіні, Китай. Я займаюся інформатикою і багато своєї роботи займаюся програмуванням. Я народжений із слабким зором, мені потрібно використовувати збільшувальні інструменти, щоб чітко бачити шрифти на екрані. Я використовую інструменти mgnify для мікрософт у Windows та використовую модуль збільшення для compiz, якщо в Linux. Я зазвичай встановлюю інструмент, щоб збільшити втричі більше, ніж початковий розмір шрифту. Для мене інструменти збільшувати - це нормально, головна проблема - швидкість, мені потрібно рухати мишкою, щоб курсори стежили за текстом, на який я дивлюсь, збільшувати мікрософт дає можливість "автоматично слідкувати за пунктами редагування тексту", які встановлюють мене з безперервний рух миші під час редагування чи кодування. Але це не завжди працює, оскільки програмне забезпечення для редагування або IDE можуть не підтримувати це. Збільшувальні засоби на Linux важко використовувати. KMag з KDE має жахливу швидкість оновлення, яка робить мої очі некомфортними, збільшувальні штекери compiz, які я зараз використовую, добре, але не мають функції автофокусування (фокусування авто слідування). iOS пропонує для мене цілком ідеальне рішення з повноекранним збільшенням, особливо на 9,7-дюймовому екрані ipad. там автофокусування не потрібне, оскільки я навряд чи використовую їх для кодування чи іншого редагування. Android надає дуже мало функцій доступності, лише як зворотний зв’язок струшування, що для мене марно. на Android немає жодних хороших збільшувальних інструментів, не кажучи вже про попередню функцію, як повноекранне збільшення на iOS. Раніше я вивчав Qt, хочу створити корисні інструменти для збільшення на Linux, навіть на android. Але навряд чи мати певний прогрес. але не має функції автофокусування (фокусування авто слідування). iOS пропонує для мене цілком ідеальне рішення з повноекранним збільшенням, особливо на 9,7-дюймовому екрані ipad. там автофокусування не потрібне, оскільки я навряд чи використовую їх для кодування чи іншого редагування. Android надає дуже мало функцій доступності, лише як зворотний зв’язок струшування, що для мене марно. на Android немає жодних хороших збільшувальних інструментів, не кажучи вже про попередню функцію, як повноекранне збільшення на iOS. Раніше я вивчав Qt, хочу створити корисні інструменти для збільшення на Linux, навіть на android. Але навряд чи мати певний прогрес. але не має функції автофокусування (фокусування авто слідування). iOS пропонує для мене цілком ідеальне рішення з повноекранним збільшенням, особливо на 9,7-дюймовому екрані ipad. там автофокусування не потрібне, оскільки я навряд чи використовую їх для кодування чи іншого редагування. Android надає дуже мало функцій доступності, лише як зворотний зв’язок струшування, що для мене марно. на Android немає жодних хороших збільшувальних інструментів, не кажучи вже про попередню функцію, як повноекранне збільшення на iOS. Раніше я вивчав Qt, хочу створити корисні інструменти для збільшення на Linux, навіть на android. Але навряд чи мати певний прогрес. Android надає дуже мало функцій доступності, лише як зворотний зв’язок струшування, що для мене марно. на Android немає жодних хороших збільшувальних інструментів, не кажучи вже про попередню функцію, як повноекранне збільшення на iOS. Раніше я вивчав Qt, хочу створити корисні інструменти для збільшення на Linux, навіть на android. Але навряд чи мати певний прогрес. Android надає дуже мало функцій доступності, лише як зворотний зв’язок струшування, що для мене марно. на Android немає жодних хороших збільшувальних інструментів, не кажучи вже про попередню функцію, як повноекранне збільшення на iOS. Раніше я вивчав Qt, хочу створити корисні інструменти для збільшення на Linux, навіть на android. Але навряд чи мати певний прогрес.

Коли я був у школі, у нас був член нашої дослідницької групи, який був сліпим. Він був трохи старшим, можливо, середини 40-х. Він розповів нам про те, як він запрограмував свій перший комп’ютер (що було задовго до того, як текстовий мовчання було звичайним), щоб вивести вміст екрану в Морзе Код. Щоб подолати очевидну проблему з курячими яйцями, йому довелося щоразу переписувати код з нуля, поки він не працював досить добре, щоб він міг його прочитати.

Тепер він використовує текст у мовленні, хоча дуже ретельно планує код, перш ніж писати його, щоб мінімізувати цикл налагодження.

Він також був досить гарний у проведенні презентацій PowerPoint, які, незважаючи на відсутність зору, настільки ж добре відформатовані, як і будь-які прозорливі ведучі.

У цій публікації в блозі є деяка інформація про те, як команда Visual Studio робить доступними свій продукт:

Візуальна студія основної команди, доступність для лабораторій

Багато програмістів використовують Emacspeak:

Emacspeak - повний аудіо робочий стіл

Ще в Новій Зеландії я знав когось із макулярною дегенерацією , тому був частково помітний. Він дуже талановитий програміст і змушений користуватися Delphi, тому що він міг працювати, розпізнаючи форми слів. Це було легше зробити з синтаксисом, схожим на Паскаль, ніж з чітко поставленим дужкою на C-ish. У нього є веб-сайт, але він, схоже, зовсім не згадує макулярну дегенерацію, тому я не буду його називати.

Я сліпий і з кількох місяців використовую VINUX (дистрибутив Linux на базі Ubuntu) з SODBEANS (версія мережевих мереж із плагіном SAPPY, що додає підтримку TTS). Це рішення працює досить добре, але іноді я віддаю перевагу запуску Win XP та NVDA для запуску багатьох сторінок на FireFox, оскільки Vinux працює не дуже добре, коли ви намагаєтесь відкрити більше 3 вікон FireFox ...

Як багато хто зазначав, emacspeak був стійкою платформою рішення для багатьох старих хакерів. Оскільки він підтримує Linux та Mac нестандартно, він став моїм переважним засобом розробки проектів Windows, наприклад, для їхнього розвитку.

До питання про те, як насправді опустити синтаксис через слуховий, на відміну від візуального, я виявив, що існує безліч методів, щоб наблизитись, якщо не до одного і того ж ігрового поля.

Слухові значки можуть стояти на місці для словесних дескрипторів для одного прикладу. Ви можете встановити тони для того, наскільки далеко відступна лінія. Чим довший тон, тим далі відступ. Оскільки тони можуть грати паралельно з текстом у мовлення, інформація надходить у ті ж часові рамки і не серіалізує передачу чогось такого основного.

Брайль може швидко та точно розшифрувати користувачеві точний синтаксис рядка. Це щось більш корисне для людей, які використовують брайль у повсякденному житті; найбільша перевага - випадковий доступ до вмісту дисплея. Оновні одиниці зазвичай мають клавіші маршрутизатора над кожною символьною коміркою, яка може розмістити курсор на цю клітинку. Немає перешкод за допомогою клавіш зі стрілками O (n) op проти доступу O (1).

Слухова розмірність (крок, швидкість, об'єм, перегин, багатство, стрес тощо) може передати поняття (ключове слово, клас, змінна, помилка тощо). Наприклад, коментарі можна прочитати монотонним виразом ... підходить, якщо можна так сказати :).

Emacs та інші редактори з меншими розмірами (Visual Studio) дозволяють кодеру сильно виконувати програму (наступний блок, блок складання, відхилення вниз, перехід до деф, перехід на дерево розбору тощо). Ви можете дуже швидко отримати «велику» картину структури цілого проекту, що робить це; з такими розширеннями, як Cedet, ви можете отримати корисність крос-платформи VS / Eclipse / тощо та в текстовому редакторі.

Можливо, напевно, можна продовжувати і далі, але в двох словах, це основа того, чому декілька з нас там зловживають у промисловості, ададемії або в наших підвалах :).

Група студентів Університету Південного Іллінойса Едвардсвіль та Університету штату Вашингтон працюють над мовою програмування для сліпих:

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

Харальд ван Бредероде - відомий голландський експерт OBA DBA, тренер та ведучий, який сліпий. Його блог містить кілька корисних порад для людей із вадами зору.

Якою в світі була б навіть клавіатура Брайля ??

Є такі речі, як брайлівські письменники, але ви ніколи не використовуєте його як пристрій введення для комп'ютера.

Якщо ви просто говорите про клавіатуру з символами шрифтом Брайля, це також буде дуже поганою ідеєю. У вас буде набагато більше ключів, щоб дістатися під час набору тексту, і все одно це буде повільніше.

Введення дотику НЕ є візуальною майстерністю, сліпа людина може це робити так само добре, як і далекоглядний.

Я думаю, що це було б добре в екстремальному програмуванні за принципом парного програмування. Якщо ви створюєте програмне забезпечення для незрячих людей, яким краще це зробити, то хтось, хто буквально би відповідав вимогам бізнесу, тому я не думаю, що це зовсім далеко не знайдено.

Що стосується написання коду, ну, якщо не було якихось відгуків, я думаю, що людина може боротися з синтаксисом. Хоча звуковий зворотний зв'язок може допомогти до певної точки.

NVDA - хороший зчитувач екрану з відкритим кодом для виграшу.

А що з винайденням якогось пристрою, який ви підключаєте до порту usb, і це, в основному, "лист гуми", який змінює себе, щоб показувати шрифт вашого коду, дозволяючи сліпим людям читати його, а не чути?

Існує безліч інструментів для допомоги незрячим або слабозорим, включаючи зворотний зв'язок з мовою та клавіатури Брайлі. http://www.rnib.org.uk/Pages/Home.aspx - це хороший веб-сайт для надання допомоги та порад щодо цих питань.

Одного разу я зустрів Сема Хартмана, він відомий розробник Debian з 2000 року і сліпий. У цьому інтерв'ю він розповідає про доступність для користувача Linux. Він використовує Debian і gnome-orca в якості читача екрана, він працює з Gnome, і "виконує порівняно гарну роботу з розмовою Iceweasel / Firefox і Libreoffice".

Конкретно кажучи про програмування, він говорить:

Хоча [gnome-orca] розмовляє з gnome-терміналом, це не дуже добре в програмі розмови терміналів, мені це зручно використовувати. Отже, я запускаю Emacs з пакетом Emacspeak. У межах цього я запускаю емулятор терміналу Emacs, а всередині цього, як правило, запускаю Screen. Для додаткової забави я часто запускаю додаткові екземпляри Emacs на внутрішніх екранах.