[Homeros] О концепции accessibility в MacOS (was: Q: Терминал в MacOS)

Пт Ноя 7 20:01:53 MSK 2014

Никита, здравствуйте!

Искренний респект за такое подробное описание! Я всё внимательно
прочитал. Если бы мы с Вами сидели за чашкой кофе, то с удовольствием
развил бы собственные философские продолжения этой темы, но сейчас мне
хотелось бы услышать Ваше мнение по таким двум вопросам:

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

-- 
Michael Pozhidaev. Tomsk, Russia.
Russian info page: http://www.marigostra.ru/
English info page: http://www.marigostra.com/