Забудьте про div, семантика спасёт интернет

> Давайте я начну сразу с конца, чтоб вам было лучше слышно на вашем high horse в красивой белой броне.

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

> 4. Всегда будет кто-то, кто не может пользоваться каким-то устройством или услугой. Будут люди без рук и без ног, будут люди с умственными расстройствами, будут люди у которых просто нет денег на смартфон (шок, я знаю), будут дислексики, будут люди, которые не умеют читать (или читать на вашем языке).

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

Однако вы занимаетесь подменой понятий, когда вопрос семантичной вёрстки ставите в один ряд с этими вещами в контексте трудозатрат.
Разные приёмы повышения доступности имеют разную степень сложности реализации. Делать заголовки через h1-h6 — это совсем не так сложно, как делать перевод сайта на другой язык. Ряд перечисленных проблем и вовсе решается на стороне пользователя, так что от вас усилий не требует.
Вы же не считаете, что наложить вики-разметку на текст статьи в Википедии — это также сложно, как переписать эту статью для другого языкового раздела Википедии?

Именно про простоту использования семантической вёрстки и был вопрос 1, который вы проигнорировали, а вопрос 4 был про эмпатию, когда любой нормальный человек согласен делать малые или вовсе ничтожные усилия ради решения больших проблем других людей, но вы этот вопрос предпочли заболтать демагогическими рассуждениями.

> До куда ВЫ готовы пойти, чтоб подстроиться под каждую новую потребность?

До туда, до куда мне хватит ресурсов разного рода в каждом конкретном случае. Да и всё совсем не так прямолинейно, например, я не знаю китайского, но у меня есть разработки с китайской локализацией, потому что я просто предусмотрел локализуемость, а тот, кто мог перевести, пришёл и перевёл. От меня только требовалась минимальная эмпатия, чтобы задуматься о людях, общающихся на других языках, ну и усилие на подключение gettext в одну строку кода.
Ну а ресурсы для вёрстки заголовков через h1-h6 вместо div есть, на мой взгляд, у каждого разработчика. Особенно если продукт разрабатывается с нуля без тяжёлой наследственности. Здесь и сейчас мы пока говорим только про семантичную вёрстку.

Если кто-то считает, что верстать из одних div и span со стилями без семантических ролей и соответствующих тегов существенно проще, чем верстать хотя бы чуть более семантично, то я хотел бы услышать аргументы.

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

> Потребности людей всегда будут безграничны, сколько бы вы ни старались, каждый раз найдется кто-то еще, кто не может пользоваться вашим сервисом.

Accessibility — это не то, что нужно сегодня сделать на 100 процентов. Такое, действительно, практически невозможно, хотя к этому стоит асимптотически стремиться. Accessibility — это то, что сегодня должно быть хотя бы чуть-чуть лучше, чем вчера. Перестать использовать сплошные div'ы без ролей, а начать использовать специализированные теги — это подходящий маленький шаг вперёд, который верстальщику практически ничего не стоит.

> раз вы не читаете что пишут, что я за семантику, мне просто хотелось узнать ее корни. Которые, очевидно, вы и сами не знаете.

Если бы я хотел узнать корни семантики, то в текущую дискуссию вошёл примерно бы так:

«Скажите, а откуда вообще взялась семантика в гипертексте? Как мне кажется, контекст доступности появился позже её возникновения.»

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

Базовая семантика в HTML в виде заголовков, списков, таблиц и прочего изначально была чем-то вроде предопределённых стилевых классов. Подразумевалось, что автор просто ставит тег заголовка, а он уже визуально отображается особым образом.
Постепенно аппетиты росли, так что появились каскадные таблицы стилей (CSS).
Понимание ценности семантики для доступности пришло позже, потому что сами технологии обработки веб-страниц при помощи скринридеров появились только через несколько лет, после появления HTML.
В современном смысле, семантичность в любом документе нужна для облегчения его парсинга и переноса в другие форматы. Ну а скринридер — это просто частный случай парсера. Семантика существует не только в HTML, но и в PDF (PDF/UA), и в RTF, и много где ещё.

1. Откройте хорошо размеченную статью Википедии.
2. Выделите весь текст и скопируйте его в буфер обмена.
3. Откройте Word и вставьте туда текст из буфера.
4. Откройте Блокнот и тоже вставьте туда текст из буфера.
5. Выделите текст в Блокноте и скопируйте его в буфер обмена.
6. Вернитесь в Word, создайте ещё один документ и вставьте в него текст из буфера.
7. Попробуйте построить оглавление в первом и втором документе Word.

В первом документе HTML-заголовки стали заголовками Word и, сохранив свой семантический смысл, так что мы можем с ними взаимодействовать. Во втором же документе, куда мы копировали plain text, мы потеряли всю семантику (заголовки, ссылки, таблицы и пр.).

Когда вы таблицу верстаете HTML-тегами, её можно прямо со страницы скопировать в Excel и сразу начать работать с ней как с табличной структурой данных. Если же вы сверстаете таблицу на div'ах, то потенциальному аналитику данных придётся сначала пройти ад чистки данных и корректного распределения их по строкам и столбцам.

Если вы будете размечать иностранные слова в русском тексте через атрибут lang, то, когда какой-нибудь Google проиндексирует этот текст и будет читать его через Google Ассистент, иностранное слово, например, греческий корень в энциклопедической статье про термин, будет прочитано греческим синтезатором речи.

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

Тут в соседних ветках комментариев спорят о реальной значимости разных тегов. Однако в действительности есть теги, которые вообще мало на что влияют в бытовом вебе и поисковой оптимизации, но они всё равно специфицированы, чтобы именно помогать сохранять те или иные семантические контексты, если это вдруг понадобится. Например, теги удалённого и добавленного текста, чтобы размечать отображения разницы версий текста. Это просто пространство стандарта, которое тоже нужно, потому что такой класс задач существует. И вот HTML уже содержит необходимые решения, которыми при необходимости можно просто сразу взять и воспользоваться, не изобретая новое решение для каждой такой задачи.

Человеческая цивилизация развивалась за счёт накопления и систематизации знаний. В цифровой форме этому процессу помогает не просто хранение данных, но и их правильная разметка. Семантическая вёрстка — это, как бы пафосно не звучала, ваш личный вклад в правильное накопление и хранение знаний человечества. Хранения в виде правильных семантических структур, а не в виде свалки букв.

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

Но даже, если бы семантика в вебе была нужна исключительно незрячим, то всё равно этим бы стоило заниматься, потому что ни один верстальщик не переломится, если заголовки будет размечать через h1-h6.
Просто делайте, как вам сказали, и не рассуждайте.
Это главное, что надо вынести из всей этой дискуссии тем, кто плохо воспринимает абстрактные фундаментальные концепции. (Тут я как бы упрощаю задачу и обеспечиваю accessibility для тех, кто слаб в понимании общей аргументации.)

На этом со своей стороны дискуссию в этом ключе заканчиваю. Вы показали себя как не очень воспитанный и не особо интеллектуально чистоплотный оппонент, сваливающийся в демагогию и подмену понятий, а такие собеседники мне не интересны. Надеюсь, вы умеете и по-другому; жаль, что в этот раз у вас не получилось. Задачу же публичного представления близкой мне точки зрения я уже решил.

Забудьте про div, семантика спасёт интернет

Вот именно там и перечитайте несколько раз следующее:

«Under what circumstances may this not be possible?
• If the feature is available in HTML [HTML51] but it is not implemented or it is implemented, but accessibility support is not.»

Боюсь, вы совсем не представляете, насколько всё сложно и неконсистентно у скринридеров и браузеров в этих вопросах, а также какие бывают специфические ситуации при внедрении WAI-ARIA в реальных проектах, из-за чего именно семантика через role до сих пор в ряде случаев оказывается предпочтительнее. Иногда оправдано даже использование, например, role="list" и role="listitem" вместо <ul> и <li>, хотя уж они-то поддерживаются без проблем. Не всё так просто, как кажется на первый взгляд, после беглого чтения спецификации.

Повторю ещё раз последний абзац из комментария, с которым вы пытаетесь спорить:

«Статьи (и комментарии) про accessibility, написанные в лучшем случае чисто по спецификации без реальной практики, сразу видны. Претендуя на менторство в этих вопросах, стоит если и не иметь богатый опыт, то хотя бы проверять примеры с реальным скринридером.»

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

Забудьте про div, семантика спасёт интернет

> Все что-то втирают про каких-то незрячих людей первым, как будто большинство пользователей интернета слепые. А сколько их на самом деле? Часть процента? И вот ради этих единиц все сайты нужно писать по специальному шаблону? Да перестаньте.

У меня есть к вам несколько очень конкретных вопросов. Надеюсь, вы сможете на них ответить. Прошу подумать и ответить на них также максимально конкретно.

1. Технический вопрос:
   Вам реально объективно проще делать, например, заголовки через div'ы со стилями, чем через h1-h6, или всё-таки если с самого начала просто делать правильно, то объём усилий одинаковый?
   Укажите один из двух вариантов ответа:
   
   1. Трудозатраты на вёрстку без учёта семантики меньше.
   2. Трудозатраты на вёрстку с учётом или без учёта семантики в целом сопоставимы, если с самого начала просто делать правильно.
2. Социологический вопрос:
   Сколько незрячих людей должно быть в Интернете или на вашем сайте, чтобы вы решили, что теперь вы будете верстать с учётом семантики?
   Укажите точное число людей или количество процентов от всей аудитории.
3. Экономический вопрос:
   Вы осознаёте,
   что люди с ограниченными возможностями такие же клиенты с деньгами, как и все остальные,
   что в развитых странах они получают гарантированные социальные выплаты, часто являясь более экономически устойчивыми субъектами, чем многие условно здоровые люди,
   что они приобретают повышенную лояльность к сервисам, обеспечивающим хорошую доступность,
   что они порождают мультипликативные эффекты, приводя в сервис или подсаживая на продукт своих знакомых и родственников?
   Укажите один из двух вариантов ответа:
   
   1. Да, моя точка зрения о нужности accessibility учитывает все эти факторы.
   2. Нет, раньше я не задумывался над этими аспектами.
