Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Добавлю, если контент сайта создается динамически, то редко делают подписи для скринридеров на эти элементы. Поэтому трудно узнать о том, что что-либо изменилось на странице. Чтобы этого не было можно сделать примерно так
Тогда, когда контент изменится, то скринридеры его прочитают автоматически.
<div aria-live="polite"></div>
Тогда, когда контент изменится, то скринридеры его прочитают автоматически.
Их надо применять с умом. На одно проекте внедрили кучу слайдеров с авто прокруткой сделанных на основе Tiny Slider. Каждую прокрутку этот слайдер анонсирует через
aria-live="polite" (Slide 1 of 5). В итоге при открытии страницы в скринридер сразу выдавал словесный понос который трудно отключить.
Интересно было бы почитать про сущетвующие инструменты автоматических проверок доступности сайтов.
Типа как react-a11y
Типа как react-a11y
Забавно, я в полной мере согласился бы только с 3 пунктом. Правильные заголовки действительно очень помогают при навигации. А по остальным…
1. Это по-моему вообще слабо относится к скринридерам. По плохо подписанной кнопке или ссылке вроде бы всем сложно будет навигировать. Тут чаще проблема в другом — когда кнопку или ссылку делают не используя соответствующие теги html, заменяя их css и js. Вот тогда, да, скринридер их вообще не распознает и объявит, как обычный текст.
2. По-моему вообще не надо тратить время на атрибуты alt, если это не графическое отображение какого-нибудь элемента взаимодействия (кнопки, ссылки, галочки вкл/выкл и т.д.). Например, на одном из моих проектов статусы заявок выводились картинками. Вот тут, да, тег alt обязателен. А во всяких статьях, новостях и т.д — нет. Во-первых тот же google chrome самостоятельно распознает текст на картинках, к тому же их можно прогнать через специальные сервисы где ии их вполне адекватно опишет. Не хуже, чем это будет сделано в alt.
4. С плохо доступными формами сталкиваюсь редко. И чаще вопрос тут в навешанных на них js действиях, меняющих содержимое страницы на onChange onKeyUp и т.д. Что выкидывает с них фокус скринридера. Капчи сейчас вполне нормально решаются через специальные сервисы. Да, иногда приходится обращаться ко зрячим, но очень редко.
5. Это для всех неприятно, но для незрячих — несмертельно. В конце концов можно во вкладке звук отключить.
1. Это по-моему вообще слабо относится к скринридерам. По плохо подписанной кнопке или ссылке вроде бы всем сложно будет навигировать. Тут чаще проблема в другом — когда кнопку или ссылку делают не используя соответствующие теги html, заменяя их css и js. Вот тогда, да, скринридер их вообще не распознает и объявит, как обычный текст.
2. По-моему вообще не надо тратить время на атрибуты alt, если это не графическое отображение какого-нибудь элемента взаимодействия (кнопки, ссылки, галочки вкл/выкл и т.д.). Например, на одном из моих проектов статусы заявок выводились картинками. Вот тут, да, тег alt обязателен. А во всяких статьях, новостях и т.д — нет. Во-первых тот же google chrome самостоятельно распознает текст на картинках, к тому же их можно прогнать через специальные сервисы где ии их вполне адекватно опишет. Не хуже, чем это будет сделано в alt.
4. С плохо доступными формами сталкиваюсь редко. И чаще вопрос тут в навешанных на них js действиях, меняющих содержимое страницы на onChange onKeyUp и т.д. Что выкидывает с них фокус скринридера. Капчи сейчас вполне нормально решаются через специальные сервисы. Да, иногда приходится обращаться ко зрячим, но очень редко.
5. Это для всех неприятно, но для незрячих — несмертельно. В конце концов можно во вкладке звук отключить.
По плохо подписанной кнопке или ссылке вроде бы всем сложно будет навигировать.Внутри кнопок очень часто есть иконка, по которой обычный пользователь может понять её назначение. Но не скринридер.
По-моему вообще не надо тратить время на атрибуты alt, если это не графическое отображение какого-нибудь элемента взаимодействияБез
alt-а скринридер будет читать src атрибут картинки. Альт как минимум должен присутствовать (хотя бы пустой). Для контентнтых картинок в нём должно быть описание картинки. Если картинка находится внутри интерактивного элемента, у которого нет текcтового описания, аlt тоже нужен. Для «декоративных» картинок можно добавить role="presetntation" либо aria-hidden="true". Либо вообще вставлять их через CSS background-image.С плохо доступными формами сталкиваюсь редко.Плейсхолдеры вместо лейблов повсеместны. Например поиск на хабре так сделан.
Сталкивался как-то на одной из работ с поддержкой рабочих мест слабовидящих.
И в частности сайтов скажу следующее:
Идеально: там где планируется частое посещение слабовидящими — просто делать отдельную облегченную версию с высокой контрастностью и стандартной версткой под 1280х1024, тогда и видиться будет нормально и синтезаторами речи распознаваться. Бо обычные нынешние сайты для них, да, мрак
И в частности сайтов скажу следующее:
Идеально: там где планируется частое посещение слабовидящими — просто делать отдельную облегченную версию с высокой контрастностью и стандартной версткой под 1280х1024, тогда и видиться будет нормально и синтезаторами речи распознаваться. Бо обычные нынешние сайты для них, да, мрак
тогда и видиться будет нормально и синтезаторами речи распознаваться
Так ведь синтезаторы речи не занимаются распознованием с экрана.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
5 самых неприятных фич для слепого человека на сайтах