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