4. Тест на эмпатию:
   Попытайтесь представить, что вы через месяц потеряете зрение в результате, например, осложнений от гриппа. В какой-то момент вам потребуется заказать доставку еды на дом, но сайты и приложения соответствующих сервисов окажутся недоступными. Скажите, после такого мысленного эксперимента вы по-прежнему придерживаетесь точки зрения, что заниматься accessibility не нужно, потому что целевая аудитория слишком мала?
   Укажите один из двух вариантов ответа:
   
   1. Я по-прежнему считаю, что разработчикам напрягаться в отношении accessibility не нужно.
   2. Я изменил свою точку зрения: учитывать accessibility всё-таки нужно, потому что это вопрос принципиальной невозможности для некоторых людей воспользоваться теми или иными сервисами, в том числе покрывающими базовые потребности, на удовлетворение которых люди с ограниченными возможностями имеют, как минимум, моральное, а, по большому счёту, и юридическое право.
5. Дополнительный тест на принципиальность:
   Если на вопрос 4 вы ответили «Я по-прежнему считаю, что напрягаться в отношении accessibility не нужно», то скажите, вы готовы повторить это, глядя в глаза человеку с ограниченными возможностями, который, например, не смог заказать еды, купить билет на самолёт или сделать очередной платёж по ипотеке в недоступном Интернет-банке, из-за чего получил штрафные начисления?
   Ответьте, да, готовы, или вы только в абстрактном разговоре такой правдоруб-социодарвинист, который регистрирует новые аккаунты, чтобы оставлять такие комментарии анонимно?

Жду от вас конкретных ответов на конкретные вопросы. Равно как и от любого другого, кто согласен с озвученной вами позицией. «А» по вопросу ненужности усилий в сфере accessibility говорят очень многие, но я до сих пор не встретил людей, готовых сказать остальные буквы до самого конца. Обычно уже на втором вопросе начинают мяться.

Забудьте про div, семантика спасёт интернет

> открывает свой компьютер с ни разу не обновлённой WinXP и ie6, и заходит на сайт. Ну ничего не работает. И отказала в оплате.

Просто Internet Explorer все неизвестные для него теги по умолчанию считал как с «display: inline». Ну а все эти и прочие он как раз не знал до версии 9.

> Выпилил я всю эту семантику за 6 нажатий backspace и всё заработало. Так я сделал и сдал HTML5 сайт который работал под ie6.

Ну а теперь в 2021 году я вам расскажу, как это надо было решать правильно. :-)

Проблема решалась следующим кодом в контейнере <head>:

<!--[if lt IE 9]>
<script type="text/javascript">
	var elements = ['article', 'footer', 'header']; // etc
	for(var i = 0; i < elements.length; i++) {
		document.createElement(elements[i]);
	}
</script>
<![endif]-->

Впрочем, в те времена скринридеры ещё совсем плохо поддерживали семантику новых тегов, так что надо было вручную всем им прописывать соответствующие роли через атрибут role: <header role="banner"> и так далее.

Забудьте про div, семантика спасёт интернет

> Никогда не поздно напомнить о важном. Вон даже Хабр на дивах свёрстан, что ж теперь :)

Вёрстка на div'ах в сущности не мешает добавлению семантики для скринридеров. Все специальные семантические теги — это просто блочные контейнеры с предопределёнными ролями. Соответственно можно любому элементу назначить роль вручную: вместо <header> сделать <div role="banner">, вместо <footer> — <div role="contentinfo"> и так далее. На заре эры семантических тегов это и вовсе было более предпочтительным решением, да и до сих пор в некоторых случаях явное указание роли через role всё ещё может требоваться, так как «голые» семантические теги не всеми скринридерами обрабатываются корректно.

Более того, через role доступен ряд ролей, для которых нет аналогов в виде предопределённых тегов, например, role="note".

Кроме того, вы смешали всю семантику в одну кучу. В действительности, какой-нибудь <main> и <article> — это сущности несколько разного порядка, а не просто разновидности семантических тегов. <section> и вовсе основными скринридерами без aria-label игнорируется, так что одно его добавление ничего не даст.

Статьи про accessibility, написанные в лучшем случае чисто по спецификации без реальной практики, сразу видны. Претендуя на менторство в этих вопросах, стоит если и не иметь богатый опыт, то хотя бы проверять примеры с реальным скринридером.

Конкурс World & AI Data Challenge: начинаем решать задачу распознавания шрифта Брайля

Спасибо за статью. Это было интересно, правда в основном в первой половине.
Однако у меня есть два серьёзных дополнения:

Во-первых, существует такой продукт как Braille Reader VDL, который был разработан в России много лет назад, и поставлялся заинтересованным заказчикам (в том числе за границу) как коммерческое решение обсуждаемой задачи. Правда там скорей задача оцифровки документа чтобы отсканировать книгу и сохранить её для возможной повторной печати, то есть без распознавания именно смысла текста.

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

Прежде всего, Брайль — это система, в которой знаки составляются из ячеек по 6 (в особых случаях по 8) точек).
На листе будет фиксированное количество строк и фиксированное количество столбцов, а само шеститочие/восьмиточие даже при разных форматах листов плюс-минус одного размера, комфортного для тактильного восприятия.
То есть логично сначала определить условную сетку ячеек на листе, а потом анализировать каждую получившуюся ячейку. Думаю, это повысит устойчивость к ошибкам из-за шума: если какой-то артефакт на изображении есть не в сетке, то его в принципе можно игнорировать.
Ну и, как я уже написал, размер ячейки и точек сильно не различается, так что там должны быть плюс-минус одни и те же пропорции. В частности, в России есть вообще конкретный стандарт по параметрам брайлевской печати — ГОСТ Р 56832-2015 Шрифт Брайля. Требования и размеры

На этом этапе я бы советовал результаты распознавания сохранить как есть, то есть в виде комбинаций точек. В частности, существует две распространённые системы кодирования: Braille ASCII и Braille Patterns.
На Braille ASCII базируется такой формат документов, как BRF. То есть фактически мы сможем легко отправить отсканированный текст снова на печать. Это полезно, когда, например, мы сканируем старую книгу с целью подготовки её переиздания. Вышеупомянутый продукт Braille Reader VDL как раз решал эту задачу, которая была сильно востребована в библиотеках, желавших спасти старые брайлевские издания нот.
Зато нотация Braille Patterns кодирует не 6, а 8 точек брайлевского знака, да и может быть легко сконвертирована в Braille ASCII. Правда восьмиточечный Брайль не используется в бумажной форме, так что вряд ли это актуально для задачи сканирования.

Ну и вот что касается уже получения текста из комбинаций брайлевских точек, то сложность этой части, как мне показалось, вы как раз сильно недооцениваете.
Дело в том, что одна брайлевская ячейка совсем не соответствует какому-то символу. У шеститочия всего 64 варианта (считая пробел), поэтому там просто не хватает вариативности.
В итоге, вбрайлевском письме целый ряд символов кодируется одинаковым набором точек и их трактовка зависит либо от контекста, задаваемого окружением, либо вообще от чисто смыслового контекста. Причём, контекст окружающих символов может задаваться не только в соседних ячейках, но и существенно дальше. Например, строки

• 1234567890
• abcdefghij
• абцдефгхиж
• αβφδεφγθιη

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

В индустрии вспомогательных технологий в основном решается задача трансляции обычного текста в брайлевский, потому что именно она наиболее востребована (брайлевские дисплеи, подготовка текстов к печати и т.д.). Но есть open source библиотека Liblouis*, которая является наиболее распространённым решением и теоретически обеспечивающем трансляцию в обе стороны.
Однако трансляция брайлевского текста в обычный в любом случае сложнее и менее надёжна, чем обычного в брайлевский, да к тому же уровень поддержки языков в брайлевских трансляторах сильно разнится. В частности, поддержка русского оставляет желать много лучшего даже при трансляции обычного текста в брайлевский.
Я сомневаюсь, что эту задачу даже на минимальном уровне смогут решить случайные люди, толком не знающие Брайля, да к тому же с наскока за несколько недель. Мне кажется, что вся сложность этой задачи вами сильно недооценивается.

Думаю, полезнее сосредоточиться на решении чисто задачи сканирования брайлевского текста с последующим распознаванием в нотацию Braille ASCII или Braille Patterns. Это абсолютно реально для современных систем компьютерного зрения и относительно несложно, так что вполне можно собрать рабочий прототип за пару недель. Это будет полезно как раз для сохранения старых брайлевских изданий, для которых уже не осталось цифровых исходников или типографских матриц для нового тиража.
Ну а задачу трансляции брайлевского текста в обычный стоит решать уже в рамках отдельной исследовательской работы, где на вход сразу принимать эти строго формализованные нотации описания брайлевских символов, или же сразу приходить в проект Liblouis* и делать вклад в него.

Вступил в силу новый ГОСТ для цифровых ресурсов: все платформы должны быть доступны для инвалидов

> Как мне определить, может ли исполнитель верстать по стандартам?

Можно дать ему тестовое задание или попросить пример работы по предыдущим проектам и проверить страницу автоматическим валидатором доступности, типа Axe.

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

Тут же можно попросить исполнителя прокомментировать отчёт автоматического валидатора и по общему впечатлению оценить, насколько он плавает или не плавает в теме.

> Как мне определить аудитора, который нормально проверит работу верстальщика?

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

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

Как минимум, аудитор должен уметь работать с технологиями на пользовательском уровне. Причём, не с какой-то одной, а со всеми основными. Кстати, очень вредно, когда веб-доступность разработчики тут же проверяют на своей macOS, потому что подавляющая часть аудитории будет на Windows.

