[TC] Национальные стандарты по доступности сайтов
Здравствуйте.
Подскажите те, кто разбирается в стандартах доступности сайтов для незрячих.
В техническом задании на разработку сайта написано, что он должен
соответствовать уровню (а) Приемлемый Госта от 12 года. В этом госте
написано, что если существуетболее новый стандарт, то надо
руководствоваться им. Последний вроде от 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/
Однако это не единственная организация подобного рода, обратитесь к
поисковикам.
Всё, рассмотренное ранее, это технические аспекты проблем доступности,
но есть ещё и юридические, хотя эти юридические напрямую влияют на
решение технических проблем.
Вы упомянули техническое задание, следовательно, заказчика и
разработчика сайта связывает договор, в котором указано это техническое
задание. Если это так, то правила проверки на соответствие требованиям
ГОСТа тоже должны быть указаны в этом договоре, если таких правил в
договоре нет, то это серьёзное упущение. И в рамках договора возникает
проблема: а судьи кто? Кого обе стороны (и заказчик, и разработчик)
готовы считать авторитетным экспертом и чьё решение готовы признать в
части соответствия или несоответствия сайта требованиям ГОСТа?
Если это вы, то проблемы нет. Ваше мнение -- истина в последней
инстанции (в рамках данного договора, конечно). Если не вы, то
разработчик может (имеет право) Не согласиться с вашими выводами, да и с
выводами любого эксперта со стороны заказчика.
Конечно, здравомыслящий разработчик сначала сопоставить предполагаемые
расходы на доработку сайта и расходы на судебное разбирательство, а
затем решит, что выгоднее и проще сделать. тем более, что приведённые
вами примеры явно нарушают конкретные критерии стандарта. Но
разработчики бывают разные и ситуации у них бывают разные...
Проблема ещё в том, что на сегодняшний день (по крайней мере у меня
такие сведения) нет официально уполномоченной государством организации
для вынесения официальных решений о соответствии сайтов требованиям
ГОСТа по доступности.
Когда-нибудь такая организация появится, но сейчас придётся искать так
называемых независимых экспертов или экспертные организации, чтобы,
например, получить более-менее независимый результат оценки сайта на
доступность. Опять же "звание независимого эксперта" не является
официальным или даже общепризнанным в отношении какого-то конкретного
человека или организации.
Сейчас, если поискать в сети, можно найти какое-то количество людей,
самопровозглашающих себя экспертами в области доступности. Не все из них
одинаково полезны...
Успехов. Анатолий.