Веб-разработчик
0,7
рейтинг
22 июля 2015 в 13:53

Дизайн → Как программируют слабовидящие программисты? перевод


От переводчика

Что это за пост? Он не похож на статью


Это действительно не статья. Это компиляция самых интересных, на мой взгляд, ответов на заглавный вопрос: «Как программируют слабовидящие программисты?» из обсуждения на Quora.com.

Почему я сделал перевод?


Ответы людей меня сильно впечатлили. Я никогда не думал, что люди сталкиваются с такими проблемами и не только не отчаиваются, а мужественно и смело эти проблемы преодолевают, сохраняя при этом оптимизм и радость к жизни. Это поразительно.

Как веб-разработчик, я, конечно, слышал о таинственных экранных дикторах и полумифических дисплеях Брайля. Кто-то там ими пользуется, но ведь это всё не в моём, а в каком-то совсем другом, особом, вебе, где специально обученные разработчики всё для них подготовили и по вечерам все вместе танцуют под луной.

Это не так. Совсем не так.

Нет никаких специально обученных разработчиков.

Нет никакого особого веба.

Веб один и он общий для всех. И никаких других разработчиков, кроме нас с вами, в нём нет. И именно мы с вами несём за него ответственность.

Именно мы с вами — те люди, которые делают его таким, как он есть. Именно из наших с вами рук пользователи получают веб-страницы. Разработчик — последний, кто вносит в веб-страницу правки и определяет, насколько она будет доступной для людей, которые вынуждены пользоваться вебом иначе — слепые ли они, парализованные ли, или их возможности каким-то иным образом ограничены. Это — социальная ответственность, хотим мы этого или нет.

Давайте же делать веб чуточку лучше, доступнее для всех и каждого, и пусть никто не уйдёт обиженным.


Пархам Даустэр, PHP-программист


Я — слепой PHP-программист. Способ, которым я пишу код, пожалуй, отличается от способов, упомянутых в других ответах. Прежде чем начать, давайте я немного расскажу о себе.

Я слеп от рождения. У меня никогда не было проблемы «потери зрения»: я им никогда не обладал. Это многое упрощает.

Лично я, в отличие от многих других незрячих, использую среду разработки. Мы пользуемся экранными дикторами, а интерфейсы сред разработки в большинстве своём для них плохо доступны. Например, экранным дикторам недоступны все среды разработки компании JetBrains. Это — один из минусов конкуренции в нашем обществе: люди слишком заняты заботой о большинстве, чтобы прислушиваться к меньшинству.

Я использую Zend Studio, основанную на всем известном Eclipse. Eclipse — приятное исключение: доступность реализована очень хорошо. Он доступен не полностью, но и 80% мне вполне хватает. Слепому выбирать не приходится.

Среда разработки эффективно избавляет от рутины вроде запоминания сигнатур методов, документации и множества других вещей, оставляя мне заботу о более насущных вещах (например, почему легаси-код — такой отстой).

Я не пользуюсь клавиатурой Брайля. Использовать всего лишь 6 клавиш, которые ещё и нужно нажимать одновременно для каждого символа — это слишком медленно. Сотня клавиш, которые можно очень быстро нажимать друг за другом — это намного, намного быстрее.

Дисплеем Брайля я тоже не пользуюсь. Вместо этого у меня стоит экранный диктор, настроенный на 420 слов в минуту. Это намного быстрее, чем читать с брайлевского дисплея.

Самое важное, по моему мнению, — быть впереди конкурентов. Для незрячего это уже само по себе сложно. Мы вынуждены конкурировать, не имея одного из чувств, которое есть у большинства людей в мире. Это не было бы большой проблемой, если бы не упоминавшийся мной выше конфликт интересов большинства с меньшинством. Находясь в меньшинстве, нужно находить способы получить то, что многие люди воспринимают как само собой разумеющееся. В этом, мне кажется, заключается сила, приходящая от слабости: приходится импровизировать, заставлять себя, достигать невозможного каждый день всего лишь чтобы не остаться безработным.


Томми Маквильям, мобильный инженер в Quora