У нас сейчас доступность — это очень хайповая тема на конференциях. Появилась куча самопровозглашённых экспертов.

Очень простой тест: кладёте на стол 5000 руб., и предлагаете такому эксперту сделать тоже самое.
Далее запускаете на компьютере браузер, программу экранного доступа и завязываете эксперту глаза, после чего засекаете 5 минут, за которые он должен, например, заказать на сайте пиццу.

Если он справится или же обосновано объяснит, что за 5 минут не удалось найти доступный Интернет-магазин, то он забирает 10000 руб., если же он просто эти 5 минут будет слепо тыкаться по странице поисковика и даже не сможет найти нужный сайт, то 10000 руб. забираете вы.

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

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

Тут уже обратная история, когда можно попасть, например, на обычного незрячего человека, который уже по факту своей инвалидности считает себя экспертом. Причём, часто чем меньше компетенций, тем больше гонора, часто с рекомендациями, завязанными на очень спорный субъективный опыт. Попытки взаимодействовать с общественными организациями инвалидов и различными НКО обычно приводят именно к такому.

В действительности, есть несколько подходов к взаимодействию с веб-интерфейсом, и при экспертизе нужно учитывать их все, равно как и специфику разных конфигураций ПО, так как сочетания разных браузеров и вспомогательных технологий имеют свои нюансы. Любимых браузеров или программ экранного доступа в этих вопросах быть не должно.

Кроме того, отзыв «а тут я не смог» мало полезен. От Аудитора всё-таки желательно получать хотя бы примерную техническую рекомендацию. Без способности её предоставить он замедлит и усложнит весь процесс обеспечения доступности.

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

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

> И правда ли, что несмотря на то, что сообществу программистов-фронтендеров, начиная с гугла и мозиллы, глубоко пофиг на эти стандарты, и они их соблюдают только там, где им выгодно, есть отличный от нуля шанс найти рыцаря кода и разметки, а не костылей и велосипедов?

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

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

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

Вёрстка на div'ах — это ведь прямое следствие быстрого входа в профессию. Люди узнают основы и уже начинают верстать, в том числе устраиваясь на работу. Добившись первых заработков или полноценного трудоустройства, многие просто уже не доходят в своём образовании до полного понимания концепций семантичности веб-интерфейсов, потому что формально уже пришли к успеху и дальнейшее изучение представляется чем-то излишним.

Впрочем, кнопка на div тоже может быть доступной:

<div tabindex="0" role="button" aria-label="Название"></div>

Но вот это как раз уже и требует специальных знаний, которые правда описываются не в WCAG, а в WAI-ARIA. Да и в любом случае до такого лучше не доводить. Это обычно когда мы чиним доступность интерфейса, боясь чихнуть в структуре вёрстке, чтобы ничего не поломать.

В действительности правильная вёрстка в подавляющем большинстве случаев доступна уже из коробки. Соответственно у грамотного верстальщика доступность во многом должна выходить автоматически, а значит никак и не удорожать процесс. Это также, как написать «молоко» или «малако»: усилия одни и те же, просто одно правильно, а другое нет. Вот только с копирайтерами, которые пишут «малако», никто не хочет работать, а верстальщиков на div'ах берут даже крупные компании.

Поэтому давайте выпьем за то, чтобы мы все дожили до тех времён, когда делать кнопку через div будет также стыдно, как сейчас написать «малако»!
Через несколько дней будет GAAD, так что это хороший повод начать со своих собственных проектов.

Технологии, которые помогают незрячим выучить английский

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

А вы уверены, что всегда сможете визуально отличить латинскую A от кириллической А, C от С, E от Е, K от К, M от М, O от О, T от Т, X от Х?

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

> Это видящему достаточно просто взглянуть на слово, чтобы понять, что оно на английском

А на каком языке написано слово «ХOР»? Как вы думаете, я имел ввиду группу поющих людей или сокращение термина eXtended OPerations? А вот в Брайле как раз всё будет однозначно, потому что будут стоять индикаторы алфавита.

Это не говоря о том, что проблема распознавания языка отдельно стоящего слова вообще надумана. В подавляющем большинстве случаев у человека есть контекст соседних слов или ситуации.

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

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

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

> Конечно, существуют наработки школ для слепых, но исследования их эффективности просто не проводились. Результативность такого формата часто не идеальна, но по сути другого варианта не остается.

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

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

Существует отдельное направление «коррекционная педагогика», внутри которого выделяется подраздел «тифлопедагогика». Научным наработкам в этой области много десятилетий. В России несколько университетов с соответствующими факультетами.

Между прочем, начать надо с того, что доказать необходимость специальной методики изучения для незрячих, выходящей за рамки простой адаптации учебных материалов под невизуальное восприятие, типа печати обычного учебника по-брайлю, как делается практически со всеми предметами: от математики до литературы.

> Даже в миллионниках такая школа может быть только одна, а в городах поменьше и вовсе подобных школ может не быть. Поэтому большинство тех, кто хотел бы изучать английский, просто не имеют физической возможности добираться к учебному заведению.

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

> В целом для использования компьютера незрячему человеку требуется только клавиатура со шрифтом Брайля и скринридер.

Что такое «клавиатура со шрифтом Брайля»?

Обычная клавиатура с брайлевскими метками на клавишах? Но зачем? Покажите хоть одно такое устройство в широком употреблении.

Клавиатура в стиле Перкинса с шестиклавишным или восьмиклавишным вводом брайлевских символов? Но вообще-то это, как правило, элемент тех самых брайлевских дисплеев, которые вы назвали неэффективными.

> на февраль 2020 года просто не существует адаптированных онлайн-программ по изучению английского языка для русскоговорящих слепых.

blind-study.ru/course/95

> нужно либо устанавливать сразу два синтезатора и получить кучу проблем с совместимостью

Что такое «проблема совместимости» в контексте установки русского и английского синтезатора речи? Это не два антивируса, чтобы они начали воевать друг с другом.

> При наличии визуального дисплея можно даже переводить изображения в тактильную форму.

Как «визуальный дисплей» может помочь перевести изображение в тактильную форму? И причём здесь вообще DAISY, который представляет собой контейнер из MP3-и XML-файлов?

Тактильная графика — это рельефное изображение простых форм, изготавливающееся вообще отдельным видом устройств по заранее подготовленному макету.

Ну и так далее, и тому подобное… По меньшей мере мелкие неточности есть практически в каждом абзаце статьи.

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

«Онлайн школа EnglishDom», накажите вашего SMM'щика, который это придумал и реализовал. Это просто шлак, который будет забивать поисковики мусором по теме, по которой возможно люди в тяжёлой ситуации будут искать жизненно-необходимую информацию. Неужели этот дешёвый хайп на теме ппоказушного сочувствия инвалидам так уж поможет вашему бизнесу? Будет несколько тысяч просмотров с нулевой конверсией, а вот мусорный шум для поисковиков создали. Неужели самим не противно от такой халтуры?

Neuronomics. Идея для стартапа 2030 года

Как я и писал, никакой серебряной пули в изучении экономической теории не существует. Нет какой-то пары «правильных» статей, по которым можно всё изучить. Только сотни человекочасов на изучение сначала простых абстракций, а потом их последовательное усложнение. Это в программировании можно не учить BASIC, а сразу учить Python или даже C, и дальше прекрасно себя чувствовать, вообще не зная BASIC. В экономике придётся пройти весь путь с начала, от всех этих функций полезности и рационального выбора, которые не имеют никакого отношения к реальности, но являются языком для более сложных описаний.

Спойлер с подробностями

Для начала можно брать практически любой учебник по целевому курсу. Азы там везде одинаковые.

• Учебник для первокурсников по предмету типа «Экономическая теория» объяснит базовые понятия. Читать можно бегло- потом утрясётся.
• Далее нужен учебник по предмету типа «Микроэкономика». Это базовые абстракции, описывающие поведение экономических агентов (фирм и домохозяйств) на однородных рынках, то есть рынках одного товара. Здесь нужно освоить формальный язык описания и понять методы анализа.
• Потом нужно посмотреть учебник по предмету типа «Экономика предприятия». Здесь формализуется внутренняя структура фирмы и механизмы её работы, потому что в микроэкономике фирмы описываются просто как чёрный ящик в виде производственной функции (на вход ресурсы, на выход товар). В этом же курсе объяснят про фонды, амортизацию и прочее.
• После микроэкономики (можно параллельно с экономикой предприятия) надо посмотреть учебники по предмету типа «Макроэкономика». Менее века назад (формально в 1936 году) наука пришла к пониманию, что экономика страны является более сложной системой, чем совокупность микроэкономических агентов. В больших системах появляются специфические процессы, не заметные на уровне базового взаимодействия агентов на одном рынке. Здесь как раз начнут вводится категории валового продукта, инфляции, агрегированного спроса и предложения, совокупных инвестиций и прочего.
• Здесь же следует посмотреть учебники по предмету типа «Мировая экономика», где описывается взаимодействие между странами, их роль в мировом хозяйстве и прочее.
• Будет не лишним и прочитать учебник по предмету типа «История экономических учений», чтобы понимать как и откуда всё развивалось со времён древних греков до наших дней. Это поможет лучше понимать внутреннюю логику многих теорий.
• Ну и базовые математические знания надо закрепить учебниками по предметам типа «Финансовые вычисления», «Эконометрика» и «Математические методы в экономике». Это фактически алгоритмы расчёта типовых экономических категорий, математическая статистика и решение оптимизационных задач в экономических областях.

Всё это можно изучать практически по любому учебнику для младших курсов экономических вузов. Фактически это примерно профильная часть первых полутора-двух лет на экономическом факультете.

Здесь важно понять практически всё, потому что без этого дальше идти не имеет смысла.

Есть три важных момента:

