Comments 11
Спасибо, отличная статья.
Юридический аспект. Неотъемлемое право доступа к информации заложено в законодательство многих стран. Например, в США и ЕС все веб-интерфейсы должны быть
доступными для людей с ограниченными возможностями. У нас это касается в основном государственных сайтов, ко всем остальным это применяется лишь в качестве
рекомендации.
Довольно спорное утверждение, на сколько я могу судить, не существует какого-то нормативного акта, который бы однозначно утверждал, что все государственные сайты должны соответствовать ГОСТу доступности с одной стороны, но с другой стороны в тексте ФЗ №181 утверждается, что инвалиду гарантируется право на получение необходимой информации, и это правило не подразумевает никаких исключений, таким образом предполагается, что абсолютно все Российские сайты должны соответствовать этому ГОСТу.
Попали в меню настройки. Скринридер зачитал правильную роль — это всплывающая кнопка. Вспоминаем, что это aria-haspopup. Эта кнопка также имеет дополнительное
состояние, она свернута, и так как это кнопка, мы можем удобно нажать на нее с помощью Enter или пробела. Нажимаем пробел:
Статус поменялся, переходим дальше.
Паттерн Menu Button Предполагает, что при нажатии этой кнопки фокус переместится на первый пункт открывшегося меню и дальше пользователь сможет перемещаться по этому меню с помощью клавиш up/down arrowkeys, но в реализации яндекса это работает совсем иначе. После того как пользователь активирует кнопку «Настройки», фокус никуда не перемещается, а остается на этой кнопке и дальше пользователю нужно догадаться, что ему следует перемещаться по пунктам menu с помощью клавиши tab. Кому-то покажется, что небольшая разница, но дело в том, что этот способ взаимодействия совершенно не очевиден для пользователя скринридера. Пользователь множество раз раньше встречал меню, он знает как нужно им пользоваться, но в данном случае яндекс изобрел свой путь и как это работает понятно далеко не сразу. Более того, в некоторых случаях это вовсе не работает. К примеру, в jaws+chrome Tab не перемещает фокус по пунктам меню, а после активации кнопки просто изменяется состояние самой кнопки, а меню открывается внизу страницы и пользователю, который этого не знает, абсолютно непонятно, где его искать. Очевидно, что сложно протестировать все возможные сочетания браузеров и скринридеров, хотя и можно попытаться, но вот именно поэтому и стоит реализовывать элементы управления следуя устоявшимся паттернам.
В данном меню есть еще одна ошибка, элемент с ролью menuitem оборачивает тег «a»:
<div role="menuitem"><a href="https://yandex.ru/tune/geo/?retpath=https%3A%2F%2Fwww.yandex.ru%2F%3Fdomredir%3D1&nosync=1" class="link i-counter-toggler i-bem link_js_inited" aria-label="Изменить город" target="_self" data-statlog="head.settings.region" data-statlog-showed="1">Изменить город</a></div>
, что приводит к эффекту, когда в одном случае скринридер называет элемент пунктом меню, в другом ссылкой, а в третьем и пунктом меню, и ссылкой одновременно. Роль menuitem нельзя использовать так, элемент управления должен быть либо ссылкой, либо пунктом меню, аналогично тому как нельзя вставлять ссылку в кнопку или checkbox в ссылку.
Довольно спорное утверждение, на сколько я могу судить, не существует какого-то нормативного акта, который бы однозначно утверждал, что все государственные сайты должны соответствовать ГОСТу доступности с одной стороны, но с другой стороны в тексте ФЗ №181 утверждается, что инвалиду гарантируется право на получение необходимой информации, и это правило не подразумевает никаких исключений, таким образом предполагается, что абсолютно все Российские сайты должны соответствовать этому ГОСТу.Согласно требованиям закона 419-ФЗ, все сайты государственных учреждений должны быть приспособлены для слепых и слабовидящих. На государственных сайтах помимо внедрения техник доступности в основную версию сайта, можно часто увидеть и специальную версию для слабовидящих (с упрощённой разметкой, настройками цвета и шрифтов).
По поводу ФЗ №181 вы абсолютно правы, но реальность такова, что процент сайтов, которые этому ГОСТу соответствуют, крайне мал, и с этим ничего не делается.
Паттерн Menu Button Предполагает, что при нажатии этой кнопки фокус переместится на первый пункт открывшегося меню и дальше пользователь сможет перемещаться по этому меню с помощью клавиш up/down arrowkeys, но в реализации яндекса это работает совсем иначе...Спасибо за фидбек. Передам коллегам из команды главной.
Согласно требованиям закона 419-ФЗ, все сайты государственных учреждений должны быть приспособлены для слепых и слабовидящих.
К сожалению, все, что мне удалось найти в 401 это:
обеспечения условий доступности для инвалидов по
зрению официальных сайтов федеральных органов государственной
власти, органов государственной власти субъектов Российской
Федерации и органов местного самоуправления в сети «Интернет»
устанавливается уполномоченным Правительством Российской Федерации
федеральным органом исполнительной власти.
А таким федеральным органом является, видимо, Министерство связи и массовых коммуникаций, которое издало два приказа на эту тему, один из которых вообще не упоминает Гост, а другой просто "рекомендует" ему соответствовать.
По поводу ФЗ №181 вы абсолютно правы, но реальность такова, что процент сайтов, которые этому ГОСТу соответствуют, крайне мал, и с этим ничего не делается.
В основном да, но если пользователь пожалуется на какую-то компанию в прокуратуру, то она подаст на эту компанию в суд, требуя привести сайт в соответствие стандарту, и, как показывает практика, этот суд выиграет.
Здравствуйте! Меня зовут Вадим. Я незрячий пользователь инструментов от яндекса. Пару недель назад я установил на свой андроид смартфон приложение яндекс.почта, и через 5 минут его удалил, потому что оно совершенно не оптимизировано под доступность для скринридеров. В связи с чем очень я бы вас просил прочитать вашу лекцию подразделению мобильной разработки вашей компании. Спасибо!
P.S. Очень жаль, что вы вряд ли имеете доступ к разработчикам mail.ru group. А то официальное приложение вконтакте для андроида и клиент mail.ru также недоступны/не удобны/совершенно не оптимизированы. Если честно, стыдно даже. Такие большие компании и совершенно не парятся по поводу таких элементарных вещей, как, например, информативный тег alt на веб-страницах, и подписание графических кнопок в приложениях…
P.P.S. Веб версия яндекс.почты вполне доступна, спасибо! Но пользоваться ей с помощью скринридера все равно не слишком удобно, т.к. она совершенно не размечена заголовками, графическими элементами или еще хоть чем-нибудь и представляет собой, по сути, сплошной поток ссылок, что совершенно неудобно.
P.S. Очень жаль, что вы вряд ли имеете доступ к разработчикам mail.ru group. А то официальное приложение вконтакте для андроида и клиент mail.ru также недоступны/не удобны/совершенно не оптимизированы. Если честно, стыдно даже. Такие большие компании и совершенно не парятся по поводу таких элементарных вещей, как, например, информативный тег alt на веб-страницах, и подписание графических кнопок в приложениях…
P.P.S. Веб версия яндекс.почты вполне доступна, спасибо! Но пользоваться ей с помощью скринридера все равно не слишком удобно, т.к. она совершенно не размечена заголовками, графическими элементами или еще хоть чем-нибудь и представляет собой, по сути, сплошной поток ссылок, что совершенно неудобно.
Часто заказчик уже обладает нарушением цветовосприятия, так что уже заложено на стадии макета
Было бы неплохо, если бы Яндекс следовал этим рекомендациям.
Некоторые продукты Яндекса просто ужасны с точки зрения доступности.
Web-версия Диска — яркий пример того, как не нужно делать. Множество кастомных элементов управления, которые воспринимаются скринридерами просто в качестве текста. И хоть интуитивно понятно, что они кликабельные, но добавление role=«link», или role=«button» значительно упростило бы пользование. И это только один пример.
Или, скажем, yandex.passport, выпадающий список с месяцами во время регистрации. Из под Jaws он не работает совершенно. Из под NVDA с ним можно справиться, но только в режиме плоского просмотра, что не всегда (не всем) очевидно.
Вы пишете, что картинки должны сопровождаться альтернативным текстом, грубо говоря иметь осмысленный атрибут alt, но даже в этой статье не одна картинка не имеет описания.
Хотя, справедливости ради, хочу отметить, что вопреки распостранённому мнению, не каждая картинка должна иметь описание.
Если то, что изображено на картинке можно понять исходя из контекста и это нельзя (нецелесообразно) конкретизировать при помощи описания, то и вставлять простыню пространного текста в alt не нужно. Ибо только время отнимет у читающего. Но при этом, картинка всё равно должна иметь непустой атрибут alt. Т.к. скринридеры игнорируют такие изображения. И пользователь может даже не узнать что там есть картинка. В противном же случае, он может попросить описать изображение зрячего человека.
Честно говоря, этой рекомендации совершенно не понял. Если этот элемент имеет какое-либо значение для пользователя, то скрывать его не нужно, даже если он представлен в виде картинки.
Что касается атрибута aria-hidden. Его упоминают почти во всех рекомендациях по доступности. Но как разработчик и постоянный пользователь скринридеров, хочу отметить, что очень часто его применяют неправильно. Более того, в подавляющем большинстве случаев, его применение избыточно.
Классический пример неправильного применения:
Есть изначально скрытый блок, который необходимо показать в ответ на какое-либо действие пользователя.
Свойство display изменяют, скажем, на block, но об aria-hidden совершенно забывают. После чего мы получаем, что блок визуально отображается, но остаётся недоступным для скринридеров.
В данном случае aria-hidden является избыточным. Все скринридеры вполне успешно умеют не читать элементы с display: none. одновременное использование display: none и aria-hidden=«true» — просто ещё одна возможность накосячить на ровном месте.
aria-hidden стоит применять только в случае, если вам необходимо сохранить визуальную видимость элемента, но сделать его нечитабельным для скринридеров. В прочем, такая необходимость встречается не так уж и часто.
Использование дополнительной текстовой информации для элементов при помощи aria-label или aria-description тоже должно рассматриваться в каждом конкретном случае отдельно. Иногда это может лишь усложнить взаимодействие пользователя с интерфейсом.
Мы все не любим раздутые визуальные интерфейсы, но многие считают что напихать кучу дополнительной информации через те же aria-атрибуты — не будет лишним.
Отсутствие зрения !== отсутствию интеллекта. Во всяком случае, не всегда)))
Если предназначение кнопки понятно из самой подписи на кнопке, то любая дополнительная информация будет лишней.
У нас есть некая кнопка по нажатию на которую должен выпадать некий список:
Скринридер на этой кнопке нам прочитает что-то вроде: actions кнопочное меню свёрнуто (произносимая информация может несколько отличаться у разных скринридеров).
Добавим aria-label:
Теперь получаем: какой-то текст кнопочное меню свёрнуто.
Проверялось в NVDA, Jaws и TalkBack.
Прошу заметить, что при использовании aria-label в данном случае текст, который расположен между открывающим и закрывающим тегами button вообще игнорируется.
Но когда это может быть полезным?
Например, если в кнопке используется какая-то векторная иконка и отсутствует текстовая подпись, но мы хотим указать на предназначение кнопки.
Тут уже писали об интерфейсе почты. Кстати, облегчённая версия web-версии почты — сделана просто идеально с точки зрения доступности. И этот тот редкий случай, когда aria-label применялся правильно и в тему.
Ну и несколько рекомендаций.
Некоторые продукты Яндекса просто ужасны с точки зрения доступности.
Web-версия Диска — яркий пример того, как не нужно делать. Множество кастомных элементов управления, которые воспринимаются скринридерами просто в качестве текста. И хоть интуитивно понятно, что они кликабельные, но добавление role=«link», или role=«button» значительно упростило бы пользование. И это только один пример.
Или, скажем, yandex.passport, выпадающий список с месяцами во время регистрации. Из под Jaws он не работает совершенно. Из под NVDA с ним можно справиться, но только в режиме плоского просмотра, что не всегда (не всем) очевидно.
Вы пишете, что картинки должны сопровождаться альтернативным текстом, грубо говоря иметь осмысленный атрибут alt, но даже в этой статье не одна картинка не имеет описания.
Хотя, справедливости ради, хочу отметить, что вопреки распостранённому мнению, не каждая картинка должна иметь описание.
Если то, что изображено на картинке можно понять исходя из контекста и это нельзя (нецелесообразно) конкретизировать при помощи описания, то и вставлять простыню пространного текста в alt не нужно. Ибо только время отнимет у читающего. Но при этом, картинка всё равно должна иметь непустой атрибут alt. Т.к. скринридеры игнорируют такие изображения. И пользователь может даже не узнать что там есть картинка. В противном же случае, он может попросить описать изображение зрячего человека.
Если какой-то дополнительный элемент на вашей странице представлен в виде изображения, то его необходимо скрыть от скринридера с помощью атрибута aria-hidden=“true”.
Честно говоря, этой рекомендации совершенно не понял. Если этот элемент имеет какое-либо значение для пользователя, то скрывать его не нужно, даже если он представлен в виде картинки.
Что касается атрибута aria-hidden. Его упоминают почти во всех рекомендациях по доступности. Но как разработчик и постоянный пользователь скринридеров, хочу отметить, что очень часто его применяют неправильно. Более того, в подавляющем большинстве случаев, его применение избыточно.
Классический пример неправильного применения:
Есть изначально скрытый блок, который необходимо показать в ответ на какое-либо действие пользователя.
[div style="display: none;" aria-hidden="true"]...[/div]
Свойство display изменяют, скажем, на block, но об aria-hidden совершенно забывают. После чего мы получаем, что блок визуально отображается, но остаётся недоступным для скринридеров.
В данном случае aria-hidden является избыточным. Все скринридеры вполне успешно умеют не читать элементы с display: none. одновременное использование display: none и aria-hidden=«true» — просто ещё одна возможность накосячить на ровном месте.
aria-hidden стоит применять только в случае, если вам необходимо сохранить визуальную видимость элемента, но сделать его нечитабельным для скринридеров. В прочем, такая необходимость встречается не так уж и часто.
Использование дополнительной текстовой информации для элементов при помощи aria-label или aria-description тоже должно рассматриваться в каждом конкретном случае отдельно. Иногда это может лишь усложнить взаимодействие пользователя с интерфейсом.
Мы все не любим раздутые визуальные интерфейсы, но многие считают что напихать кучу дополнительной информации через те же aria-атрибуты — не будет лишним.
Отсутствие зрения !== отсутствию интеллекта. Во всяком случае, не всегда)))
Если предназначение кнопки понятно из самой подписи на кнопке, то любая дополнительная информация будет лишней.
У нас есть некая кнопка по нажатию на которую должен выпадать некий список:
[button type="button" aria-haspopup="true" aria-expanded="false"]Actions[/button]
Скринридер на этой кнопке нам прочитает что-то вроде: actions кнопочное меню свёрнуто (произносимая информация может несколько отличаться у разных скринридеров).
Добавим aria-label:
[button type="button" aria-haspopup="true" aria-expanded="false" aria-label="Какой-то текст"]Actions[/button]
Теперь получаем: какой-то текст кнопочное меню свёрнуто.
Проверялось в NVDA, Jaws и TalkBack.
Прошу заметить, что при использовании aria-label в данном случае текст, который расположен между открывающим и закрывающим тегами button вообще игнорируется.
Но когда это может быть полезным?
Например, если в кнопке используется какая-то векторная иконка и отсутствует текстовая подпись, но мы хотим указать на предназначение кнопки.
Тут уже писали об интерфейсе почты. Кстати, облегчённая версия web-версии почты — сделана просто идеально с точки зрения доступности. И этот тот редкий случай, когда aria-label применялся правильно и в тему.
Ну и несколько рекомендаций.
- Необходимо продумывать реализацию доступности точно так же, как вы продумываете визуальный интерфейс.
- Избыток иногда хуже недостачи
- Невозможно сделать интерфейс максимально привлекательным с точки зрения доступности без реального опыта в этом деле и/или хорошего тестирования только на основе каких-то рекомендаций.
П.С. парсер режет теги, не Так и не смог написать правильно.
Отличная лекция и плохая расшифровка :(
Самое плохое — слайды с текстом и кодом картинками. Это противоречит почти всему, чему учит лекция. Как так? Ну и убрать из текста контекст ШРИ, сделать его полноценным и независимым тоже несложно, но это скорее про редактирование.
Спасибо за статью!
Скажу прямо, к вопросам доступности я отношусь пока довольно скептически. Складывается впечатление, что это скорее веяние моды, чем реальное понимание необходимости. "Так надо", "Это хорошие практики", "Все так делают". К тому же, часто люди, ратующие за доступность, сами мало чего в ней понимают (камень не в автора статьи). Больше того, не ясно, как без реальных устройств и тестов проверить эту самую доступность. Я много слышу от разработчиков рассуждений о доступности, однако ни бизнес, ни аналитика, ни тестирование никоим образом в этих терминах не рассуждают, ни денег, ни времени на это не выделяется.
И отдельно хочется уточнить статистику. Есть ли данные, сколько из тех 10% населения России являются постоянными пользователями интернета?
Sign up to leave a comment.
Доступность интерфейсов. Лекция Яндекса