Вы слышали про Python Bee? Теперь представьте что так выглядит ваш обычный день.

Одному из моих лучших друзей в старшей школе поставили диагноз «наследственная оптическая нейропатия Лебера», когда он учился в выпускном классе. НОНЛ постоянно снижала его зрение и на первом году обучения в колледже мой друг почти полностью ослеп. Его специализацией была информатика, и то, как он программировал, было одной из самых невероятных вещей, которые я видел в жизни.

В колледже он использовал комбинацию экранной лупы и экранного диктора. Экранная лупа называлась MAGic и позволяла ему увеличивать текст так, что на монитор умещалось всего лишь несколько символов. Сам монитор был огромным экраном свыше 30 дюймов, оптимизированным для слабовидящих. Экранным диктором был JAWS, хотя мой друг перепробовал множество других программ. Он говорил, что существующие программы с открытым кодом выглядят жалко в сравнении с очень дорогими программами, которыми он пользовался благодаря помощи нашей школы.

Мой друг всегда ставил экранный диктор на максимальную скорость чтения (наверное, свыше 300 слов в минуту). Для сравнения, аудиокниги обычно звучат вдвое медленнее. Для меня это звучало как совершенно другой язык, но он его отлично понимал. Мой друг предпочитал использовать абсурдно старую версию Firefox (3.5 или вроде того), потому что она лучше всего поддерживала его экранный диктор. Практически все действия он выполнял горячими клавишами, передвигаясь по приложениям и окнам с ошеломляющей скоростью. Всё это, вкупе с 40-кратным увеличением, делало практически невозможными попытки проследить за его действиями. При этом он работал эффективнее многих виденных мной программистов.

О том, как именно мой друг программировал.

Как редактор кода он использовал Emacs (думаю, из-за того, что наловчился с сумасшедшими горячими клавишами). Экранный диктор читал код, который он проматывал. Точно так же экранный диктор читал вывод терминала, так что исключалась любая возможность того, что что-то не будет озвучено. Как вы догадываетесь, программный код понять сложнее, чем английские слова. Хотя языки, не злоупотребляющие символами в синтаксисе, понимать проще. Более доступны те языки, которые «выглядят» похожими на английский, как Python, Ruby и подобные. Тем не менее, использование отступов вместо скобок довольно-таки усложняет жизнь — приходится внимательно выслушивать количество табов на каждой строке.

Чтобы вы лучше себе представляли общую картину, я расскажу забавный случай, случившийся на втором курсе. Мы изучали OCaml, функциональный язык с забавным синтаксисом. Мой друг был вынужден слушать чушь вроде let rec fib n равно return match n with return вертикальная черта один дефис больше, чем… точка с запятой точка с запятой и тому подобное. В этот день он работал с очень большим куском кода, который никак не компилировался. Он прослушивал этот нелепый синтаксис снова и снова, но не мог найти ни одной ошибки. Ничего не изменилось, пока он не пришёл в класс, где зрячий помощник преподавателя заметил, что по какой-то причине экранный диктор произносит цифру «0» как букву «О». Это был совершенно новый вид багов, с которыми не сталкиваются зрячие программисты.

Стоит также отметить, что он увлечён спецификацией доступности HTML, в особенности ARIA. Большинство сайтов в интернете её полностью игнорируют, несмотря на то, что она очень просто внедряется. То, как он пользуется сайтами с ARIA-атрибутами и без них — это небо и земля.

Сейчас он работает разработчиком ПО на полной ставке.


Стив Дони


Рон Морфорд — один из самых талантливых программистов, с которыми мне приходилось работать. У него было что-то под названием «синдром Марфана», из-за которого он полностью потерял зрение, когда ему было чуть больше двадцати. Я работал на него в начале 90-х, разрабатывая экранный диктор для Windows 3.1. Рон владел компанией Automated Functions, Inc, которая разрабатывала программы и железо для слепых. Одним из его первых продуктов был VERT. Это был ящик размером с обычный ПК, разработанный как посредник между компьютером и терминалом. Он отслеживал проходящий между ними трафик и преобразовывал его в речь. VERT мог произносить до 400 слов в минуту, а Рон их запоминал.