1. Стоит опасаться фастфуда, типа «Экономическая теория за 24 часа», потому что там многое выбрасывается. Ну и научпопа, типа весёлых роликов на YouTube с шутками и прибаутками, потому что научпоп — это тоже примитивизация, да к тому же с высокой долей субъективизма, когда автор считает допустимым, например, высмеивать сторонников какой-то теории, а не делать её анализ. Лучше всего брать просто вузовские учебники — скучно, но систематизировано.
2. Не стоит боятся использовать русскоязычные учебники и учебники русских авторов. На этом уровне в иностранных всё то же самое. Более того, когда мы пойдём дальше, некоторые вопросы экономической теории у зарубежных авторов просто не рассматриваются. Например, в США доллар — это валюта и для внутренних, и для внешних расчётов (там есть нюансы, но про них в учебниках не пишут), поэтому проблемы, характерные для экономик с различающимися внутренними и внешними валютами в обычных американских учебниках если и рассматриваются, то недостаточно подробно, а часто вообще игнорируются.
3. В учебниках (да и в науке) существует мейнстрим и даже практически мода. Сейчас мейнстрим — это неоклассические теории, провозглашающие эффективность рыночной саморегуляции. Это заметно практически во всех распространённых учебниках. Это надо воспринимать спокойно. После Великой депрессии мир был напуган и тогда были популярны теории государственного регулирования, которые объективно лучше работают в условиях кризиса. Потом от настолько крупных кризисов отвыкли, так что ударились в другую крайность. Это просто надо понимать и воспринимать описание разных теорий более нейтрально. Ну и масонов в этом обвинять тоже не стоит.

Если после всего этого не сломаетесь, то можно идти дальше.

• Во-первых, надо взять учебники следующего уровня по микроэкономике и макроэкономике. Там будет написано что-то типа «для старших курсов» или «для продолжающих изучать». Они более глубоко описывают знакомые модели и вводят более сложные описания экономических процессов. Сейчас в России эти курсы в вузах имеют говорящие названия «Микроэкономика 2» и «Макроэкономика 2».
• Во-вторых, из микроэкономики на этом уровне отпочковывается такое направление как «Экономика отраслевых рынков». Здесь даётся более глубокое понимание типов рыночных структур, моделей рыночной конкуренции и прочего. То есть как вообще фирмы толкаются друг с другом на рынке и как это моделируется.
• В-третьих, макроэкономика на этом уровне уже начинает разваливаться на отдельные поддисциплины, которые также требуют изучения. Соответственно надо брать учебники по курсам типа «Денежно-кредитная политика», «Налогово-бюджетная политика», «Инвестиционная политика». Это сформирует реальные представления об этих областях экономики, потому что базовые модели очень абстрактно описывают тот же налоговый фактор или архитектуру банковской системы, тогда как их реальное влияние в каждой стране надо чётко понимать.
• В-четвёртых, полезно изучить какой-нибудь курс с названием типа «Социально-экономическая статистика». Это даст представления о специфике экономических показателей, всяких классификаторов экономической деятельности и прочего, чтобы потом понимать, как вообще экономика оцифровывается и представляется в количественном виде. Тут надо чётко понять общие принципы, ну а для отдельных стран потом всё равно придётся добирать знания, изучая конкретные методологии и классификаторы их национальных статистических служб.
• В-пятых, в зависимости от интересующей области надо добрать фокусных знаний. Это может быть что-то про финансовые рынки, про экономику сельского хозяйства, про риски и страхование и прочее. Этот блок даже в экономических вузах в рамках одной специальности полностью не покрывается. Тут надо смотреть по обстоятельствам. Фактически для симуляции надо минимум покрыть специфику сельского хозяйства, тяжёлой и лёгкой промышленности, сферы услуг, а также финансового сектора.
• В-шестых, скорей всего, после чтения распространённых учебников останутся несколько брешей в эрудиции, которые являются следствием политизации системы образования. Здесь нужно залатать дыры в представлениях о марксистских теориях, методах управления плановой экономики (в основном на примере СССР) и прочего. Никаких откровений и экзальтированного восприятия как «тайной скрываемой правды». Просто это было, у этого есть своя внутренняя логика и многое из этого применялось и работало десятилетиями, так что игнорировать неправильно.

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

• Во-первых, государственные органы публикуют отчёты и стратегии, где, помимо прочего, описывают логику принятия решений и планы на будущее. Например, знающие люди, которые читали ежегодный документ про политику ЦБ РФ, были в курсе того, что в 2014 году будет падение курса рубля. Это писалось чёрным по белому в течение нескольких лет. Конечно, если бы не неожиданный факторы 2014 года, падение было бы не в два с половиной раза, но в полтора точно. Это к тому, что эти документы надо изучать, чтобы быть в курсе и понимать, что планируется. Вот только там пишется не напрямую, а описывается набор мер, а цепочку последствий уже надо просчитывать на основе знаний, полученных на двух предыдущих этапах изучения экономики.
• Во-вторых, надо взять научные базы, типа РИНЦ, Scopus и Web of Science, отсортировать там журналы по рейтингу и просматривать публикации в основных авторитетных изданиях. Там как раз и появляются статьи с переднего края экономической теории, описывающие развитие моделей, ещё не дошедшие до учебников. Если интересует конкретный вопрос, то в этих же базах надо искать статьи за всё время по соответствующим темам (есть общий поиск, а также все статьи протегированы ключевыми словами). Кстати, опять же не надо игнорировать русскоязычные публикации. Радуйтесь, если вам доступны материалы на большем числе языков. Анализ российской экономики мало кому интересен в иностранном журнале, поэтому даже очень сильные работы туда не всегда попадают.
• В-третьих, если интересующий вопрос достаточно объёмный, то стоит смотреть не просто статьи, где объём сильно ограничен, а монографии. Часто на монографии можно выйти, просматривая списки библиографических ссылок в научных статьях.

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

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

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

Однако всё это не означает, что кругом дураки. Просто на людей с комплексными представлениями в области прикладной макроэкономики нет широкого спроса. Ну много ли надо их даже на всю страну и так ли часто они уходят на пенсию? Поэтому это единицы, вырастающие на энтузиазме где-нибудь в академической среде или выкристаллизовывающиеся на отдельных должностях. Рядовой экономист занимается экономикой предприятия, логистикой, расчётом конкретных финансовых моделей фирмы и прочего. Это то, что покрывает 99% всех запросов к экономистам, и там другие требования к знаниям.

Neuronomics. Идея для стартапа 2030 года

> Как на реальные фирмы действует некий фактор, так и на нейросети он действует точно так же. Таким образом думаю что какая бы из теорий не была верна (полностью или частично) именно генетический алгоритм поможет выяснить как это работает)

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

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

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

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

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

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

Neuronomics. Идея для стартапа 2030 года

Извините, но в экономике всё устроено намного сложнее.

Комментарий под спойлером, получившийся слишком большим

Например, то же повышение ставок одновременно порождает как антиинфляционный, так и инфляционный импульс.

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

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

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

Кроме того, в разных странах разная структура экономики, и где-то сроки выплаты дивидендов играют существенную роль для всей экономики, если там развитый фондовый рынок и много публичных компаний, а где-то влияние этого фактора незначительно, потому что доля таких фирм мала. То есть эффект от применения этого инструмента ДКП будет различаться от страны к стране. Да и в одной стране в кризисный период публичные компании могут отказываться от выплаты дивидендов и соответственно снижать значимость этого фактора.

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

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

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

Отдельным вопросом является специфика расчёта формально одних и тех же статистических показателей в разных странах. Например, тот же ВВП в Великобритании и России рассчитывается по разным методологиям: в Британии используются методы, способствующие завышению, в частности, включение в расчёт неформального сектора, типа производительности проституток (и это не шутка, там есть специальные вменённые величины выручки и издержек работников этого нелегального сектора), а в России занижающие, когда неформальный сектор игнорируется. При этом, в последующих международных сопоставлениях эту разницу обычно игнорируют и работают с ВВП как с однородными данными, просто приводя по ППС, например, при назначении тех же кредитных и инвестиционных рейтингов стран.

Да и если у показателя одна и та же методология расчёта, например, как у какой-нибудь безработицы общая методология МОТ, то никуда не девается национальная специфика. В частности, безработица где-нибудь в США является показателем, достаточно чувствительным к конъюнктуре, тогда как в России динамика безработицы намного меньше связана с кризисными процессами, потому что отличается трудовое законодательство и рынок труда в целом, из-за чего люди намного реже увольняются с работы, даже когда у компании всё плохо, да и биржи труда устроены по-другому.

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

Кроме того, в ваших рассуждениях заметно влияние идеологизированных источников знаний, оперирующих предвзятыми политизированными лозунгами, а не фундаментальным пониманием природы процессов, например, в тезисе:

". Соответственно в кризис инфляция падает, если только руководство вменяемое и не пытается напечатать «чтоб всем хватало» типа как в Венесуэлле сейчас"

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

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

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

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

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

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

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

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

P.S. Если что, мне было интересно прочитать пост. Этим комментарием как-то обесценить работу и обидеть не хотел. За статью в любом случае спасибо.

Доступ в интернет открыт: технология LUWRAIN помогает слепым пользователям

> можно, пожалуйста, ещё раз пояснить, за что я должен извиниться?

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

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

Хорошо, зафиксируем итог дискуссии:

В самом начале пользователем DollaR84 спокойно был задан вопрос о фактических преимуществах LUWRAIN по сравнению с уже существующими технологиями невизуального доступа. От Михаила поступил расплывчатый ответ с указанием на спорные преимущества в виде якобы эксклюзивной доступности TeX. В ответ на справедливо высказанные пользователями marsalovv и DollaR84 сомнения, Михаил огульно обвинил людей в теоретизировании без понимания практики вопроса, причём, было написано следующее:

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

Это полная цитата Михаила из комментария от 18:24 06.06.2019 без какого-либо вырывания из контекста. Фактически там содержится 3 утверждения:

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

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

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

