Государственный сайт, доступный для людей с ограниченными возможностями (чек-лист доступности) / Комментарии / Хабр

Tseikovets 11 ноя 2016 в 16:13

«Требования по доступности сайта определяются стандартом WCAG уровня AA. Стандарт довольно подробно описывает все требования, содержит ссылки на разъяснения, используемые техники и часто встречающиеся ошибки. Это позволяет полностью опираться на него при анализе доступности веб-страниц и их адаптации.»

Это не совсем верно. Есть стандарт WCAG 2.0, внутри которого существует три уровня соответствия: A — низший, AA — средний и AAA — наивысший. То есть некорректно говорить, что «Требования по доступности сайта определяются стандартом WCAG уровня AA». Для разных проектов может быть разный уровень по WCAG'у.

Ну и с полной опорой на WCAG вы погорячились. Та же семантическая разметка им не регламентируется, так как появилась позже, чем сам этот стандарт. То есть не стоит надеется, что WCAG ответит на все вопросы, особенно для разработчиков, так как он скорей менеджерский документ и позволяет написать ТЗ, а вот конкретные методы реализации в нём практически не описаны.
Сейчас, кстати, идёт разработка WCAG 2.1 как переходного документа, а также обсуждение нового WCAG 3.0.

«Также широко распространен JAWS (программа платная и дорогая, но поставляется в триал-версии с 40-минутным режимом).»

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

При серьёзном подходе с JAWS тестирование обязательно, так как там есть своя специфика. Более того, существует специфика работы одной и той же программы чтения экрана в разных браузерах, так что фактически FF+IE и NVDA+JAWS дают 4 обязательные для тестирования пользовательские конфигурации, являющиеся наиболее распространёнными.
В обозримом будущем надо будет подтягивать уже и Edge, где доступность была переработана с нуля. NVDA он уже поддерживается, а JAWS должен начать поддерживаться примерно в декабре 2016 года. Если в команде перфекционист, то тестирование в браузерах на базе Chromium тоже лишним не будет, хотя тут их поддержка не равномерна и имеет уклон в сторону экранных чтецов NVDA и Window-Eyes.
Впрочем, настолько глубокое тестирование оправдано именно для тех проектов, где доступность строго прописана в ТЗ, и они являются системообразующими, типа сайта госуслуг. Для домашних проектов и поддержки доступности на базовом уровне NVDA для тестирования должно хватить. К тому же обычный разработчик всё равно вряд ли сможет сделать глубокое тестирование, так как для этого должен быть специальный QA-инженер accessibility.

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