У Рона было невероятная память. Одним из первых проектов, которые я для него делал сразу после колледжа, был экранный диктор для DOS. Иногда я возился с ним полдня и, если у меня ничего не получалось, я шёл к Рону и спрашивал — «Что делает вот эта функция?». Рон помнил её построчно, хотя, возможно, не заглядывал в неё несколько месяцев.

До того, как Рон основал AFI, он был специалистом по компьютерной безопасности в NASA. Он рассказывал отличные истории о том, как тамошние программисты постоянно пытались хакать друг друга, чтобы найти дыры в ранних версиях Unix.

Я работал в области доступности около 8 лет, потом устроился в Microsoft и работая над реализацией доступности в Windows. За это время я видел множество слепых программистов. Они пользовались множеством разнообразных техник и инструментов, но, в основном это была стандартная клавиатура и речевой вывод. Были и клавиатуры Брайля, но мало кто пользовался ими ежедневно. На клавиатуре Брайля девять основных клавиш — по четыре для каждой руки и пробел; буквы вводятся комбинациями клавиш, составляющими алфавит Брайля. Как уже упоминали другие участники, ещё существует дисплей Брайля, с выдвигающимися и втягивающимися пластиковыми палочками. Но такие дисплеи невероятно дороги: 80-колоночный дисплей продавался за 8 000 $, хотя, я думаю, что он мог подешеветь за последние 20 лет.


Лукас Радэлли


Я абсолютно слеп. Я работаю на Google, участвую в разработке алгоритма ранжирования. По моему опыту и по тому, что я слышал от многих других слепых программистов, наш способ программирования не сильно отличается от способа наших зрячих коллег. Я пользуюсь в основном текстовым редактором (Emacs с расширением Emacspeak, озвучивающим текст) и браузером для просмотра внутренних страниц Google с документацией и прочим.

Главное отличие в том, что мы или слушаем то, что на экране, или читаем на дисплее Брайля. Ничего не могу сказать про использование этого дисплея, потому что у меня его никогда не было (слишком дорого), но могу поделиться некоторыми мыслями о том, как программировать на слух.

Самое трудное в программировании на слух в том, что нужно запоминать кучу всего. Вы двигаетесь от строки к строке, прослушивая их целиком. Можно прослушивать код пословно или же посимвольно. Отличие, как видите, в том, что одновременно доступна лишь малая часть кода. Вы не можете начать программировать, посмотрев имена входящих аргументов функции. Вы их помните. Если вам понадобится свериться с объявлением функции, то вы ставите закладку, переходите к объявлению, читаете его и возвращаетесь назад к закладке. Как можно заметить, это вовсе не мгновенный процесс, поэтому тренировка памяти становится необходимым навыком

Мне нравится программировать с помощью Emacspeak, потому что он хорошо подходит для программирования на C++. Например, в этой программе есть голосовые стили: она читает переменные, функции и другие части языка с разной интонацией. Это помогает разобраться, что есть что. Можно считать это аудиоподсветкой кода.

Напоследок, из интересного

Слепые программисты не используют выравнивание кода. Обычно мы расставляем отступы уже после написания. Нам они не приносят никакой пользы.

Вы можете спросить: а как же Python?

Мне очень правится Python и даже необходимость выравнивать код не меняет этого. Я придумал некоторые техники: например, сдвигать строку в конец каждого блока отступов — так я могу очень быстро узнать, где блок заканчивается. При чтении чужого кода можно настроить диктор, чтобы он проговаривал глубину отступов, но меня слегка раздражает выслушивать, сколько пробелов на каждой строке.


Флориан Бэйджерс


Я пришёл сюда из уведомления Slack в коммьюнити Free Code Camp и вижу что моя блогозапись упомянута дважды. Спасибо. Я это ценю и очень рад, что она оказалась полезной для стольких из людей. К сожалению, из-за каких-то проблем с доступностью, я не могу прочитать комментарии с её упоминанием. Тем не менее, я прошу всех, у кого есть вопросы, стукнуть мне в твиттер Zersiax. Обычно я отвечаю сразу же, если не сплю :-) Это обсуждение показывает, что слепые тоже пишут программы и некоторым это даже нравится.