В реальности же:

• Во-первых, Михаилу были предоставлены объективные доказательства штатной возможности работы с графическими менеджерами презентаций без помощи зрения в виде одного из многих давно существующего методического пособия для незрячих, а также живой демонстрации работы незрячего пользователя с PowerPoint.
• Во-вторых, Михаилу было указано на то, что решение, предлагаемое в рамках LUWRAIN, а именно работа в текстовом редакторе с TeX, точно также доступно и в графических средах с программами экранного доступа, поэтому никаким преимуществом LUWRAIN это не является, а наоборот, лишь представляет собой суженное пространство возможностей по сравнению с использованием программ экранного доступа.
• В-третьих, от Михаила так и не были получены обоснованные объяснения, что именно в доступных офисных пакетах он называет «проблемами с выделением текста». Михаил по данному вопросу попытался передёрнуть и перевести разговор на выделение текста в терминале Linux, хотя из вышеприведённого изначального заявления отчётливо видно, что речь была о якобы проблемах выделения в офисных пакетах.
• В-четвёртых, полностью дискредитированные в ходе дискуссии первые два утверждения Михаила автоматически дискредитируют и третье, сводящееся к тому, что его позиция поддерживается какими-то людьми с каких-то конференций. Можно лишь констатировать, что как Михаил, так и его знакомые с конференций, одинаково плохо разбираются в вышеупомянутых вопросах.

Я не Михаил, поэтому не буду никого называть полным дураком. Я не подвергаю сомнению компетентность и квалификацию Михаила в вопросах программирования как такового и признаю за ним хорошие знания в области невизуальной доступности Linux, особенно в сфере неграфических сред.
Однако в области общего ландшафта вспомогательных технологий на разных системах и принципиальной доступности тех или иных задач без зрительного контроля Михаил в рамках этой дискуссии продемонстрировал полнейшую некомпетентность и безграмотность. Представленная выше выжимка всей дискуссии это доказывает вполне однозначно, а текст содержит ссылки на упомянутые комментарии, так что любой желающий может с ними ознакомиться в оригинале и убедиться самостоятельно.
Кроме того, сама манера ведения дискуссии у Михаила бескультурна и крайне токсична, да и не соответствует академическим стандартам: это касается как хамских заявлений, с которых он начал, так и недобросовестных полемических приёмов в виде смены темы, передёргивания и Галопа Гиша, которыми продолжил.
Полноценная дискуссия невозможна, когда одна из сторон нарушает правила, а также не обладает достаточными знаниями, чтобы в принципе работать с аргументацией оппонента, как, например, Михаил не знает на должном уровне и в актуальном состоянии принципы и возможности невизуальной работы на системах типа Windows или macOS, невизуальную работу в пакете Microsoft Office, ну или работу с TeX вне Linux.
Даже просто то, как Михаил вёл эту дискуссию, достаточно дискредитирует его позицию по поднятым вопросам, ну а для реальных специалистов, владеющих актуальными знаниями по невизуальной доступности графических сред вне Linux, слабость позиции Михаила очевидна с первых же строк.
Сам же Михаил не заинтересован в расширении своих знаний, хотя и разрабатывает кроссплатформенное решение с пафосным позиционированием в виде якобы самого удобного для незрячих интерфейса, однако и это сейчас также не является правдой, поэтому продолжать что-то объяснять лично ему бесполезно.
Ввиду этого задачу данной дискуссии я считаю выполненной и со своей стороны её прекращаю.

Dixi.

Доступ в интернет открыт: технология LUWRAIN помогает слепым пользователям

> Я уже давно потерял нить дискуссии, просто перешлю ответ Михаила как есть.

ofmetal, совершенно верно. Михаил старательно размывает границы и предмет дискуссии, используя приём Галоп Гиша, сводящийся к забрасыванию оппонента кучей новых доводов, не заботясь об их качестве и соответствии изначальной теме, а также игнорируя содержательную часть встречных доводов. Он требует всё следующих и следующих аргументов от оппонента, со своей стороны отказываясь обсуждать и признавать ранее приведённые доводы, полностью опровергающие его заявления, которые и являлись изначальным предметом дискуссии.
В своём новом сообщении Михаил 2 раза написал «прошу демонстрацию» и ещё по одному разу «пожалуйста, дайте», «прошу описание», «прошу показать» и «прошу привести», каждый раз расширяя общий объём дискуссии, но при этом со своей стороны не дал никаких предметных ответов на предыдущие доводы, в том числе с бесспорной демонстрацией существования того, что он отрицал, а именно являющуюся нормой долгие годы возможность работы в PowerPoint без зрительного контроля.
Он также здесь подвергает сомнению возможность создания презентации на Windows в простом текстовом редакторе при помощи TeX и стандартных программ экранного доступа, что является абсолютным нонсенсом, так как принципы этого процесса аналогичны тому, как он собирается это реализовывать в LUWRAIN и как он сам это делал все эти годы, а именно: набор нотации TeX в редакторе и компиляция этого файла в PDF посредством кроссплатформенных утилит, существующих под все распространённые системы, в том числе и Windows. В Windows также существуют инструменты типа специализированного TeX-редактора WinEdt, ещё больше облегчающего процесс работы с TeX, и всё это доступно и активно используется незрячими долгие годы.
В том числе, эти возможности являются комбинируемыми, в частности, вставка в презентации на PowerPoint формул, написанных на TeX, равно как и их вставка в альтернативные системы презентаций, например, генерирующих HTML-слайды из markdown. Более того, та же математика в презентациях на PowerPoint по ряду критерий более доступна, так как формулы могут быть не просто написаны, но и прочитаны со слайда без помощи зрения, тогда как продвигаемый Михаилом вариант имеет перекос в сторону создания.
Отсылки к его неудачному опыту пробы всех этих технологий когда-то давно являются лишь дополнительными доводами против него и уровня его исследовательской работы в области невизуальной доступности, потому что его вопросы про получение текста всего окна на Windows явно показывают, что он даже не прочитал список команд того же JAWS (JAWSKey+Alt+W (ранее до JAWS 11.0 в 2009 году JAWSKey+CTRL+W) и далее работа в окне виртуального просмотра), но сейчас хотелось бы закрыть хотя бы один пункт с презентациями, так что сосредоточимся на нём.

Итак, одним из первых пунктов дискуссии было заявление Михаила, что в графических средах, в том числе в связке PowerPoint с программой чтения экрана, невозможно без зрительного контроля создавать презентации. Это было одно из главных его программных заявлений, на основе которых он выводил тезис о неоспоримом фундаментальном превосходстве LUWRAIN над существующими альтернативами, когда его об этом в самом начале спросил пользователь DollaR84.
Михаил ссылался на свои якобы достаточные знания по этому вопросу, мнение каких-то специалистов по доступности высшего образования с каких-то конференций, а также якобы отсутствие фактических подтверждений этой возможности. Причём, делал это в достаточно невоздержанной агрессивной форме в безапелляционном менторском тоне.
В предыдущем комментарии Михаилу были предоставлены объективные подтверждения наличия такой возможности в виде существующих долгие годы методических материалов, а также живая демонстрация работы незрячего пользователя в PowerPoint на Windows с программой экранного доступа. Про инсинуации в последнем сообщении Михаила о якобы недоступности TeX на Windows сейчас даже и не говорим, потому что это уже пробивание дна.
В связи с этим, для продолжения дискуссии и рассмотрения аргументов следующего этапа, хотелось бы всё-таки услышать от Михаила одно из двух:

1. Либо публичное признание собственной неправоты и недостаточной компетентности в вопросе доступности работы с презентациями в графических средах, равно как его консультантов с хвалённых конференций, на которых он активно ссылался как на истину в последней инстанции. Никаких самоуничижительных формулировок я не требую, достаточно лаконичного «Признаю, ранее озвученная мной информация не соответствует действительности; это было мне не известно, и привлечённые консультанты меня ввели в заблуждение, а я не проверил».
2. Либо прямо сформулированное открытое конспирологическое обвинение в фабрикации приведённых доказательств на web.archive.org и YouTube с привлечением третьих лиц из разных стран.

Это последний раз, когда я призываю всё-таки ответить на приведённые объективные факты. Бесконечно повторять это нет никакого желания.
Пока Михаил не выполнит стандартных требований обоснованной дискуссии с последовательным взаимным рассмотрением аргументов друг друга, считать его добросовестным участником дискуссии не представляется возможным.
Таким образом, я ожидаю от Михаила добросовестного ответа на уже выдвинутые доводы, без которого рассмотрение дальнейших вопросов, которые он поднимает, не имеет никакого смысла, хотя и там им допущен ряд неточностей и грубых искажений, но об этом имеет резон говорить, только если он делом докажет свою способность вести дискуссию по академическим стандартам.

Доступ в интернет открыт: технология LUWRAIN помогает слепым пользователям

> Несогласных коллег прошу привести конкретные чёткие примеры инструментов, которые позволяют создавать интерфейсы для невизуальной работы с API.

