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

[Lex]

Михаил, здравствуйте!

По сути то, что вы предлагаете - это написание чтеца экрана на 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