[TC] Re: Национальные стандарты по доступности сайтов
Приветствую всех!
Андрей,
> Последний вроде от 19 года.
Верно, это ГОСТ Р 52872-2019.
Восприятие пользователя сайта и восприятие разработчика сайта -- это не
одно и то же, поэтому одной из задачей стандарта доступности является
сформулировать требования доступности так, чтобы их могли применять
потребители web- и иного цифрового контента и разработчики web- и
цифрового контента одновременно. Задача крайне сложная, поэтому для
понимания стандарта (и стандартов из любой области деятельности)
требуется определённый уровень знаний в предметной области.
> там в одну кучу сброшены и
> незрячие и глухие и аутисты и так далее
Ну вот: вы прекрасно поняли, что доступность сайтов это не только
проблема людей с нарушениями зрения, но и проблема людей с другими
нарушениями жизненно важных функций.По этой причине стандарт содержит
требования к содержимому сайта, чтобы это содержимое было доступно как
можно большему числу людей с различными ограничениями и / или нарушениями.
В стандарте нет явного деления требований по видам ограничений и / или
нарушений, то есть если сайт соответствует какому-нибудь из уровней (А,
АА или ААА), то он соответствует этому уровню независимо от ограничений
или нарушений жизненных функций у конкретного пользователя.
И, конечно, как сказано во введении, существуют такие ограничения или
нарушения, доступность для которых существующими техническими средствами
реализовать либо невозможно, либо возможно, но тогда поломается
доступность для других пользователей. По этой причине даже полное
соответствие наивысшему уровню ААА не даёт стопроцентной доступности для
определённых видов ограничений или нарушений.
Теперь к примерам...
> нажать ее можно только со зрением, но дальше все доступно, Можно ли
> такой сайт
> назвать доступным приемлемо?
Нельзя. Для точного тыкания пальцем в пункт ГОСТа нужно уточнить
ситуацию: зачем нужен зрячий? На кнопке нет надписи? Или кнопка не
определяется программой экранного доступа? Или кнопка не активируется с
клавиатуры, например, на неё нельзя попасть клавишей TAB и активировать
клавишей Пробел?
В зависимости от того, какая из этих проблем актуальна (или все разом),
будет нарушен тот или иной критерий выполнения в стандарте.
У каждого критерия указан уровень (А, АА или ААА), для которого он
должен обязательно выполняться.
Если нет текстовой подписи, то нарушен критерий 1.1.1:
4.1.1 Положение 1.1 Текстовая версия
Необходимо предоставить текстовую версию любого нетекстового
контента так, чтобы ее можно было преобразовать в другие формы,
необходимые пользователям, например, увеличенный шрифт, шрифт Брайля,
речь, специальные знаки или упрощенный язык.
Критерий успешного применения 1.1.1 Нетекстовый контент
(Уровень А)
Весь нетекстовый контент, представленный пользователю, имеет
эквивалентную текстовую версию, кроме описанных ниже случаев: ...
Обратите внимание, что в скобках указан уровень соответствия, для
которого этот критерий должен выполняться.
Если проблема с доступом с клавиатуры:
4.2.1 Положение 2.1 Доступность операций с клавиатуры
Вся функциональность должна быть доступна с клавиатуры.
Критерий успешного применения 2.1.1 Клавиатура
(Уровень А)
Всей функциональностью контента можно управлять с помощью
клавиатуры без каких бы то ни было ограничений по времени для отдельных
нажатий на клавиши, кроме случаев, когда вызываемая функция требует
ввода, зависящего от направления движений пользователя, а не только от
конечных точек).
Ну и так далее...
Иными словами, последовательность действий должна быть такой:
1. Вы исследуете web-страницу, работая с программой экранного доступа.
2. Находите элемент, который у вас вызывает какие-то проблемы.
3. Пытаетесь понять проблему -- это просто неудобство например, слишком
длинное название элемента) или реальная проблема доступности (приходится
прибегать к помощи зрячего). Если это всего лишь неудобство, которое не
мешает вам сделать нужное действие, то к ГОСТу это не имеет отношения
(как правило, хотя возможны исключения).
Если это реальная проблема, не позволяющая вам самостоятельно выполнить
нужное действие, то чаще всего это будет нарушением критериев ГОСТа
(одного критерия или больше). Если хотя бы один критерий
соответствующего уровня нарушен, то сайт не будет соответствовать ГОСТу
по этому уровню, причём чтобы соответствовать уровню ААА (наивысший),
сайт должен соответствовать уровням АА и А, а чтобы соответствовать
уровню АА, сайт должен соответствовать уровню А.
Иными словами, соответствие более высокому уровню означает соответствие
всем более низким уровням.
Идём дальше...
> но надо ввести капчу. Капчу можно распознать с помощью платных
сервисов, есть даже звуковая капча, но она на иностранном языке с очень
Тот же критерий 1.1.1:
- капча: если нетекстовый контент применяется с целью
подтверждения того, что контент используется человеком, а не
компьютером, то пользователю предоставляется текстовая версия, которая
определяет нетекстовый контент и описывает цель его использования, а
также для пользователей с различными видами сенсорных и физиологических
особенностей предоставляются альтернативные формы капчи, использующие
доступные для различных типов сенсорного восприятия способы
представления информации;
Поясняю: здесь "текстовая версия" -- это всего лишь описание, что, мол,
это капча, она нужна для того-то и того-то. А альтернативная форма --
это капча в других формах, доступных для пользователя (например,
аудиокапча на родном языке для людей с нарушением зрения). Хотя
текстовая капча (капча в виде текстового задания) возможна, но
разработчик сам выбирает какую альтернативную капчу предоставить:
текстовую или аудио.
Ещё хочу предостеречь от ввязывания с дискуссию с разработчиком по
поводу алгоритма реализации капчи. Часто разработчики сваливают эту
задачу на особенно активных пользователей, проявивших энтузиазм в части
требований доступности. Не поддавайтесь на эту провокацию. Разработка и
реализация алгоритма альтернативной капчи -- это прямая задача
разработчиков. Даже если готового алгоритма на сегодняшний день не
существует, это не должно быть основанием для нарушения требований
стандарта.
Далее...
> кнопок, ни ссылок, низаголовков. Есть просто текст, но при нажатии на
> то, что должно быть ссылкой все открывается и работает, но куда надо
> нажать совершенно непонятно.
Этот случай нарушает
Критерий успешного применения 4.1.2 Название, роль, значение
(Уровень А)
Для всех компонентов пользовательского интерфейса (включая, но не
ограничиваясь элементами форм, ссылками и компонентами, генерируемыми
скриптами), их название и роль могут быть программно определены;
динамические формы, характеристики и значения, которые могут быть заданы
пользователем, могут быть заданы программно; уведомления об изменениях в
этих элементах доступны в пользовательских приложениях, включая
вспомогательные технологии.
Иными словами, программа экранного доступа не может определить, какую
роль или какую функцию выполняет элемент (кнопка, ссылка, флажок и тому
подобное). Нарушение этого критерия делает сайт не соответствующим уровню А.
В общем случае, аудит сайта на выполнение требований доступности не
такая уж тривиальная работа (особенно в ручном режиме), требующая
определённых знаний и в области вспомогательных технологий, в области
разработки цифрового контента, а также усидчивости и внимательности.
Если у вас нет желания погружаться в эту рутину, то, по моему мнению,
целесообразно привлечь эксперта или экспертную организацию для
полноценного аудита сайта на выполнение требований доступности. Один из
вариантов --
АНО "Центр И2Т" -- Автономная некоммерческая организация "Центр развития
доступности "Инклюзивные информационные технологии"
http://i2tc.org/
Однако это не единственная организация подобного рода, обратитесь к
поисковикам.
Всё, рассмотренное ранее, это технические аспекты проблем доступности,
но есть ещё и юридические, хотя эти юридические напрямую влияют на
решение технических проблем.
Вы упомянули техническое задание, следовательно, заказчика и
разработчика сайта связывает договор, в котором указано это техническое
задание. Если это так, то правила проверки на соответствие требованиям
ГОСТа тоже должны быть указаны в этом договоре, если таких правил в
договоре нет, то это серьёзное упущение. И в рамках договора возникает
проблема: а судьи кто? Кого обе стороны (и заказчик, и разработчик)
готовы считать авторитетным экспертом и чьё решение готовы признать в
части соответствия или несоответствия сайта требованиям ГОСТа?
Если это вы, то проблемы нет. Ваше мнение -- истина в последней
инстанции (в рамках данного договора, конечно). Если не вы, то
разработчик может (имеет право) Не согласиться с вашими выводами, да и с
выводами любого эксперта со стороны заказчика.
Конечно, здравомыслящий разработчик сначала сопоставить предполагаемые
расходы на доработку сайта и расходы на судебное разбирательство, а
затем решит, что выгоднее и проще сделать. тем более, что приведённые
вами примеры явно нарушают конкретные критерии стандарта. Но
разработчики бывают разные и ситуации у них бывают разные...
Проблема ещё в том, что на сегодняшний день (по крайней мере у меня
такие сведения) нет официально уполномоченной государством организации
для вынесения официальных решений о соответствии сайтов требованиям
ГОСТа по доступности.
Когда-нибудь такая организация появится, но сейчас придётся искать так
называемых независимых экспертов или экспертные организации, чтобы,
например, получить более-менее независимый результат оценки сайта на
доступность. Опять же "звание независимого эксперта" не является
официальным или даже общепризнанным в отношении какого-то конкретного
человека или организации.
Сейчас, если поискать в сети, можно найти какое-то количество людей,
самопровозглашающих себя экспертами в области доступности. Не все из них
одинаково полезны...
Успехов. Анатолий.