Ответ на этот тезис содержался в одном из предыдущих комментариев, который в содержательном смысле был проигнорирован. Повторю более развёрнуто.
Реализация любой функциональности, например, того же конвертора DAISY, или клиента для любого API, например, той же «ВКонтакте», может быть написана в доступной кроссплатформенной форме на существующих технологиях GUI, например, wxWidgets или web UI.
Получившийся интерфейс будет доступен за счёт существующих вспомогательных технологий в виде программ экранного доступа, которые на сегодняшний день предлагают более богатые функции по работе с текстовой информацией, если она предоставлена в доступном виде (см. прошлые замечания про ущербную функциональность LUWRAIN при навигации по тексту).
Причём, обращу внимание, что разработка клиента для какого-то API на том же Python с доступным GUI на каком-нибудь wxPython представляется не более трудоёмкой задачей, чем аналогичная разработка внутри LUWRAIN, а степень документированности общераспространённых решений для сторонних разработчиков на порядок выше, чем LUWRAIN.
Опережая возможное возражение, отмечу, что wxPython не требует строгого визуального контроля для создания интерфейса, в частности, весь интерфейс NVDA и её дополнений написан именно на нём командой незрячих разработчиков, равно как и ряд других проектов.
Таким образом, реализация поддержки какого-то API в рамках среды LUWRAIN — это лишь один из возможных вариантов, причём, далеко не во всём лучший, потому что дружественность LUWRAIN к внешним разработчикам низкая (фундаментальные изменения каждые несколько лет, плохая документированность, ограниченный набор языков разработки), да и сам LUWRAIN уступает экранным чтецам по эффективности работы незрячего с текстовой информацией, о чём было сказано ранее с приведением конкретных примеров.

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

Давайте всё-таки зафиксируем рамки дискуссии:
Я никогда не заявлял, что пользы от разработки платформы LUWRAIN не существует и что идея бесперспективна, поэтому данную точку зрения я отстаивать не собираюсь. Попытка перевести дискуссию в эту плоскость я считаю недобросовестным приёмом смены темы.
Прошу придерживаться главных вопросов, которые были подняты в начале обсуждения, а именно:

1. Искажённая информация об альтернативных решениях, которым приписываются несуществующие недостатки на фоне чего предпринимается попытка сформулировать мнимые преимущества LUWRAIN, тогда как можно спокойно обсуждать реальные преимущества LUWRAIN, а не выдуманные.
2. Наличие в LUWRAIN ряда проблем самой базовой функциональности, которые не позволяют говорить о её интерфейсе как об однозначно наиболее удобном и эффективном для незрячих (см. замечания про ущербность навигации по тексту в предыдущем комментарии).

Также стоит отметить, что идея использования публичных API для обеспечения доступности соответствующих сервисов звучит достаточно логично, но имеет целый ряд нюансов.
Дело в том, что публичные API часто имеют более узкую функциональность, чем основной пользовательский интерфейс.
Это обуславливается тем, что многие из них ориентированы не на поддержку полнофункциональных клиентов, а на предоставление интерфейсов для мониторинга отдельных параметров системы.
API тех же сервисов Яндекса далеко не во всём эквивалентны web-интерфейсам. Google Docs также, по крайней мере, раньше, но возможно и до сих пор, через web-интерфейс предоставляли больше возможностей, чем через API.
Ввиду этого, плевки Михаила в сторону работы с каким-нибудь Google Docs через браузер выглядят крайне некомпетентно, особенно ввиду того, что поддержка Google Docs в LUWRAIN обсуждается уже несколько лет, но до сих пор не реализована, так что спор фактически вокруг сравнения уже работающего решения через программы экранного доступа и некого прожекта в рамках LUWRAIN, бесконечно обещающего светлое будущее.

> Любой коллега может проверить, какими масштабами кода может оперировать незрячий человек, если он откажется от утилит экранного доступа.

Считаю этот тезис бессодержательным по следующим причинам:

1. Не существует никаких общепризнанных метрик оценки возможности предельного объёма кода, которым может оперировать незрячий или любой другой человек. Не существует также никаких общеизвестных порогов возможностей, установленных эмпирически. Отсылка к этому как к само собой разумеющемуся представляется спекуляцией.
2. Само понятие «объём кода» представляется спекулятивным, потому что существует модульность кода проекта, а также разные языки обладают разной степенью многословности.
3. Михаил так и не сказал, что же такое происходит с большим кодом в каком-нибудь Notepad++, озвучиваемым при помощи NVDA, что незрячий не сможет с ним работать и его спасёт только LUWRAIN, который сейчас даже текст по словам не позволяет удобно вычитать, не озвучивая CamelCase и прочее. Причём, здесь его об этом спрашивали несколько раз несколько человек.

> Прошу привести примеры сравнимых разработок в России с использованием стандартных методов доступности, которые были известны, как утверждается, уже давно.

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

Те же программы экранного доступа написаны во многом или практически полностью незрячими и представляют собой более объёмные и функционально сложные продукты, чем LUWRAIN. Разработка какой-нибудь NVDA ведётся незрячими из нескольких стран в распространённых редакторах кода и Visual Studio и сомневаюсь, что LUWRAIN убедит их на него перейти.
Да и вообще наличие инвалидности по зрению у IT-специалиста не означает, что он должен теперь работать только над проектами в области вспомогательных технологий. Я бы даже сказал, что факт его работы вне сферы вспомогательных технологий больше говорит о уровне его профессионализма.
Большая часть профессиональных незрячих программистов работают в обычных проектах по всему миру, в том числе в крупных корпорациях и в командах разработки очень крупных проектов, в том числе операционных систем.
Фактически этот тезис Михаила сводится к следующему: «покажите мне крупный проект для незрячих, разработанный русскими незрячими, или я буду считать, что незрячие, кроме меня, написавшего миллион строк в проекте LUWRAIN, сейчас ни на что не годны».
Прошу прощения, но до обсуждения таких заявлений мне опускаться бы не хотелось. Это просто даже выглядит неприлично.

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

Я не знаю, что загадочные люди скрываются под «нам», но та же NVDA представляется пока что намного более значимым в отрасли и технически сложным продуктом, чем LUWRAIN, и с его разработкой без проблем справляются исключительно незрячие, использующие стандартные графические среды.
Это не значит, что кто-то крутой специалист, а кто-то обязательно дурак, как постоянно пытается навесить ярлыки всем несогласным Михаил, но это означает, что на существующих технологиях незрячие могут делать очень сложные вещи, и это неоспоримый факт, доказываемый эмпирически последние несколько десятилетий, в течение которых развивались программы экранного доступа для графических сред.

> LUWRAIN интересно разрабатывать. Конечно! Потому что мы строим решение, исходя из тех задачь, с которыми сталкиваемся непосредственно в работе. Только ведя разработку можно точно понять, что должно быть.

Это и есть одна из главных проблем LUWRAIN. Реальных повседневных пользователей у него буквально несколько человек, да к тому же это те, кто плохо себе представляет полный ландшафт вспомогательных технологий. В этом смысле забавно читать акцентированное «мы», противопоставляемое опыту за все годы уже нескольких сотен тысяч (если не миллионов) незрячих по всему миру, работающих с другими решениями.
Простейший пример — чтение пунктуации. Обычно незрячий разово настраивает удобный ему уровень подробности чтения неалфавитных знаков.
Если всё примерять только на себя, то в продукте будет гвоздями прибит тот уровень детализации, который кажется разработчику подходящим.
Однако здесь как раз и требуется настройка, которой сам разработчик может никогда не будет пользоваться, но которая нужна остальным пользователям, чтобы настроить эту важную часть функциональности под себя.

Именно этим и объясняется, что в LUWRAIN нет кучи базовых вещей в той же навигации по простому тексту, которые нужны, чтобы разные люди могли решать актуальные для них задачи: бегло прочитывать текст или наоборот вычитывать по словам или даже буквам, править трудно выявляемые без зрения ошибки и так далее.
Вместо этого предоставляется крайне мало функциональная система доступности интерфейса, которая соответствует суженным потребностям нескольких «мы», но агрессивно позиционируемая с передёргиванием фактов как самое доступное и функциональное, что есть в индустрии.

> Тематика ресурса, к счастью, не даст никого ввести в заблуждение, что возможность написать скрипт на Python, где даже подсветка будет озвучиваться, это так же круто, как и вести масштабную разработку на Java.

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

> 1. Факты существования механизмов для создания доступа к API для людей с нарушениями зрения.

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

> 2. Факты успешных масштабных проектов, которые ведут незрячие в России с использованием тех самых давно и хорошо проработанных методов доступности.

См. выше, где я объяснил, почему привязка к российским разработкам — это спекуляция, и почему нельзя оценивать эффективность работы незрячих программистов только по проектом для незрячих, в которых они задействованы.

> 3. Желаю встретить Никиту на конференции, где он мне лично покажет, как он делает презентации в доступном офисе без посторонней помощи.

Михаил опять грубо передёргивает.
На Windows с программой экранного доступа можно сделать презентацию как в TeX, то есть точно также, как он предлагает делать внутри LUWRAIN, а также при помощи PowerPoint и ряда других решений, в том числе генерирующих слайды из абсолютно доступных для незрячих текстовых файлов с разметкой Markdown. То есть доступными являются все эти варианты, а LUWRAIN лишь обещает сделать доступным один из них.
То, что Михаил отказывается принять реальность, что незрячий может сделать презентацию в PowerPoint, делает бессмысленной весь этот спор. Человек просто не признаёт факты.

• Вот учебник по созданию презентаций в PowerPoint без зрения (специально показываю достаточно старый материал, чтобы подчеркнуть то, что это норма уже долгие годы)
• Вот ролик на YouTube, где девушка показывает азы этого процесса.

и, разумеется, в этих материалах показаны не все доступные возможности.
То, что Михаил общается с людьми, которые этого не знают и/или не понимают, лишний раз демонстрирует общую некомпетентность команды LUWRAIN и их оторванность от актуального состояния вспомогательных технологий для незрячих.
Если на конференциях никто не смог ему до сих пор это показать и объяснить, то не думаю, что вообще имеет смысл ходить на такие конференции, и уж тем более воспринимать их как источник знаний о переднем крае индустрии.
И, конечно, никто бегать за Михаилом по конференциям не собирается, только ради сомнительного удовольствия показать ему то, существование чего он намерено игнорировал все эти годы. Это позиция какого-то маленького капризного мальчика, топающего ножкой с криком «Не верю! Не верю!»

> 4. Да и про кроссплатформенность все как-то забыли. Холивар на тему Linux и Windows устраивать не будем, но мне нужны факты доступных, ну не знаю, хотя бы читалок книг в Linux.

