[Homeros] О концепции accessibility в MacOS

Пн Ноя 10 17:25:33 MSK 2014

Никита, спасибо за информацию об OS X!
если там без "мышки" никуда, то мне такая ось не нужна и даром.
пущай зрячие пользуются, у кого много денег.

09.11.14, Lex<lex на progger.ru> написал(а):
> Михаил, здравствуйте!
>
> По сути то, что вы предлагаете - это написание чтеца экрана на java. Они
> таки извлекают информацию из структур Accessibility-иерархии и
> представляют ее пользователю в упрощенном виде. А степень некоторой
> очистки и причёски зависит от уровня поддержки конкретного приложения
> конкретным чтецом экрана. Ярчайшим примером такой поддержки является
> механизм виртуальных буферов в NVDA для веб браузеров и pdf документов.
>
> Еще, задумайтесь о том, каквам из java весело будет взаимодействовать с
> платформозависимыми нативными accessibility интерфейсами.
>
> Да, инсталлятор OS X озвучивается.
>
>
> 07.11.2014 18:01, Michael Pozhidaev пишет:
>> Никита, здравствуйте!
>>
>> Искренний респект за такое подробное описание! Я всё внимательно
>> прочитал. Если бы мы с Вами сидели за чашкой кофе, то с удовольствием
>> развил бы собственные философские продолжения этой темы, но сейчас мне
>> хотелось бы услышать Ваше мнение по таким двум вопросам:
>>
>> 1. Здесь витает тема доступа к оконному интерфейсу из неоконной
>> среды. Очень экспериментальная затея. Во всех ОС (точно в Linux и MacOS,
>> в Windows очень вероятно) accessibility-системы строят структуры
>> интерфейса приложений, откуда экранные чтецы забирают эту информацию. Я
>> хорошо знаю, как это делает AT-SPI в Linux, подозреваю, что в MacOS и
>> Windows это очень похоже. Если пока вынести за скобки неполную поддержку
>> и прочие практические недостатки, логически сама по себе напрашивается
>> идея эту информацию оттуда забрать и вынести в Luwrain, где пользователю
>> показать не в таком виде, как он её воспринимает, работая с приложением
>> напрямую, а после некоторой очистки и причёски.  Что там делать с
>> имитацией перетягивания мышью - непонятно, но на правах идеи это вполне
>> заслуживает на подумать. Лично мне эта идея нравится применительно для
>> обзора веб-страниц, чтобы осматривать их не в понимании Firefox, а
>> в некотором упрощенном виде. Конечно, будет издержка, что само
>> приложение должно болтаться на заднем плане.
>>
>> 2. Могут ли незрячие пользователи MacOS выполнять установку системы
>> самостоятельно?
>>
>> Спасибо! :))
>>
>> "Nikita" writes:
>>
>>> Здравствуйте, Michael Pozhidaev.
>>>
>>>> Оооп, минуточку. В этом месте  можно, пожалуйста, развернуть Вашу мысль?
>>> Я был бы с такими просьбами по-осторожнее, потому что я могу завестись
>>> и безумно растечься мыслью по древу, ударившись в сравнение разных
>>> подходов и средств доступности на очень многих платформах. :-)
>>>
>>>> Я крайне жаден до концептуальных проблем чего бы там ни было, так что за
>>>> ценную аналитическую информацию вынесу респект!
>>> Я всё-таки постараюсь тезисно, чтобы кратко донести основную мысль.
>>> У accessibility в OS X есть масса проблем, часть из которых
>>> хронические не исправляющиеся ошибки, например, скачки высоты и
>>> громкости синтезатора в зависимости от объектов GUI, часть - просто
>>> недоработки, потому что разработчикам не хватает знаний в каких-то
>>> областях, например, в Брайле, а часть как раз является
>>> фундаментальными концептуальными проблемами.
>>> К последней группе я бы отнёс две основные вещи:
>>> Во-первых, сама Mac OS исторически была ориентирована на мышку. Если
>>> верить официальной биографии, то Джобс даже испытывал реальную
>>> неприязнь к курсорным клавишам на клавиатуре.
>>> Полноценная навигация с клавиатуры в системе невозможна. Даже самые
>>> банальные вещи без мышки там не сделать.
>>> В итоге, VoiceOver вынужден обходить это двумя путями: либо повальной
>>> навигацией по экранным контролам, либо прямой эмуляцией мышиных
>>> действий. Для VoiceOver является вполне рядовой ситуацией фиксировать
>>> точку, затем эмулировать на ней зажимание мышки, потом фиксировать
>>> вторую точку, эмулировать перетаскивание мышки на неё и
>>> отпускание. Это реально те действия, которые должен достаточно часто
>>> выполнять слепой пользователь OS X.
>>> В Windows и обычно в оконных интерфейсах для Linux клавиатурное
>>> управление дублирует практически всё, а в OS X даже между кнопками
>>> диалога не всегда возможно переместиться с клавиатуры.
>>> На мой взгляд, путь обеспечение невизуальной доступности через прямую
>>> эмуляцию мышки - это, пожалуй, один из самых неудачных путей, по
>>> которым только можно пойти, если вообще не самый неудачный.
>>> Во-вторых, VoiceOver использует последовательную линейную навигацию по
>>> экранным контролам. То есть мы открываем окно и дальше начинаем
>>> последовательно перемещаться по всем его дочерним объектам.
>>> Одна из самых слабых мест этой идеи заключается в том, что в этой
>>> цепочке объектов очень много хлама.
>>> Например, в углу окна, как правило, есть три маленькие цветные
>>> кнопочки для закрытия, сворачивания и восстановления
>>> размера. Очевидно, что они нужны далеко не всегда, а скорей даже
>>> иногда.
>>> С точки зрения визуальной работы они и не бросаются в глаза, потому
>>> что находятся в углу. Но вот для пользователя VoiceOver они-то
>>> попадают в цепочку навигации.
>>> В итоге, цепочка последовательного перемещения по экранным элементам
>>> для слепого пользователя всегда начинается с этих самых кнопок. Потом
>>> туда ещё попадает иконка программы, а уже только после всего этого
>>> начинается актуальное содержимое окна.
>>> В визуальном интерфейсе можно сделать элементы более акцентированными
>>> и менее акцентированными, за счёт размеров, цвета, расположения. А вот
>>> в невизуальном они получаются все одинаковой степени акцентированости.
>>> При полном переборе всех объектов окна с VoiceOver для нас одинаковую
>>> значимость получают и второстепенные и первостепенные элементы, что,
>>> на мой взгляд, является возможно даже самой страшной ошибкой
>>> разработчиков Apple.
>>> Да, с одной стороны, мы вроде как достаточно неплохо защищены от того,
>>> что есть риск пропустить какой-то элемент окна, но за это мы
>>> расплачиваемся катастрофической потерей производительности из-за
>>> необходимости продираться через все второстепенные элементы, а также
>>> просто статические объекты типа меток label или иконок. А главное
>>> каждый из таких элементов представляет собой как бы отдельный этап
>>> навигации, то есть если сначала идёт иконка, потом label, а только
>>> потом кнопка "ОК", то до этой самой кнопки нам надо добираться в три
>>> шага, дабы прошагать два предыдущих статических объекта.
>>> В общем вот вы всё ругаетесь на Windows, говоря, что там ваша работа
>>> существенно замедляется. Если бы вы попробовали OS X, то, боюсь, тогда
>>> вообще бы застрелились. :-)
>>> Там для увеличения производительности можно обвешаться скриптами и
>>> просто их дёргать при необходимости, но это очень трудоёмкое решение и
>>> не очень масштабируемое на высоковариативные задачи.
>>> Именно поэтому лично в моих глазах Luwrain на OS X намного более
>>> востребован, чем на Windows, потому что он сможет предложить реально
>>> более производительную альтернативу даже базовым задачам, типа чтения
>>> почты, тогда как на Windows в таких вещах преимущества Luwrain для
>>> меня как раз не очевидны, потому что там не всё так запущено, как на
>>> OS X.
>>> Есть и много других проблем реализации accessibility OS X, но это уже
>>> отдельный и очень долгий разговор. Самые фундаментальные проблемы, на
>>> мой взгляд, именно вот в том, что я описал.
>>> Успехов. Никита.
>>>
>>> _______________________________________________
>>> Homeros mailing list
>>> Homeros на lists.altlinux.org
>>> https://lists.altlinux.org/mailman/listinfo/homeros
>
> _______________________________________________
> Homeros mailing list
> Homeros на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/homeros
>