Помимо прочих особенностей, интерактивную литературу из всех компьютерных игр также выделяет высокая степень инклюзивности. То есть текстовые игры имеют наибольшие возможности легко и непринуждённо объединить вокруг себя одновременно как обычных игроков, так и игроков с ограниченными возможностями, потому что текстовая форма подачи является самой универсальной и доступной. К парсерным же играм, из-за простоты базовой модели их интерфейса, всё это относится в наибольшей степени.
Главным образом, речь идёт о людях с существенными нарушениями зрения, так как именно для них вопрос доступности текстовой игры во многом решается на уровне её технической реализации, то есть зависит от разработчика. Остальные категории пользователей с ограниченными возможностями, как правило, оказываются способны полностью решить все возникающие проблемы за счёт вспомогательных технологий чисто на своей стороне.
Одной из тех вещей, которые можно отнести к безусловным успехам предыдущего Парсерфеста-2018, является принципиальная доступность всех представленных на нём игр. То есть практически каждый любитель парсерных игр с ограниченными возможностями мог достаточно просто поиграть во все игры фестиваля, если имел доступ к широко распространённым операционным системам. К сожалению, это нельзя сказать ни про один другой конкурс или фестиваль русскоязычной интерактивной литературы за многие годы.
Всё это позволило расширить совокупную аудиторию фестиваля за счёт сообщества незрячих геймеров, только основное ядро которого составляет несколько сотен человек, и где есть немало настоящих любителей парсерных игр и очень опытных и сильных игроков. Кроме того, это дало возможность и дальнейшей популяризации парсерных игр в рамках различных специализированных мероприятий или просто на уровне личного общения.
Выбор платформы для написания парсерной игры зависит от множества факторов, приоритизируемых каждым автором по-своему, поэтому универсальных рекомендаций по данному вопросу дать нельзя. Однако можно рассматривать доступность как ещё один фактор, для чего разработчикам парсерных игр нужно знать текущее состояние дел.
Для тех авторов, которые заинтересованы в расширении аудитории своей парсерной игры за счёт обеспечения её большей доступности, ниже приводится сводная таблица с описанием степени доступности существующих парсерных платформ с поддержкой русского языка. Для упрощения восприятия неспециалистами информация представлена в форме обобщённых оценок, дающих примерное понимание, но не описывающих все технические нюансы.
В таблице приняты следующие обозначения:
- «Высокая» — обозначает высокую степень доступности, когда игрок может полноценно играть и практически не отвлекаться на необходимость совершения дополнительных действий.
- «Средняя» — обозначает среднюю степень доступности, когда игрок в целом всё ещё оказывается способен полноценно играть, но в ряде аспектов будет вынужден совершать дополнительные действия для получения какой-то игровой информации, предоставляющейся в недостаточно эргономичном интерфейсе. Данный уровень доступности может отпугнуть мало заинтересованного игрока.
- «Низкая» — обозначает низкую степень доступности, когда игрок либо не имеет возможности в полной мере взаимодействовать с игрой, либо же вынужден для этого совершать существенный объём дополнительных действий, превышающих по общей длительности сам игровой процесс. Данный уровень доступности может оказаться приемлемым лишь для крайне заинтересованного игрока.
- «Недоступно» — обозначает отсутствие базовой доступности, когда игрок не имеет принципиальной возможности достаточно успешно взаимодействовать с игрой.
Кроме того, для оценки важности доступности на той или иной операционной системе, рядом с её названием в скобках приводится процент использующих её людей (согласно исследованию технических предпочтений русскоговорящих незрячих пользователей, проведённому компанией Яндекс). Для системы iOS данные не приводятся ввиду отсутствия на ней технических возможностей по воспроизведению игр, актуальных для русскоязычной аудитории.
Также, для тех платформ, для которых информация о версии является значимой (т.е. нет большого разнообразия отдельно развиваемых интерпретаторов), рядом с их названием в скобках приведена версия, для которой изложенные данные являются актуальными.
| Платформа ↓ | OS → | Windows (97,3%) | Android (77,9%) | GNU/Linux (6,8%) | macOS (5,6%) | Браузер |
|---|---|---|---|---|---|
| 6 days (1.25) | Низкая | — | — | — | — |
| ADRIFT | Средняя | Средняя | Недоступно | Недоступно | Недоступно |
| Az (commit 30.11.2015) | — | — | — | — | Средняя |
| FireURQ Adventure System (FireURQ 2.2.4) | Недоступно | — | — | — | — |
| Hydra (0.5 beta) | Средняя | — | — | — | — |
| protoparser.js (6(145)) | — | — | — | — | Средняя |
| Quazatron Adventure (commit 07.04.2019) | — | — | — | — | Средняя |
| Quest (5.8) | Средняя | — | — | — | Средняя |
| RInform | Высокая | Средняя | Недоступно | Недоступно | Высокая |
| RTADS | Высокая | Высокая | Средняя | Средняя | Средняя |
| TDZ (4) | Недоступно | — | — | — | — |
| Декодер 2002 (2.00) | Средняя | — | — | — | — |
| Метапарсер 3 (1.5) | Недоступно | Недоступно | Средняя | Недоступно | Высокая |
| ТКР 2 (1.3) | Низкая | — | — | — | — |
| ТОМ 2 (2.a.5.3 alpha) | Средняя | — | — | — | Средняя |
| ЯРИЛ 2.0 (2016/5) | Средняя | — | Средняя | — | — |
Вся изложенная выше информация относится к ситуации «из коробки» и ориентирована на разработчиков игр, не обладающих достаточными знаниями для самостоятельного улучшения доступности используемой платформы, поэтому вынужденных принимать тот уровень, который есть изначально.
Автор статьи как минимум предвзят.
1. tiny instead не только для *nix
2. Десяток отобранных игр онлайн с https://rinform.org/ видите ли означает высокую доступность, а игры с функционально полностью аналогичной страницы https://metaparser.syscall.ru/ видите ли со средней и то в скобочках.
3. В игры на метапарсере можно играть через переписку с ботом вконтакте, дискорде, телеграме.
Написано, что Метапарсер 3 — недоступен через веб,
Цитирую: Недоступно» — обозначает отсутствие базовой доступности, когда игрок не имеет принципиальной возможности достаточно успешно взаимодействовать с игрой.
Сноска: Облегчённый интерпретатор МЕТАПАРСЕР-js позволяет получить минимум средний уровень доступности, но он является встраиваемым решением для разработчика игры
Сначала говорили об игроке, теперь об авторе. Верстка чем-то отличается в худшую сторону или что? (Hint: она практически такая-же как и в парчменте (только проще), у которой автор статьи написал «высокая»)
Во время переписки с Никитой я предлагал встроить МП3 в движок для незрячих. Это сделать очень просто — дать строку, получить строку. Гораздо проще, чем в PlainInstead. Я не программист windows, мне это сложно сделать. Ответа не получил. Надеялся, что js версия уж точно облегчит игру незрячим. Но вот, оказывается, как. Ну что сказать, обидно и несправедливо. Не хочется уже и делать ничего больше.
Пётр, ну надо выяснить, что не так и допилить. Возможно, какой-то мелочи не хватает.
> Пётр, ну надо выяснить, что не так и допилить. Возможно, какой-то мелочи не хватает.
Ага. Вот вам и дезинформация в действии. Плевать на факты. :( Написали бред, а ты отбивайся?
Ок, буду отбиваться. Смотрим на список.
1) protoparser.js — средняя (веб). Сделан на console.js Я осознанно ушел от этого ради той самой «доступности». У протопарсера доступность средняя. У метапарсера — нет вообще. Объективность? Нет, не слышали. Речь, конечно, не о том, чтобы понизить рейтинг протопарсера. :)
2) Сравните верстку прачмента и метапарсера-js. Найдите разницу. Она минимальна. ЕСЛИ есть какие-то проблемы — напишите. Но объективного замечания нет. Просто написано, что игры недоступны для незрячих.
3) у тадса средняя доступность по веб. Прошу мне показать русскую игру в вебе, чтоб я знал к чему нужно стремиться. Я не издеваюсь, мне правда интересно.
Ну и насчет «сервиса». Если залить файлы на статический сервер это проблема, можете писать так:
https://metaparser.syscall.ru/games/index.html?URL к своей игре
Игра — zip архив с main3.lua и dict.mrd. Можете считать это сервисом.
Подводя итог считаю, что статья содержит необъективную информацию, как минимум в том, что касается метапарсер-js.
Я всегда был ориентирован на сотрудничество, всегда был рад движению в строноу незрячей аудитории. Но в такой форме я не понимаю как его вести. Все это напоминает мне анекдот «почему без шапки».
Очень удручён и разочарован.
Никита, Пётр сделал возможным запускать игры с любого хостинга, просто по ссылке вида https://metaparser.syscall.ru/games/index.html?https://mywebsite.ru/mygame.zip
Ты можешь проверить, насколько удобно и комфортно слабовидящие могут играть в игры с https://metaparser.syscall.ru?
Подозреваю, что в твоей таблице для веб-метапарсера «Недоступно» надо сменить на «Высокий».
Запускать игры с любого хостинга можно и без этой фичи/
Есть дистрибутив метапарсер js. Который просто заливаешь рядом с игрой и все. Или 1 на все свои игры. В этом нет отличия от того же протопарсера. Но автор статьи написал, что мп3 доступен по вебу только разработчикам. И точка. О чём тут можно говорить, о чём спорить? Нет, свободен. Но я должен доказывать бредовость информации в статье, а не наоборот? :)
На этом я закругляюсь. Показывайте незрячим что хотите.
Продолжим разговор за веб-версии:
RTADS — средний? А ссылка хоть одна на ртадс-игру, играемую в браузере, будет? По факту ноль.
ТОМ2 — средний? Две игры, обе не работают в ФФ (другие браузеры не пробовал).
AZ — средний? Одна игра, работает отлично. Почему средний?
Протопарсер — средний? Ладно это не совсем парсер, но работает же хорошо.
Писал бы сразу: платформа — количество игр онлайн. Сразу бы стало все понятно.
Ринформ — 15 игр
Инстед — 6 игр на сайте и 8 в чат-боте.
AZ — 1 игра
Протопарсер — 1 (или 2?)
ТОМ2 — 2 игры (в ФФ не работают)
RTADS — 0
Кстати еще ты забыл вписать в табличку Аперо. Там люди ведь отличные парсеры пишут. Про волшебный меч например.
Никита, а вы тестировали с системами экранного доступа в браузере все движки о которых пишите? По-идее, если вывод добавляется в документ html, то система экранного доступа должна его озвучить. В этом случае у нас почти все парсерные движки, которые умеют в браузер должны иметь высокий рейтинг.
Но, это в теории. Мне самому было это интересно, и я как-то устанавливал себе NVDA. Так вот не все в пп озвучивалось. Тут, имхо, надо указывать конкретные системы синтеза речи, или звать специалиста, например Антона Ласточкина :)
>> Есть дистрибутив метапарсер js. Который просто заливаешь рядом с игрой и все. Или 1 на все свои игры. В этом нет отличия от того же протопарсера.
Не совсем так. Игры для пп пишутся на js, поэтому их можно запускать локально. А для мп-js все же нужен сайт.
> А для мп-js все же нужен сайт.
https://forum.ifiction.ru/viewtopic.php?pid=38869#p38869
Быстро ты забыл. ;)
Не нужен сайт. Запускать можно из браузера с диска локально. Разницы с js в этом смысле нет. Только писать на lua.
Хотя, если совсем точно говорить, локально работает в Firefox. А в хроме блочится реквест на запуск js. Я еще посмотрю в этом направлении.
На Андроиде тоже не удалось запустить локальную версию.
>> Быстро ты забыл. ;)
Нет-нет, я помню ) Ты же сам написал, что «работа на статическом сайте и запуск с диска — не одно и то же». На статическом сайте как раз все запустилось. фф сейчас самый передовой браузер, поэтому в нем могут присутствовать какие-то фичи, которых нет в остальных.
А нет, вру. Я не то запускал. Работает и в хроме, короче. Вот для теста сделал архив (немного избыточный, но неважно). http://instead.syscall.ru/downloads/london.zip
Про андроид ничего сказать не могу, но для мобильных смысла запускать из zip игру не вижу. Проще открыть прямо из сети. Связь для игры не нужна.
> Ты же сам написал, что «работа на статическом сайте и запуск с диска — не одно и то же».
По ссылке на форум есть текст того, что я сказал:
> Все наши версии работают на статическом хостинге без проблем. Все ли запускаются при этом с диска я не знаю. Ну вот метапарсер-js точно запустился.
***
Ну вот метапарсер-js точно запустился.
***
Так что на FF и Хроме работает точно.
Погонял на разных машинах. В общем, зависит от версии Хрома. Вероятно, в каких то версиях ограничение есть, в каких-то нет. Так что на новом Хроме увы — не пашет.
Если совсем надо под виндой, можно завернуть игру электроном и будет метапарсер, доступный кому угодно, на любой платформе.
Ладно. Я, возможно, погорячился в плане формы подачи своего негодования. Я по-прежнему считаю, что Никита некорректно описал ситуацию с метапарсером-js. Но это мелочи. Я делаю то, что делаю. Со своей стороны обещаю техническую поддержку для адаптации моих игр для незрячих. Если она понадобится. Собственно, создавая метапарсер-js, я держал в голове эту мысль.
Сайт https://metaparser.syscall.ru будет постепенно пополняться. Сейчас это мой основной проект в плане интереса. Если будут какие-то проблемы в плане доступности — сообщайте.
Мир, труд, жвачка.
Всем, пытающимся здесь спорить с апломбом о доступности, перед продолжением дискуссии следует прочитать следующий материал — https://habr.com/ru/post/392817/
А теперь я один раз отвечу всем и сразу по затронутым техническим аспектам.
Ир:
> 1. tiny instead не только для *nix
В варианте, работоспособном здесь и сейчас для парсерных игр только для *nix.
> 2. Десяток отобранных игр онлайн с https://rinform.org/ видите ли означает высокую доступность, а игры с функционально полностью аналогичной страницы https://metaparser.syscall.ru/ видите ли со средней и то в скобочках.
С точки зрения специфики взаимодействия с программами невизуального экранного доступа эти страницы не аналогичны.
Информация про доступность в рамках МЕТАПАРСЕР-js вынесена в примечание, потому что это вариант, выходящий за рамки стандартного цикла разработки и релиза игры на INSTEAD. Игры на МЕТАПАРСЕР-js собираются дополнительно. Например, «Испытание Марсом» — это игра, которая есть в стандартном web-варианте, но её нет (по крайней мере, не было на момент публикации) в варианте МЕТАПАРСЕР-js, как и ещё доброй половины игр на Метапарсер 3 из общего репозитория.
Примечание как раз и говорит о необходимости уделять этому внимание, потому что в контексте доступности полагаться на стандартный репозиторий с его web-интерпретатором нельзя.
> 3. В игры на метапарсере можно играть через переписку с ботом вконтакте, дискорде, телеграме.
Во-первых, соответствующих столбцов в таблице в принципе нет, так что претензия про некорректность подобной информации очевидно несостоятельна.
Во-вторых, вы в курсе доступности клиентов для названных сервисов и их web-интерфейсов? Записывать проблемы доступности инфраструктуры в проблемы доступности сервиса внутри этой инфраструктуры? Вы уверены, что вас от этого не раскалит ещё сильнее? (Вопросы, конечно, скорей риторические.)
Пётр:
> Написано, что Метапарсер 3 — недоступен через веб,
Статус «Недоступно» для браузерного варианта Метапарсера относится к стандартной опции «Играть онлайн» в репозитории. В заголовке всей этой строки, согласно установленным обозначениям, конкретизирован интерпретатор.
МЕТАПАРСЕР-js вынесен отдельно, потому что это опционный вариант, расширяющий типовой цикл разработки и релиза игры на INSTEAD. На момент написания даже не все игры на Метапарсере 3 были собраны под МЕТАПАРСЕР-js, именно поэтому и акцентировано внимание, что этим должен заниматься автор, потому что репозиторий автоматически за него это не сделает.
> Верстка чем-то отличается в худшую сторону или что? (Hint: она практически такая-же как и в парчменте (только проще), у которой автор статьи написал «высокая»)
В сноске я написал «минимум средний уровень», то есть пограничное состояние между средней и высокой. Да, там есть проблема «склейки» вышестоящего текстового контента с полем формы, что несколько снижает ux.
Пока только тестировал, причины проблемы в вёрстке не анализировал. Займусь позже. Теоретически все браузерные интерпретаторы со статусом «Средняя» можно постараться затащить на «Высокая».
Внимательнее смотрите на последний абзац в заметке. Это констатация ситуации здесь и сейчас на момент публикации, которую получит автор, выпустивший игру на платформе «как есть», не вникая и не допиливая самостоятельно. То, что несколько энтузиастов пытаются тянуть доступность платформ вверх, так что возможно уже к осени станет много где лучше, выходит за рамки статьи.
> Во время переписки с Никитой я предлагал встроить МП3 в движок для незрячих. Это сделать очень просто — дать строку, получить строку…
> Ответа не получил.
Во-первых, это не так просто, если ставить вопрос о полноценной интеграции с поддержкой звука и всем таким, а хотелось бы именно этого.
Во-вторых, если уж вы предпочитаете обсуждать переписку публично, ответ ещё тогда вам был отправлен вместе с несколькими уточняющими вопросами. С учётом того, что писем в той переписке было штук 20 и все, интересные вам и касавшиеся зависаний INSTEAD вы точно получили и на них ответили, не считаю высоковероятным, что одно единственное письмо про Метапарсер не дошло.
В-третьих, более развёрнуто я вам уже ответил на сегодняшнее личное письмо, так что не вижу смысл обсуждать это публично.
> у тадса средняя доступность по веб. Прошу мне показать русскую игру в вебе, чтоб я знал к чему нужно стремиться. Я не издеваюсь, мне правда интересно.
То есть вы уже раздобыли Windows и поставили туда NVDA и JAWS за тысячу долларов, или машину с macOS, ну или хотя бы накатили на свой Linux Orca или нашли у себя на Android-устройстве TalkBack, освоив хотя бы базовые принципы невизуальной работы в web, чтобы аргументировано вести со мной дискуссию по поводу доступности и её тестирования? Я не издеваюсь, мне правда интересно.
У TADS существует интерпретатор на JavaScript, куда может быть загружена произвольная игра.
Как интерпретатор решение сырое из-за сложности ядра движка, особенно в отставшей ветки с адаптацией под RTADS, но с точки зрения доступности, не вдаваясь в проблемы общей функциональности, которые для всех авторов итак очевидны, да, средний уровень. К осени наверное затащу на высокий.
Вот пример — http://tseykovets.ru/games/rtads/?game=example
В браузере должна быть поддержка SharedArrayBuffer. После Spectre и Meltdown SAB везде по умолчанию отключали, в Chrome уже включили, у остальных не помню.
Только не знаю, к чему вы собрались стремиться, если доступность этого решения я обозначил как более низкую, чем МЕТАПАРСЕР-JS. Лучше МЕТАПАРСЕР-js только Parchment.
fireton:
> Подозреваю, что в твоей таблице для веб-метапарсера «Недоступно» надо сменить на «Высокий».
Сайт этот администрируется Олегусом (от текстов статей, до модерации комментариев).
В таблице строка Метапарсера строго про основной интерпретатор, что помечено. До определённой степени устарело второе примечание, потом обновим с остальными данными или обобщим всю строку без конкретизации интерпретатора.
Пётр, думаю, достаточно громко донёс информацию о новой функциональности МЕТАПАРСЕР-js, чтобы здесь не осталось никого, кто был бы не в курсе.
До «Высокая» там наверное надо будет кое-что подправить, я пока не смотрел причины проблем в вёрстке.
Пётр:
> Есть дистрибутив метапарсер js. Который просто заливаешь рядом с игрой и все. Или 1 на все свои игры. В этом нет отличия от того же протопарсера.
В рамках принятой логики изложения отличие в том, что для protoparser.js это основной и единственный вариант, тогда как для Метапарсера основной вариант это набор нативных интерпретаторов и соответствующий INSTEAD-em в репозитории, к которому и относится строка таблицы, что указано в скобках в её заголовке.
Если честно, мне вообще непонятна причина вашего недовольства. Вы хотите поспорить, что метапарсерные игры в основном INSTEAD 3.3.0 недоступны, как написано в таблице, или что игру на МЕТАПАРСЕР-js надо собирать руками за счёт знаний, выходящих за рамки компетенций знаний обычного игрока, как указано в примечании?
Да, сейчас вы сделали возможность использовать МЕТАПАРСЕР-js как общий интерпретатор, так что людям будет проще. Это хорошо, но откуда вся предшествующая истерика, выданная в момент, когда этого ещё не было и абсолютно все данные были корректны?
В таблице если и есть сомнительный момент, так это статус «Недоступно» у RInform для GNU/Linux и macOS, потому что я там до конца не уверен, что где-то не завалялся какой-то малоизвестный доступный интерпретатор. Впрочем, если никто его не знает, то и игрокам посоветовать не может, так что по факту это пока верно.
> На этом я закругляюсь. Показывайте незрячим что хотите.
Незрячие прямо сейчас читают этот пост и комментарии под ним, наблюдая, как отдельные люди, типа Ир, пытаются криками изменить реальность посредством утверждений, что якобы им всё доступно и одинаковым образом.
Я вам уже говорил, что на IFWiki вижу около десятка авторов, про которых точно знаю, что они незрячие, а игроки, которых в десятки раз больше авторов, регулярно ходят по ресурсам РИЛ. Этот фарс «почему средняя» и прочим устраивается прямо на глазах незрячих, как бы двусмысленно это сейчас не прозвучало.
Ир:
> RTADS — средний? А ссылка хоть одна на ртадс-игру, играемую в браузере, будет? По факту ноль.
Для ряда платформ есть целый зоопарк разных интерпретаторов, у таких платформ в заголовке строки не указывается конкретная версия, в том числе и RTADS. Для TADS есть JavaScript-интерпретатор, в который можно загрузить произвольный файл игры. В таблице речь о нём. Подразумевается, что если автор пишет на (R)TADS то в курсе специфики эко-системы. Задачи же доказывать что-то праздношатающимся комментаторам у статьи нет.
> ТОМ2 — средний? Две игры, обе не работают в ФФ (другие браузеры не пробовал).
У ТОМ 2 сейчас очередной этап перерождения, в рамках которого Александр всё поломал и строит заново. В таблице уточнён номер версии, к которой относится информация.
Для ТОМ 2 я собственноручно затаскивал доступность на высокий уровень, но в последних публичных релизах там произошёл откат.
> AZ — средний? Одна игра, работает отлично. Почему средний?
Потому что вы не понимаете, о чём спорите.
При игре в Az с программой экранного доступа, пользователю необходимо выходить из режима редактирования формы, идти построчно вверх, искать место, от которого дописалась новая информация, читать, а потом возвращаться в поле формы и вводить следующую команду.
Всё это серией нажатий на клавиатуре после каждого хода.
> Протопарсер — средний? Ладно это не совсем парсер, но работает же хорошо.
Это вполне парсер. Проблема та же, что и у Az.
> Писал бы сразу: платформа — количество игр онлайн. Сразу бы стало все понятно.
Я написал то, что написал, и, в отличии от вас, разбираюсь в вопросе, по которому высказываюсь.
Это не анализ популярности платформ (в списке есть платформы в статусе беты с единственной игрой от автора платформы в таком же статусе). Это анализ доступности, полученный реальным ручным тестированием на реальном программном обеспечении человеком, который занимается доступностью дольше, чем существует половина упомянутых в таблице платформ, в том числе весь INSTEAD.
Именно поэтому спорить с вами я больше не намерен. Вы просто как дикарь, требующий доказательств, что земля круглая, но не имеющий базовых представлений о геометрии, чтобы понять приводимые обоснования.
johnbrown:
> Никита, а вы тестировали с системами экранного доступа в браузере все движки о которых пишите?
Да, конечно. Подозреваю, я единственный участник дискуссии, который это сделал.
> Так вот не все в пп озвучивалось.
Я сейчас дописываю игру на protoparser.js. В процессе смотрел потроха и в принципе знаю, как вытащить средний уровень на высокий.
Когда закончу, отпишусь и покажу, что надо сделать. Но это именно для 6(145) на базе terminal.js. Если брать новый интерфейс, прототип которого показывали на форуме, то надо будет заново исследовать и адаптировать решение.
fireton:
> Если совсем надо под виндой, можно завернуть игру электроном и будет метапарсер, доступный кому угодно, на любой платформе.
На GNU/Linux Chromium не является доступным, а, как следствие, и все приложения на Electron. Работа по обеспечению его доступности там только ведётся.
На Windows есть трудности с доступностью Electron для не самых новых версий отдельных программ экранного доступа.
Ну это так, мелкая ремарка для иллюстрации того, что не всё так просто, как кому-то кажется.
На этом встреча с читателями этой статьи закончилась. В следующий раз, делайте домашнее задание и изучайте тему, по которой хотите спорить. Я не считаю себя непогрешимым, и могу ошибаться, но ни один человек здесь даже не смог продемонстрировать базовый набор знаний, чтобы в принципе разговаривать со мной на одном языке по поднятой теме. Оспаривались же вещи, очевидные любому человеку минимально в теме.
То, что будет в моих силах починить в доступности платформ текстовых игр, я рано или поздно сделаю, в том числе форками независимо от их разработчиков, если они будут сопротивляться. Если для доступности игр Парсерфеста надо будет вручную пересобирать какие-то игры или интерпретаторы, я это тоже постараюсь сделать.
То, в чём меня обвинил Пётр и самостоятельно показывал мне сегодня соответствующие логи из какого-то чата, к реальности не имеет никакого отношения. Для вас доступность оказалась поводом очередного бессодержательного холевара про любимые платформы, а я, действительно, заинтересован в этом и не воспринимаю доступность просто как повод помериться с кем-то чем-нибудь ещё, и по мере сил стараюсь улучшать общую ситуацию.
По сути, половина комментаторов серьёзную тему за полдня превратила в цирк. Можете продолжать, но уже без меня.
Внимательно прочитал всё выше.
По-моему, проблема в том, чтобы действительно вывести анализ на уровень эксперта. Потому что статья либо провалила проверку фактов, либо слишком непонятно сформулирована. А может, и то, и другое. В сочетании с намёком на противостояние платформ получили то, что получили.
Конкретно нет ещё хотя бы ссылок на проблемы совместимости программ под Windows, Linux, Mac и веб (для плохо разбирающихся), и пояснений по методике (для хорошо разбирающихся). Например, я до сих пор не понимаю смысл примечания 2 при том, что новые игры в веб-интерпретатор RTADS может загружать только лично Никита, а веб-интерфейс TOM 2 требует либо того, чтобы игрок скачал сам ТОМ (т.е. без доступности онлайн), либо того, чтобы автор поставил сервер Windows с запущенным TOM (что намного сложнее и дороже хостинга JS-решений).
Никита, правильно ли я понимаю, что для бОльшей доступности для слабовидящих игра в идеале должна показывать на экране лишь последнюю выведенную информацию? Просто это идёт вразрез с моим видением «идеального» интерфейса, где у игрока есть возможность видеть хотя бы последние команды и их результаты, чтобы обдумывать свои ходы.
Если бы я писал сейчас платформу, и хотел облегчить доступность игр на ней для слабовидящих, то мне было бы важно знать эти нюансы их взаимодействия с интерфейсом.
Поэтому этой статье не хватает приквела, где были бы описаны средства работы слабовидящих или незрячих людей с различными программными решениями, в том числе что для них является плюсами, а что — неразрешимыми проблемами.
Тогда и сравнение платформ будет куда понятнее.
Olegus:
> правильно ли я понимаю, что для бОльшей доступности для слабовидящих игра в идеале должна показывать на экране лишь последнюю выведенную информацию?
Нет, это можно использовать как один из возможных вариантов, предоставляя вывод полной истории и перемещение по ходам отдельными опциями, например, так сделано в интерпретаторах TadsWrapper или Androtads, но это совсем необязательно.
Для хорошей доступности важно обеспечить три основные компоненты:
1. Принципиальную доступность элементов интерфейса, чтобы текст с экрана можно было бы считать программными средствами и осуществить ввод стандартным образом.
2. Возможность детального чтения текста, чтобы можно было перечитать непонятное место по словам или символам.
3. Минимальное количество действий для получения информации, чтобы пользователю не приходилось постоянно вручную перемещать курсор к новому тексту для его чтения, а потом также возвращаться к полю ввода.
В рамках вышеприведённой таблицы частичное соответствие первой или первой и второй компоненте — это низкий уровень, полное соответствие первой и второй — средний, а за счёт добавления соответствия третей происходит выход на высокий уровень. Примерно так, хотя есть исключения, когда имеется только соответствие первой и третей. Это тоже даёт средний уровень.
Первая компонента обеспечивается использованием технологий построения интерфейса, поддерживающих accessibility API, через которые вспомогательные технологии получают информацию о содержимом экрана.
Для Windows это такие accessibility API как Microsoft Active Accessibility (MSAA), User Interface Automation (UIA), IAccessible2, для macOS — NSAccessibility, для *nix/X11 — Assistive Technology Service Provider Interface (AT-SPI), для iOS — UIAccessibility, для Android -просто accessibility API (вроде нет имени собственного), у кроссплатформенных решений есть свои API, например, для интерфейсов Java интерфейс Java Access Bridge (JAB), а Qt имеет специальный слой абстракции Assistive Tools (AT), который потом пробрасывается в нативный accessibility API каждой платформы.
Целый ряд технологий и фреймворков GUI уже имеет имплементацию accessibility API, так что вручную писать это имеет смысл только в случае использования каких-то кастомных элементов или нестандартного использования существующих, ну или если технология GUI в принципе не имеет поддержки accessibility API, но для целого интерфейсного фреймворка вряд ли такое потянет один человек в режиме хобби, так что обычно вопрос решается просто выбором технологии с уже имеющейся поддержкой accessibility API.
В web все стандартные элементы уже имеют способность отдавать необходимую информацию о себе браузеру, который её потом перенаправляет вспомогательным технологиям. Правда в web чаще всего встречается проблема использования стандартных элементов не по назначению, типа реализации кнопки через div с onclick, и вот здесь начинаются проблемы доступности, которые можно чинить средствами технологии WAI-ARIA, предоставляющей возможность вручную описать всю семантику (роль элемента, его свойства и состояния).
По большому счёту, если опираться на стандартную для системы технологию GUI, типа MFC или Windows Forms под Windows, и использовать все элементы так, как было задумано, то, за исключением каких-то сложных случаев, всё будет получаться доступным автоматически, так что все эти вышеприведённые названия даже знать необязательно. В web, если не изобретать велосипеды, так и вообще проблемы минимальны.
Есть правда ещё подход, когда интерфейс не поддерживает accessibility API (слишком сложно внедрять или такая специфическая задумка), так что доступность обеспечивается самоозвучиванием, то есть встраивается поддержка синтеза речи (реже тактильных дисплеев), через который приложение самостоятельно выдаёт реакции на действия пользователя, в том числе на перемещение по элементам управления. В мире IF так реализована доступность платформы Ren’Py. В общем случае по ряду причин это плохая практика, так что в ситуации наличия выбора и отсутствия специфических потребностей, так лучше не делать.
Вторая компонента обычно получается автоматически, если платформа имеет стандартный вывод текста на экран. Пользователь при помощи специальных функций программы экранного доступа сможет сфокусироваться на тексте и прочитать его более детально, например, узнав точное написание сложного имени персонажа, которое трудно воспринимается на слух из речи синтезатора.
Примером исключения может служить интерпретатор Fabularium для Android. Он как бы доступен, но текстовое описание там выводится только полной фразой через синтезатор речи, то есть сфокусировать его средствами программы экранного доступа на экране нельзя.
В итоге, незрячий пользователь в Fabularium не сможет по буквам прочитать плохо понятное слово. На самом деле сможет, но это целый квест, когда надо перейти в меню программы экранного доступа, специальной опцией скопировать в буфер последнюю произнесённую фразу, перейти в какой-нибудь текстовый редактор, вставить туда этот текст и читать его уже там. Такие вещи не позволяют в вышеприведённой классификации получить высокий уровень доступности, потому что это очень неудобно, да и не каждый пользователь догадается.
Для повышения эргономики интерфейса можно специальными приёмами дополнительно упрощать доступ к детальному чтению текстового вывода. Например, в интерпретаторе TadsWrapper весь текстовый вывод пишется в поле edit read only, куда можно быстро перейти по Tab или Shift+Tab, а там стандартными командами навигации по редактору прочитать текст с любой детализацией. Это наиболее быстрый и удобный для пользователя способ. В Windows Glulxe и Windows Frotz есть команда CTRL+L, которая в отдельном окне выводит транскрипт в таком же edit read only.
В других интерпретаторах придётся совершать более сложные манипуляции, чтобы детально прочитать текст.
В web, если текстовый контент выводится без извращений, задача решается автоматически, то есть доступное гипертекстовое содержимое без проблем читается с нужной детализацией.
Третья компонента частично уже освещена выше про удобные способы детализованного чтения, но главный аспект здесь — это быстрое получение реакции на каждый ход.
Незрячий воспринимает экран специальным курсором программы экранного доступа, то есть вместо разглядывания содержимого он перемещает по нему курсор, получая ту информацию, которая в него попадает.
В стандартном варианте курсор стоит на поле ввода команды, команда вводится, после чего надо переводить курсор на поле с текстовым описанием, чтобы прочитать новую информацию, а потом возвращаться и всё повторять. Такая ситуация является основной причиной невозможности получить высокую доступность в вышеприведённой таблице.
Здесь важно реализовать функциональность разового прочитывания нового текста сразу после ввода команды. Тогда пользователь сможет максимально удобно играть, вводя команды, сразу получая ответ платформы и вводя ответ, а отвлекаться на ручное фокусирование текста только в особых случаях, когда надо что-то перечитать.
Системные accessibility API обычно имеют специальные методы отправки оповещений, которые должны прочитываться вспомогательными технологиями. Также у самих вспомогательных технологий часто есть собственный API, позволяющий инициировать произнесение какой-то информации. Приложениям следует использовать эти возможности, чтобы быстро доносить до пользователя новую информацию.
В интерпретаторе TadsWrapper ещё используется приём, позволяющий повысить удобство не просто для незрячих, а слепоглухих (или незрячих, работающих без синтеза речи) за счёт переброски системного фокуса на поле вывода текста, чтобы было проще работать с тактильным дисплеем.
Для web есть специальный набор свойств WAI-ARIA, называющийся live regions. Области страницы, размечаемые как live regions, будут как раз прочитываться автоматически при их изменении без необходимости специально их фокусировать. То есть браузерные парсеры должны иметь область транскрипта, размеченную как live regions.
Основная причина среднего уровня доступности в таблице у браузерных парсеров — это как раз отсутствие разметки live regions. Она есть только у Parchment, ТОМ 2 и МЕТАПАРСЕР-JS, но у Parchment для GLULX она хорошо отлажена, у Parchment для Z-машины и МЕТАПАРСЕР-js не очень хорошо, а у ТОМ 2 ,немного поломалась в последних релизах. Именно поэтому из всех браузерных платформ RInform и МЕТАПАРСЕР-js получили две самые высокие оценки: «высокая» и «минимум средняя», тогда как остальные преимущественно просто «средняя».
Впрочем, мы вчера с Петром пошумели, а сегодня в МЕТАПАРСЕР-js уже всё починили.
Я ещё помню, что отвечаю Olegus’у, так что уточню, что в Az проблема только с третьим пунктом, а со всем остальным проблем нет, в том числе с полным транскриптов на экране, который сам по себе никакой проблемой не является. То есть там всего лишь надо аккуратно наложить и отладить с разными экранными чтецами и браузерами разметку live regions.
Прошу прощения, искать и вставлять ссылки для всего этого было лень, так что ищите названия технологий через Google, там всё сразу находится.
> Поэтому этой статье не хватает приквела, где были бы описаны средства работы слабовидящих или незрячих людей с различными программными решениями, в том числе что для них является плюсами, а что — неразрешимыми проблемами.
Ну это только если воспринимать эту статью как материал для разработчиков платформ, которым нужно понять принципы взаимодействия, чтобы под них подстраиваться.
Однако это была заметка для авторов игр, которые приходят и выбирают доступные варианты «под ключ». Причём, обычно из нескольких уже известных им решений, и тут им ещё один фактор для выбора.
Я сделал фокусное исследование, а не писал методичку. Подобие того, что ты хочешь, есть вот здесь — https://ifhub.club/2018/09/22/konechnye-avtomaty-v-menyushnom-dvizhke-povyshaem-dostupnost-doistoricheskogo-priklyucheniya-na-ink-chast-4.html
Oreolek:
> статья либо провалила проверку фактов, либо слишком непонятно сформулирована. А может, и то, и другое.
Статья не проверяет факты, а их констатирует, формулируя первоначальный вывод. Проверкой выводов можете заняться вы, если считаете результаты сфабрикованными. Это азы: проверка — задача вторичных верифицирующих исследований.
Однако проверка заключается именно в приведении результатов альтернативного исследования, а не в высказывании тонких намёков на толстые обстоятельства.
> В сочетании с намёком на противостояние платформ получили то, что получили.
Я не могу нести ответственности за намёки других людей. Со своей стороны я максимально явно написал, что универсальных рекомендаций по выбору платформ не бывает, а это лишь один из факторов, который можно принимать во внимание, а можно и не принимать. Как можно было ещё более конкретно дистанцироваться от платформенных войн я не знаю. Боюсь, проблема уже в головах читателей.
Вчерашние события, как оказалось, вообще стали следствием того, что некоторые люди просто неправильно интерпретировали словосочетание «минимум средняя», решив, что это означает «хуже, чем средняя», а не «в худшем случае средняя».
> новые игры в веб-интерпретатор RTADS может загружать только лично Никита
В этот интерпретатор можно загрузить любой файл .gam, правда пока без поддержки загрузки по URL. — http://tseykovets.ru/games/rtads/
веб-интерфейс TOM 2 требует либо того, чтобы игрок скачал сам ТОМ (т.е. без доступности онлайн), либо того, чтобы автор поставил сервер Windows с запущенным TOM
У ТОМ 2 единственный интерфейс, который есть, — это web-интерфейс, даже когда он запускается как Windows-приложение. Соответственно и браузер может быть локальным интерфейсом воспроизведения игры, являясь одним из трёх режимов запуска на вкладке «Настройки». По сути, на локальном клиенте и на сервере игра абсолютно аналогична.
Что и насколько сложнее автору в контексте общей разработки никто здесь не рассматривал. Это не имеет отношения к предмету статьи. Оценена одна единственная характеристика.
Большая ошибка трактовать этот материал, как самодостаточную рекомендательную статью по выбору платформы для парсерных игр, на что вы пытаетесь постоянно перевести разговор. Например, Hydra под Windows сейчас бесконечно доступнее INSTEAD под Windows, но очевидно, что в целом как парсерная платформа она и рядом не валялась.
Это всё равно что статистику по весу людей в определённой стране трактовать как рекомендацию по выбору жены.
Я не могу проверить выводы, потому что после упрощения они потеряли объективность. Это просто личное мнение, которому не требуются доказательства.
Тема интересная и видно, что подана для всех, но не в ущерб же последовательности. То есть, чтобы шла проверка одной характеристики, а не всех мелочей вплоть до совместимости игр и сложности запуска. Конкретно заливке игр на веб-RTADS мешает не только SharedArrayBuffer, но ещё и защита CORS, доступность игр на метапарсер-js и сложность¹ компиляции instead-tiny слабо относятся к предмету исследования, а про интерпретатор Lectrote, похоже, просто забыли. Грехи у каждого и то, что orca настраивается сложнее JAWS — это уже материал для более детального разбора.
¹: Во всех *nix и Linux, кроме Debian и Ubuntu, сам инстед ставится через компиляцию.
http://dreamcyclestudios.com/iftts/ inform tts. с исходниками.
bergano:
> http://dreamcyclestudios.com/iftts/ inform tts. с исходниками.
Я не вижу особого смысла в этом проекте, потому что в Windows Frotz уже есть встроенная поддержка зачитывания вслух нового текста через SAPI5: меню View, пункт Options, вкладка Speech; там настроить Voice и Speed, ну и отметить флажок Speak text as it is printed. Элементы же GUI в Windows Frotz итак доступны для универсальных вспомогательных технологий, и лучше них взаимодействие не реализовать.
Кроме того, как уже писал выше, в общем случае доступность через самоозвучивание интерфейса — это плохая практика. Особенно с учётом того, что редко когда там даже реализуются все необходимые дополнительные возможности для компенсации недостатков невизуального восприятия текста (быстрое прерывание речи, перечитывание, фонетическое чтение символов и пр.), которые для программ экранного доступа являются стандартной функциональностью.
Для пользователей NVDA так и вообще оптимальным вариантом повышения удобства Windows Frotz является дополнение IF Interpreters, которое реализует автоматическое зачитывание нового текста средствами программы экранного доступа.
согласен, просто нового WinFrotz не видел. а старый WinFrotz просто -2002. и про стандартную озвучку согласен.