См. на всё тот же ответ про существующие варианты поддержки API.
Если взять какой-нибудь кроссплатформенный язык программирования и wxWidgets после чего написать на нём читалку книг, то можно собрать её как приложение для Windows, Linux и macOS, доступное для существующих программ экранного доступа на всех этих системах.
Простейший пример — это звуковой редактор Audacity — обычное приложение для всех, написанное на wxWidgets, собираемое для нескольких операционных систем и являющееся доступным на всех них.
Это тот самый альтернативный путь, существование которого столь настойчиво отрицается представителями LUWRAIN.
Хорошо, пусть есть желание идти другим путём. Проблема в том, что базовой интерфейс LUWRAIN сейчас менее удобен, чем интерфейс, который можно было бы разработать на доступной технологии GUI и потом озвучить программами экранного доступа. И этот вопрос Михаил сторательно обходит, делая вид, что отсутствие базовых функций по невизуальному взаимодействию с текстом это нормально.

Ну а теперь я всё-таки вернусь к тому, с чего мы начинали.
Я ещё раз прошу предметно описать якобы существующие проблемы выделения текста в графических средах с использованием программ экранного доступа.
Михаил публично соврал в этом вопросе, а потом увёл тему в сторону. Однако я бы всё-таки хотел получить либо публичный аргументированный ответ, либо публичное признание, что он ошибся.
Я наоборот утверждаю, что удобство и функциональность работы с текстом в поле редактирования в LUWRAIN на сегодняшний день ниже, чем в каком-нибудь Блокноте Windows с программой экранного доступа. Свои аргументы я привёл в конце самого первого комментария.
Ну и я также ожидаю спокойного ответа по тем же презентациям, которые, по словам Михаила, нельзя в PowerPoint делать при помощи программ экранного доступа, но я выше показал ссылки на инструкции и прямые демонстрации, которые доказывают обратное.
Причём, убедительно прошу перестать использовать грязный полемический приём Галоп Гиша и не множить взаимные доводы, пока не будет дан ответ на предыдущие. Человек, так часто посещающий конференции и закончивший аспирантуру, всё-таки должен придерживаться стандартов академической дискуссии, а не спорить как на базаре, переходя на личности и параллельно с публичным разговором пописывая гадости на личную почту с кабатской лексикой.
Пока Михаил не выполнит обязательства добросовестного участника дискуссии и не ответит по пунктам на доводы оппонента, я не вижу смысла продолжать этот разговор. Своим поведением он лучше меня справляется с дискредитацией отстаиваемой им точки зрения.

Доступ в интернет открыт: технология LUWRAIN помогает слепым пользователям

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

Доступ в интернет открыт: технология LUWRAIN помогает слепым пользователям

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

Вы готовы здесь и сейчас также публично, как и высказали эти свои утверждения, подробно сформулировать суть проблем с выделением текста и с подготовкой презентаций вне LUWRAIN? Я знаком с обоими концами технологий (и LUWRAIN, и программы экранного доступа (разные и под разными OS)). Рассчитываю на такой же уровень дискуссии и с вашей стороны.

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

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

Доступ в интернет открыт: технология LUWRAIN помогает слепым пользователям

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

> Внизу упоминается TeX. Это в том числе и для создания презентаций.

Невизуальная доступность создания презентаций с помощью TeX является свойством TeX и распространяется на все платформы, под которые существуют утилиты работы с TeX. Соответственно то, что Михаил пытается декларировать как преимущество LUWRAIN, к заслугам LUWRAIN не имеет никакого отношения.

Незрячий человек на Windows или macOS может взять TeX, в любом текстовом редакторе при помощи любой программы экранного доступа набрать нотацию TeX и сделать себе презентацию.
То есть наличие решения через PowerPoint или Keynote — это плюс дополнительные варианты, а не что-то исключающее доступность TeX для пользователей не LUWRAIN.
Это мы ещё оставляем за скобками целый ряд небольших инструментов для вполне доступного создания презентаций, типа генерации HTML-слайдов из простых текстовых файлов с MarkDown, что намного проще TeX. То, что Михаилу где-то кто-то пожаловался на свои личные проблемы, ещё не означает, что это является нерешённой технологической проблемой всей индустрии. Большинство озвучиваемых недостатков программ экранного доступа являются пересказом каких-то сплетен некомпетентных людей.

> Современные утилиты экранного доступа могут выполнять авторазметку Daisy? Это одна из самых востребованных задач для незрячих. Как это делает LUWRAIN, Вы можете найти на нашем канале на YouTube.

Программа экранного доступа является приложением для обеспечения доступности прочих приложений. Поэтому претензии к ним, что в них нет конвертора DAISY, встроенного MP3 плеера или почтового клиента являются безграмотными. Это примерно как от драйвера для монитора требовать наличие встроенного калькулятора. Задача программы экранного доступа заключается в том, чтобы работать в фоне и озвучивать то, что происходит в графическом интерфейсе какого-то приложения общего пользования.

Корректнее ставить вопрос, что под операционную систему x не существует приложения с какой-то функциональностью, а вот внутри среды LUWRAIN такая функциональность обеспечена.

Однако это не является концептуальным преимуществом идеи LUWRAIN. То есть если бы вместо имплементации этой функциональности в LUWRAIN она была бы реализована в виде отдельного приложения, то это было бы столь же функционально. Фактически на лицо лишь синдром швейцарского ножа, когда вместо написания отдельного приложения с такой функциональностью, оно реализовано как часть какого-то более общего продукта.

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

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

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

> Как Вы создадите решение, которое интегрируется в сетевые сервисы?

Точно также, как это происходит в LUWRAIN: возьмём язык программирования (причём, не ограничиваясь Java и JavaScript) и напишем клиент для API. Этот аргумент вообще выглядит жалко.
То, что это делают для LUWRAIN, и не делают для пользователей вне LUWRAIN, не означает, что вне LUWRAIN это невозможно. Это обычно означает, что вне LUWRAIN эти задачи либо не считают важными, либо они уже имеют свои достаточно эффективные решения.
Между прочем, доступный кроссплатформенный интерфейс можно написать на целом ряде стандартных технологий GUI. Ну это так, на всякий случай, если кому-то захочется привести аргумент о кроссплатформенности LUWRAIN.

> Сравните работу с ВКонтакте, как это делаете Вы в браузере или на трубке, с тем, как это делает LUWRAIN, это тоже есть на нашем канале.

Увы, это призыв к тому, что не делает сам призывающий, а именно: он не в курсе того, как те самые проблемы решаются под Windows или macOS с их инструментами невизуального доступа.
К сожалению, большинство подобных дискуссий вокруг LUWRAIN упираются именно в том, что в этом проекте абсолютно провалена предварительная исследовательская составляющая, поэтому мы и получаем споры вокруг якобы плохой доступности чего-то, о чём разработчики LUWRAIN просто не знают.
В социальных сетях сейчас по всему миру десятки тысяч полностью незрячих людей. Через LUWRAIN там присутствует, боюсь, только один Михаил. Думаю, это о чём-то говорит. Как минимум, о том, что не всё так плохо, а может и вообще даже лучше, чем он считает.

> Как Вы будете работать в Google Docs? Через браузер?

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

> Вы программируете под Windows? Значит, в целый ряд компаний Вас на работу не возьмут. А программировать где-либо ещё Вы с большой вероятностью не можете.

Здесь просто стоит отметить то, что программировать без зрения можно на любой платформе без какого-либо привлечения LUWRAIN. Это заявление Михаила в принципе абсурдно. LUWRAIN на сегодняшний день не делает доступной какую-то новую область IT для незрячих, равно как вряд ли это сделает когда-либо в будущем, просто потому что терминал и текстовый редактор доступен везде уже сейчас, впрочем как вещи типа Emacs или различных IDE. Это просто факт, кстати, известный даже Михаилу, так что он просто лукавит.

> На Python Вы постоянно прослушиваете длину отступа? То есть Вы никогда не думали, что для невизуального редактирования работу с Python надо в каком-то виде заскриптовать?

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

> Незакрытых задач много, каждая задача в отдельности закрывается трудно, поэтому речь и идёт про конструктор, создав который один раз, мы можем развивать в самых разных направлениях.

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

• как обеспечить различаемость на слух одинаково звучащих букв, типа «М» (кириллическая) и «M» (латинская);
• как на слух узнать, что текст «GetFileSize» написан CamelCase'ом и где именно стоят большие буквы, причём, узнать это быстро в одно нажатие, а не читая всю строку по символам;
• как обеспечить улучшенную воспринимаемость на слух специфических записей, типа чисел, написанных с разделителями разрядов, когда «1 000» по умолчанию синтезатором речи читается не как «одна тысяча», а как «один ноль ноль ноль», или когда телефонный номер по умолчанию читается как сколько-то миллиардов с чем-то;
• как наиболее эффективно и гибко представить информацию о неалфавитных символах (знаки пунктуации, те же отступы в коде и др.);
• как максимально быстро донести до незрячего дополнительные метаданные о тексте, типа выделения в нём орфографических ошибок или той же подсветки синтаксиса;
• и прочее, и прочее.