Возвращаясь к некоторым вопросам, которые упомянуты конкретно в этом обсуждении:

Как я уже упоминал в своём блоге, я стараюсь пользоваться средой разработки. В основном это среды, основанные на Eclipse и Visual Studio, которая, по ироничному стечению обстоятельств, довольно хорошо подходит для визуально ограниченных людей, в то время как Microsoft Access совершенно не accessible (англ. accessible — «доступность», примечание переводчика). Не ирония ли это? :)

Использовать старый браузер (Firefox 3.5) просто глупо, если вы хоть немного кодите для веба. Это может быть грубо с моей стороны, но он всё равно лучше, чем IE. Вещи вроде этого — причина того, что я сейчас стремлюсь работать с экранным диктором NVDA с открытым исходным кодом. Он просто отлично работает с последним Firefox`ом.

Хотя я с радостью поучился бы работать в Vim и Emacs, мне некогда этим заниматься. Кроме того, я стараюсь работать в среде, где зрячие разработчики (в основном студенты) могут со мной взаимодействовать. Как правило, Linux их отпугивает, «Vim» для них — средство для чистки, а «Emaсs» звучит как какой-то вид магии. Поэтому я вынужден работать в редакторах с графическим интерфейсом, даже если командная строка была бы эффективнее.

Ладно, хватит на этот раз:) Спасибо за чтение.


Более развёрнутый ответ Флориана
Используете ли ARIA в проектах?

Проголосовало 522 человека. Воздержалось 166 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Перевод: Пархам Даустэр, Томми Маквильям, Стив Дони, Лукас Радэлли, Куинси Ларсон, Флориан Бэйджерси
Павел Лысенко @Ohar
карма
48,5
рейтинг 0,7
Веб-разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Дизайн

Комментарии (33)

  • +14
    Вот именно после таких постов хочется плюнуть на все ленивые мелочи, — почитать новости, сыграть полчасика в какую нибудь ерунду, и работать, работать. И плевать, что, компьютер видите ли не самый мощный, памяти не по максимуму, кресло не идеальное и все в таком духе.
    Одна проблема — ненадолго хватает запала. Человек быстро привыкает ко всему, как к плохому (пример из статьи), так и к хорошему (имея возможность самореализоваться, сделать мир действительно лучше — не пользуемся).
    • +3
      Очень вас хорошо понимаю.
    • +5
      Да уж статья не про мотивацию мотивирует получше всякого шлака по типу «Сколько часов спать, чтобы пахать как ужаленный»
    • –3
      Работаю на ноуте за 10к рублей с 1 ядром и 2 ГБ ОЗУ. Возможно не поверите, но мне очень комфортно уже года три.
      • +5
        Было время, когда я работал без компьютера, в тетради на ассемблере и меня тоже все устраивало. О чем и речь.
        Конечно на мощном компьютере с ssd и большим монитором работать комфортней, вопрос в том, насколько необходим этот комфорт. Практика показывает, что можно обойтись без всего, даже без зрения. Просто нужно ценить то что имеешь и не тратить впустую время.
        • 0
          Я же не говорю, что мне было не комфортно. Мне было настолько комфортно, что я не хотел менять менять этот комфорт на другой (не смотря на то, что в офисе конфигурации были иные).
          • +4
            Ну если для работы хватало такой конфигурации — то и хорошо. Но когда пару больших проектов в VS с прикрученным решарпером начинают выедать всю память, — приятного мало.
            Но даже если мощностей хватает, — все познается в сравнении. Посидев за качественным большим монитором — 15 дюймовая TN матрица на ноутбуке как то уже не вдохновляет. Поработав на SSD диске — постараешься в качестве системного не использовать HDD.
            Но в том то и дело, что оглядываясь на людей у которых ДЕЙСТВИТЕЛЬНО проблемы и они справляются — становится вроде как стыдно за свои «проблемы».
            • +4
              Но в том то и дело, что оглядываясь на людей у которых ДЕЙСТВИТЕЛЬНО проблемы и они справляются — становится вроде как стыдно за свои «проблемы».


              Это плохой подход. Каждый сидит на своей колокольни и для каждого человека самая большая проблема разная. Для слепого — слепота, для голодающего — что поесть, для подростка из золотого миллиарда — расставание с парой. И все они будут решать свою проблему делая мир чуть лучше. А в противном случае всем бы хватало шкуры, что-бы не замерзнуть и копья, что бы оленя заколоть.
              Поэтому когда к вам придет человек у которого угнали машину или ребенку которому в первый раз поставили двойку, отнеситесь к нему так-же как к ослепшему. У них всех самое большое горе.
              • +1
                Это нормальный подход, если хочешь стать лучше. Лишний пинок под зад, чтобы меньше фрустрировать, а больше — «руки в ноги и пахать».
                Я не призываю всех отказываться от приобретенных благ, да и сам отказываться не собираюсь. Понятно что отдых нужен, баловать себя надо, но не стоит забывать что то, что кажется нам проблемами по большому счету ими не являются.
                • +2
                  Только невежественные дураки пинают самих себя для мотивации.
                  • 0
                    Грубо, но я рад, что хоть у вас все в порядке с мотивацией.
                    • 0
                      Секрет прост: не делать ненавистные вещи. Или превращать их в приятные.
                      • +1
                        Предмет несколько сложнее. И дело не в ненависти.
                        Но это уже оффтоп.
        • 0
          мы в зоне программировать учились, в тетрадках, имея доступ к компьютеру 3 часа в неделю. И то под запретом оперов. Главное, не терять время впустую. А в рутинных буднях это происходит незаметно.
  • +3
    Воистину, что чем меньше человеку от природы достается, тем он сильнее волей…
    При чтении чужого кода можно настроить диктор, чтобы он проговаривал глубину отступов, но меня слегка раздражает выслушивать, сколько пробелов на каждой строке.
    Ноты!!! Разные ноты нужно настроить на разную глубину отступов. При тренированном слухе высота ноты должны легко различаться. Скорее всего, раз слушают на скорости 400+ слов в минуту текст, то смогут различать и отдельную 1/16 и даже 1/32. Это очень короткое не отвлекающее событие!
    • +9
      Это распространённое обывательское заблуждение, что слух у слепых какой-то особенный. Распознать точно высоту ноты (частоту звука) им не проще, чем зрячим.

      Вы, вероятно, представляете себе, что ему там произносят «пробел пробел пробел пробел пробел пробел», а он в голове подсчитывает. В действительности экранные чтецы отступы озвучивают как «3 таб» или «4 пробел», что при высокой скорости синтезатора речи вполне сопоставимо с нотой длительностью 1/16.

      Да и вообще, тут не в скорости дело. Судя по всему, человека напрягает сам факт подсчёта отступов, а с этим ничего не сделать.
      • 0
        Очень ждал вас в комментариях к этой записи. Вы очень обстоятельно разъясняете такие вопросы. Спасибо.
      • 0
        Ну кстати блоки же считать не обязательно. Я практически уверен, что можно захачить тот же Emacspeak что бы он говорил «отступ блока увеличился/уменьшился».
        • +3
          Ну так оно и работает в продвинутых экранных чтецах. Например, текст:

          Раз
          	Два
          	Три
          		Четыре
          


          При чтении по строкам будет читаться как

          раз
          1 табуляция два
          три
          2 табуляция четыре


          То есть на третей строке, которая имеет такой же иерархический уровень, что и вторая, при движении сверху вниз лишний раз отступ озвучиваться не будет. Если же идти снизу вверх, то отступ не будет зачитываться на второй строке. Правда так по-умному отступы читаются не всеми программами экранного доступа, некоторые озвучивают отступ всегда. Но с экранными дикторами всё как и с любым другим ПО — это инструмент, который надо подбирать под себя и свои задачи.
  • +1
    интересно, а используют ли слабовидящие программисты звуки для дебага(например, чтобы узнать наличие и порядок событий и вызова методов)? насколько музыкальной получается при этом мелодия?
    • 0
      Нет, информация отладчика просто выводится в отдельные диалоги со специфической логикой представления информации, что реализуется специальными кастомными расширениями на уровне экранного чтеца.
  • +4
    Кстати, с недоступностью IntelliJ IDEA вообще сейчас засада. Google прекратили поддержку Android Development Tools для Eclipse и пересаживают всех на Android Studio, которая базируется на IntelliJ IDEA. В итоге, сейчас с невизуальной доступностью разработки в IDE под Android ситуация становится критической. Через какое-то время может остаться только консольная компиляция, только хардкор. Разве что сообщество само как-то поддержит инструменты разработки под Android для Eclipse.
    • 0
      А Вы поддержке IDEA писали по этому поводу? Если есть баг у них на трекере, то напишите, я проголосую за него (как, наверное, и многие из этого типика). Они вроде открыты для изменений — нужно только написать.
      • +2
        все среды разработки компании JetBrains

        Он?
        PhpStorm и IDEA базируются на одном каркасе.
        • +1
          Да, точно! Тоже в посте его нашёл только что. Проголосовал.
      • +1
        del
      • +2
        Да в принципе они-то знают об этой проблеме, просто её не рейтингуют достаточно высоко. Этот вопрос поднимался и в технических рассылках Google, типа «что же вы творите, Android Studio совсем недоступна», причём ещё до стабилизации релиза.

        У Java-интерфейсов с доступностью всё достаточно сложно. Если интерфейс изначально разработан на базе недоступных контролов, то его адаптация — это адская работа по переписыванию буквально всего. Вряд ли разработчики готовы на такой подвиг ради нескольких абстрактных пользователей.

        Конечно, если бы руководитель проекта лично бы столкнулся с незрячим программистом, который испытывает проблемы от недоступности среды, или если бы вообще в компанию пришёл незрячий сотрудник, то это могло бы изменить отношение. Ну а пока такие проблемы для лиц, принимающих решения, остаются просто каким-то маргинальным тикитом, вряд ли что-то сдвинется.

        В лицо послать трудно даже одного пользователя, а когда он просто в виде нулей и единиц где-то в багтрекере, то это всего лишь статистика.
  • +1
    Есть ли какие-то ресурсы, которые проверяют доступность сайта для незрячих? Или хотя бы какие-нибудь мануалы, как именно это проверять?

    Второй вопрос — каким образом они взаимодействуют с мобайлом? Тоже дикторы? Если да, то тот же вопрос для мобильных приложений — есть ли какие-то ресурсы по проверки или мануалы о том, как.
    • +7
      Стандартизацией web accessibility занимается несколько рабочих групп внутри W3C. Они же отвечают и за документацию, которой уже достаточно много (см. WAI-ARIA Overview).

      Средства автоматизированной проверки web-доступности есть, но, честно говоря, они достаточно примитивны: обычно просто ловят неподписанные картинки и формы. Например, нефокусируемый элемент управления они вам вряд ли поймают.

      В принципе, если почитать стандарт WCAG 2.0 (в большей степени менеджерский и общефилософский) и стандарт WAI-ARIA 1.0 (конкретная техническая спецификация), то они дадут понимание того, как делать не нужно, а как нужно. Этого обычно хватает для того, чтобы не допускать грубейших ошибок web accessibility и задумываться в тех местах, где это особенно важно, например, когда прикручиваете CAPTCHA. Если же стоит задача вылизать web-доступность, то без опытного QA-инженера будет сложно.

      У мобильных OS также есть экранные чтецы (у Android даже несколько) и системный accessibility API. Если интерфейс собирается из стандартных контролов, и они используются по своему прямому назначению (типа без использования в качестве кнопки участка view, на котором ловят клик), то поддержки accessibility API из коробки обычно вполне хватает для того, чтобы приложение было доступным.

      Если же в интерфейсе есть какие-то экзотические решения или просто кастомные контролы, то поддержку accessibility API может понадобиться дописывать руками. Соответствующая документация есть как для Android, так и для iOS.

      С автоматизированной проверкой application accessibility на мобильных OS ещё сложнее, зато проще с ручной. В принципе, там достаточно просто самому разработчику загрузить экранный чтец и проверить, что курсор фокусирует все элементы интерфейса, без проблем их активирует и их названия корректно прочитываются. Там довольно простое управление — достаточно тупо горизонтальными свайпами протолкать курсор чтеца по всему интерфейсу и двойным тапом по нажимать на элементы управления. Если что-то курсором не фокусируется или элемент в курсоре читается плохо, то починить.

      В принципе, существуют check листы, как для web, так и для application accessibility. Это может помочь держать себя в рамках и служить некоторой заменой полноценного тестирования QA-инженером. В Интернете таких проверочных списков достаточно много. Есть они и в официальной документации и от сторонних авторов.
      • 0
        Спасибо за ответ!

        Пока читал ваш ответ возник вопрос про капчу, немного оффтопиком. Каким образом они (незрячие) могут с ней работать? Там ведь именно что увидеть надо. Хотя, я видел капчи, где есть значок проговаривания, но никогда им не пользовался — там чистый текст говорят или какие-то помехи присутствуют?
        • 0
          Попробуйте, чистый текст.
        • 0
          У кого как, у гугла насколько я помню в звуковые капчи добавляют много искажений и шумов.
        • +1
          Да, бывают звуковые CAPTCHA. Как правило, там голосом проговаривается некоторое количество цифр, а звук зашумлён, хотя бывает и без особых искажений.

          На звуковую реализацию CAPTCHA можно посмотреть, например, у Google или Яндекса.

          Помимо общих проблем, связанных с тем, что незрячие точно также матерятся и не всегда могут разгадать с первого раза, у этого подхода есть ещё одна фундаментальная проблема. Цифры-то интернациональны, а вот их прочтение вслух завязано на конкретный язык. В частности, у того же Google звуковая reCAPTCHA торчит на весь мир в англоязычном исполнении, что не очень хорошо.

          По большому счёту, при реализации CAPTCHA я бы вообще начинал с мысли «а оно точно надо?» На мой взгляд, это нужно далеко не везде, где это сделано. К тому же есть альтернативные методы определения ботов, типа создания в форме поля с «display: none», которое пользователь не увидит в браузере, а бот, как правило, игнорирующий CSS, попытается подёргать.

          Да и вообще порой CAPTCHA делают в очень странных местах. Например, если помните, некоторое время назад нужно было вводить код с картинки при каждом входе в свой аккаунт на Хабре. По-моему очень странная тема. Во-первых, что тут делать ботам, а во-вторых, в чём вообще смысл, если я могу руками войти, а уже потом установить флажок «запомнить меня», получить куку и бот будет ходить как к себе домой. А главное вот сейчас CAPTCHA с Хабра убрали и ничего страшного не произошло, так что это точно было лишним.

          Можно CAPTCHA делать в виде текста, что, конечно, не очень устойчиво к целенаправленной атаке, но вполне может защитить от случайных ботов. В таких случаях обычно словами записывается математическое выражение, результат которого надо ввести цифрами. Типа «Введите, сколько будет восемнадцать минус девять».

          Тем не менее, есть некоторые инструменты, которые позволяют незрячим справляться с графическими CAPTCHA. Они представляют собой расширения для браузеров, которые хватают картинку теста и отправляют её на сервер. Там осуществляется либо агрессивное OCR, либо работа какого-нибудь китайца или индуса. Потом возвращается распознанный ответ и вводится в форму. Есть как платные, так и бесплатные решения.

          Здесь тоже есть потенциальные проблемы, связанные с тем, что графический CAPTCHA может включать в себя специфические символы. Например, какое-то время назад (году в 2012-2013) Яндекс в своём CAPTCHA для русских стал показывать кириллицу, после чего все сервисы распознавания отвалились, так как не могли это распознать ввиду отсутствия поддержки кириллицы. Хитрые ходили на yandex.com и регистрировались из англоязычного интерфейса, ну а потом Яндекс всё-таки запилил звуковой вариант проверки.

          К сожалению, Яндекс до сих пор не отдаёт свою реализацию CAPTCHA, чтобы ею можно было воспользоваться в сторонних проектах. Так что русскоязычный вариант звуковой проверки придётся пилить самому.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.