Все эти проблемы были сформулированы в индустрии десятилетия назад и для них были выработаны решения.
Эти вопросы и необходимость их обсуждения поднимались несколько лет назад и в проекте LUWRAIN, однако там всё это было проигнорировано в достаточно токсичной форме.
В итоге, на сегодняшний день эти самые базовые задачи невизуальной доступности в LUWRAIN не решены, но мы продолжаем наблюдать рассуждения о специально разработанном конструкторе «супердоступных» интерфейсов.
Горькая правда заключается в том, что функциональность доступной и эффективной работы с простым текстом, набранным в редакторе, в LUWRAIN сейчас ниже, чем в каком-нибудь Блокноте Windows с параллельно запущенной программой экранного доступа, то есть специализированный интерфейс спустя 10 лет разработки всё ещё хуже, чем неспециализированный.
До недавнего времени можно было отговариваться beta-статусом LUWRAIN, но пару лет назад была выпущена официально стабильная версия 1.0, где даже просто переход по словам по CTRL+Вправо/Влево упирался в конце строк и требовал дополнительных нажатий для перехода на новую строку и стабилизации фокуса на первом слове этой строки. То есть политика разработки LUWRAIN в реальности не направлена на то, чтобы вытащить доступность интерфейса на максимальный уровень. Это просто суета в множестве разных направлений, ни одно из которых не доведено до работоспособного состояния, даже самые базовые вещи.
При этом, Михаил продолжает игнорировать необходимость повышения собственной эрудиции в подходах к решению задач невизуальной доступности. Он оперирует устаревшими концепциями и представлениями, пытаясь изобретать велосипеды и заново собирая шишки тупиковых направлений или, если повезёт, открывая Америку, например, идею браузерного омнибокса, представляя её как прорыв, который должен посрамить всех любителей программ экранного доступа, которые имели доступ к этому с самого его появления.

Увы, у LUWRAIN, безусловно, есть потенциал в ряде ниш, но я не вижу, чтобы его пытались по-настоящему раскрывать.
Пока LUWRAIN — это продукт, который наверняка очень интересно разрабатывать, но который до сих пор мало что может предложить реальным пользователям. И это спустя почти 10 лет разработки и уже при наличии официально стабильных релизов.

Подстраховка web-доступности семантических областей HTML5 через роли WAI-ARIA

> Вторая ссылка (в конце статьи) протухла.

Ссылку починил, но она там идёт на раздел большой спецификации, так что возможно не сразу очевидно. Нужен раздел «5. The Roles Model». Он тоже не маленький, так что можно по оглавлению посмотреть интересующий подраздел, если возник какой-то точечный вопрос. Конкретно роли семантических областей страницы, про которые и был этот пост, называются Landmark Roles (это раздел 5.3.4 спецификации).

> Чтобы два раза не вставать: не посоветуете ли каких-то гайдов по обеспечению accessability – хотя бы для экранных читалок.

Есть несколько источников, с которыми имеет смысл работать:

1. Web Content Accessibility Guidelines (WCAG) 2.1 — базовый стандарт от W3C. Он посвящён в основном концептуальным вопросам, то есть не освещает конкретные технические решения, а даёт понимание тех проблем, которые надо учитывать. Скорей что-то типа ориентира для формулировки ТЗ. Полезно для общего понимания проблематики web-доступности во всех аспектах.
2. Accessible Rich Internet Applications (WAI-ARIA) 1.1 — основная спецификация технологии обеспечения доступности rich internet applications от W3C. Это именно технический документ для разработчиков, описывающий то, как нужно решать задачи обеспечения web-доступности для программ чтения экрана и прочего вспомогательного ПО. Имеет смысл хотя бы раз ознакомительно пробежать весь документ, чтобы представлять набор решений и освоить его на уровне «кажется что-то про это я где-то видел», ну и потом уже прибегать к нему как к справочнику по конкретным ситуациям. Это часть целого набора спецификаций, сосредоточенная на основных проблемах, связанных с доступностью базовых элементов страницы, но в отдельных сложных случаях, типа обеспечения доступности SVG и прочего, могут понадобиться остальные документы, полный перечень которых есть на странице WAI-ARIA Overview.
3. WAI-ARIA Authoring Practices 1.1 — документ от W3C, описывающий некоторые неочевидные аспекты применения стандарта ARIA 1.1 и содержащий конкретные шаблоны проектирования интерфейса для базовых элементов. Вместо того, чтобы изобретать велосипед и пытаться имплементировать WAI-ARIA в свои кастомные элементы интерфейса, имеет смысл поискать здесь готовую реализацию.
4. Ну и конкретные задачи, типа обеспечения доступности выпадающего меню или чего-нибудь ещё, можно просто искать в Интернете с ключевыми словами, типа «web accessibility drop-down menu» или «accessible drop-down menu». В результатах, в первую очередь, стоит обращать внимание на отдельные материалы с примерами с сайтов W3C, браузеров и браузерных движков, а также крупных информационных ресурсов, типа MDN. Всякие статьи в личных блогах рейтингуйте ниже, потому что там не всё и не всегда правильно, а пока у вас не наработан опыт, вы можете это не заметить и повторить плохое решение.

> Как-то в статьях редко разбирают, что именно будет прочитано для той или иной разметки; или там чего установить, чтобы потестировать

Статьи, к сожалению, в большинстве случаев пишутся теоретиками, которые если когда-то и пробовали работать с программой чтения экрана, то, как правило, просто 5 минут и на знакомом интерфейсе, да к тому же подглядывая глазами. В итоге, они часто являются просто пересказом спецификации и не учитывают аспект нюансов разных программ чтения экрана, их версий, а также специфики сочетания браузера и screenreader'а.

В целом, тестирование web-доступности, как и везде, делится на автоматизированное и ручное.

Из автоматизированных методов можно отметить такой инструмент как Axe, который можно встроить в систему непрерывной интеграции, а также внутренние инструменты в браузерах, а именно: аудит доступности в Chrome и Инспектор доступности в Firefox.

Для ручного тестирования надо брать программу чтения экрана, осваивать принципы невизуальной работы в web, ну и проверять, насколько с сайтом вообще можно работать, получая информацию только от screenreader'а и пользуясь его способами взаимодействия со страницей. Обо всех нюансах, типа иной статистики распространённости браузеров и операционных систем, а также статистике распространённости самих программ чтения экрана на разных языковых рынках говорить очень долго. Это вряд ли формат комментария. Впрочем, и мало кто из обычных разработчиков готов будет настолько глубоко с этим связываться. Поэтому я опишу базовый вариант ручного тестирования.

Лучше всего взять Windows и установить туда бесплатную программу NVDA (есть и portable вариант запуска). По команде Insert+N или через иконку в области задач можно открыть меню программы, где, помимо прочего, будет справка и настройки. На слух понимать программу со стандартным синтезатором речи, скорей всего, будет тяжело. Поэтому можно либо поставить более качественный бесплатный синтезатор речи RHVoice (версия в виде дополнения для NVDA), либо через меню «Сервис» включить функцию «Просмоторщик речи», которая отобразит на экране область, где будут выводиться текстом все фразы программы.

Далее открываем сайт в браузере и проверяем, читается ли весь контент и элементы управления, а также осуществляется ли с ними корректное взаимодействие. Имеет смысл по CTRL+Home переместиться в начало, а потом стрелкой вниз пройтись по всей странице. Конкретно семантические области страницы можно перебрать нажатием D (сверху вниз) и Shift+D (снизу вверх). Также можно по Insert+F7 открыть диалог агрегированного отображения элементов страницы, выбрать там переключателем «Ориентиры» и в этом окне будет показано иерархическое дерево семантических областей. Подробнее обо всех командах работы в Интернете можно почитать в руководстве NVDA, доступном через меню программы.

У многих разработчиков основной системой является macOS, где есть встроенная функция чтения экрана VoiceOver. К сожалению, VoiceOver довольно слабое решение в отношении обеспечения невизуальной доступности web-контента, да к тому же с рядом крайне спорных технологических решений, ну и в англоязычной среде имеющее распространение среди реальных пользователей меньше 10%, а в русскоязычной — меньше 5%. Это одна из проблем индустрии, потому что многие разработчики если что-то руками и проверяют, то как раз на VoiceOver, ну и порой получают не лучшее качество.

Впрочем, для совсем базовых вещей VoiceOver тоже можно использовать. Он активируется по команде CMD+F5 (в зависимости от настроек клавиатуры может быть FN+CMD+F5). Настройки открываются по CMD+Option+F8. В настройках можно включить так называемую панель субтитров, которая также будет выводить фразы в виде текста на экране.

С VoiceOver имеет смысл включить быструю навигацию по одновременному нажатию стрелок вправо и влево, а потом пройтись по содержимому страницы стрелкой вправо. Отдельные блоки контента он сворачивает в условные контейнеры, которые можно открыть командой Вниз+Вправо. Элемент активируется командой Вверх+Вниз. Справку по командам можно открыть по CMD+Option+H, ну и при запуске сразу будет открыто руководство для быстрого освоения, хотя раздела по обучению web-навигации там по-моему до сих пор нет. Полный учебник по VoiceOver лежит здесь.

Это я попытался ответить на ваш вопрос кратко, так что, как видите, поднятая тема очень обширная, если краткие ответы получаются такими длинными. :-)

Для крупных проектов, конечно, нужен отдельный QA-специалист по accessibility, который способен на высоком уровне проводить ручное тестирование с учётом всей неконсистентности браузеров, программ чтения экрана и прочего, а также вырабатывать технические рекомендации и решения для обычных разработчиков, но такая практика существует даже не в каждой большой западной компании. Это порождает замкнутый круг: когда такой специалист нужен, его трудно найти, а трудно его найти, потому что массово такие специалисты невостребованы, так что мало кто пробует развиваться в эту сторону. Впрочем, это уже совсем другая история…

Доступность игр на pygame

Если вам это ещё актуально, то после некоторых исследований выяснилось, что TadsWrapper 6 для корректной работы требуется Распространяемый пакет среды выполнения Microsoft Visual C++ 2008. Упомянутая выше ошибка возникает из-за того, что по умолчанию этих библиотек в систему не установлено. Надо, конечно, побороться за автономность, но пока недостающие библиотеки можно установить вручную (32-разрядная версия и 64-разрядная версия). Для 64-разрядных систем, скорей всего, потребуется установить оба пакета.

Доступность игр на pygame

Обсудил с основным разработчиком и вроде всплыл какой-то тонкий момент с разрядностями библиотек при сборке. Уточните, на системе с какой разрядностью у вас проблемы с TadsWrapper?