Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Спасибо, было очень интересно про это почитать.
Добавьте возможность сделать пожертвование с помощью карточки/электронных денег, а не только квитанции.
Добавьте возможность сделать пожертвование с помощью карточки/электронных денег, а не только квитанции.
Вам спасибо! Делайте доступные сайты;)
Про пожертвования: это требует определенных организационных действий со стороны СВЕТ'а, к которым они не совсем готовы, в силу своего повышенного консерватизма. Может быть в следующем году они созреют и до приема платежей яндекс.деньгами и карточками. Технически-то всего лишь галочку в админке лейки поставить.
Про пожертвования: это требует определенных организационных действий со стороны СВЕТ'а, к которым они не совсем готовы, в силу своего повышенного консерватизма. Может быть в следующем году они созреют и до приема платежей яндекс.деньгами и карточками. Технически-то всего лишь галочку в админке лейки поставить.
Правильную тему затронули!
Вот бы еще какую-нибудь краткую версию документации WCAG20 чтобы веб-разработчики хотя бы минимально уделяли время тому чтобы сделать свои сайты еще доступнее и проще для всех.
Вот бы еще какую-нибудь краткую версию документации WCAG20 чтобы веб-разработчики хотя бы минимально уделяли время тому чтобы сделать свои сайты еще доступнее и проще для всех.
К слову, самый крутой русскоязычный синтезатор голоса RHVoice пишет слепая девушка Ольга Яковлева.
Добавлю ссылок:
1. Cайт Алексея Владимировича, эксперта, который помогал нам с тестированием — fitisov.cfspb.org/
2. Профиль Анны Ладошкиной на гитхабе — github.com/foralien
3. ИТВ — место, где десятки подобных некоммерческих задач ждут вас: https://itv.te-st.ru/
1. Cайт Алексея Владимировича, эксперта, который помогал нам с тестированием — fitisov.cfspb.org/
2. Профиль Анны Ладошкиной на гитхабе — github.com/foralien
3. ИТВ — место, где десятки подобных некоммерческих задач ждут вас: https://itv.te-st.ru/
А почему у «эксперта» Алексея Владимировича сайт свёрстан без элементарных заголовков? Заголовки — это более приоритетное требование, чем семантические области.
Алексей Владимирович не является веб-разработчиком — сайт ему помог сделать его друг (тоже не веб-разработчик). Ему всё (более-менее) нравится, возможно потому, что он ээээ видит этот сайт несколько иначе чем вы. Если вы предложите свою помощь в переделке в соответствии со всеми стандартами — это будет просто отлично.
Извините, но у вас какая-то каша в голове по поводу web accessibility:
В общем хорошо, честь интерес к web accessibility, но вы явно подошли с какого-то не того конца.
- Насколько мне известно, в РФ около 280 тыс. тотально слепых, около 600 тыс. так называемых слабовидящих, то есть инвалидов с остаточным зрением, а те или иные нарушения зрения разной степени критичности имеются примерно у 10 млн россиян. Но вот сколько из них ходит в Интернет — это очень спорный вопрос.
- WCAG — это в большей степени менеджерский документ и технологам он даёт крайне мало. То есть как именно сверстать доступную страницу из WCAG почерпнуть не получится. Технологам надо читать WAI-ARIA, но многие вещи в web accessibility формализовать практически невозможно, поэтому в идеале нужен ещё грамотный QA-инженер accessibility. Причём далеко не каждый слепой может быть хорошим QA-инженером, хотя обычно предпочитают просто брать первого попавшегося слепого пользователя из какой-нибудь общественной организации инвалидов, в итоге, результат соответствующий.
- Автоматическая проверка web accessibility помогает отловить совсем базовые проблемы, типа отсутствующего alt-текста, необходимость которого вообще предполагается даже по стандартам общей валидации W3C. По-настоящему проверить accessibility можно только функциональным ручным тестированием, который должен делать грамотный специалист, способный проверить структуру страницы, доступность по базовым пользовательским сценариям и дать конкретные технические рекомендации, а не просто отзывы, типа «здесь работает, а здесь не работает».
- Обычный сайт не читается как каша. У программ чтения экрана есть ряд функций для того, чтобы обеспечить относительно приемлемую степень удобства навигации даже по совсем неподготовленной странице. Криминал — это полная вёрстка в flash, развесистые Rich Internat Applications и прочие вещи. Но чтобы сделать совсем или практически недоступный сайт, надо постараться.
- Если текст не размечен заголовками — это, конечно, плохо, но его можно читать итак, а также перемещаться по нему и экранный чтец не будет выхватывать отдельные слова. Это какая-то глупость.
- Принципиально экранные чтецы читают сайт практически одинаково. Есть всего два основных концептуальных подхода: документоподобное представление web-контента и объектное. Объектное представление характерно для мобильных платформ и OS X, а документоподобное для всех остальных, в том числе JAWS и NVDA на Windows или Orca на *nix.
- Повторяющийся контент в верхней части страницы основными экранными чтецами пропускается, так что это надуманная проблема. Кроме того, концепция шапки, бокового меню, основной части страницы и для незрячих также существует, просто немного в другом виде. Это реализуется через специальные роли WAI-ARIA. В WCAG, разумеется, это не описано, поэтому и надо использовать техническую, а не менеджерскую документацию.
- Проблема со ссылками в новом окне надумана. Программы экранного доступа, как правило, сообщают об открытии страницы в новом окне или вкладке.
- При загрузке новой страницы сразу читается её заголовок, поэтому если 404 написано прямо в title, то пользователь сразу понимает, что произошло. Первый раз слышу, что страницы 404 являются какой-то проблемой в контексте web accessibility.
- С разделами в разработке вообще не понял, в чём вы видите проблему. Если у вас грамотно размечена страница и пользователь без проблем понимает, где её основная часть, а в этой основной части написано, что раздел в разработке, то никаких проблем нет. Если же у вас на странице явно не указано, что раздел в разработке, то и зрячий останется в непонятках, что это у вас такое.
- Про браузеры лучше так не говорить. Ситуация намного сложнее и не так однозначна.
- "…им наоборот — лучше оставить все как было иначе потеряешься и ничего не поймешь и будешь слушать свой скринридер по 10 раз пока въедешь", «На вещи, которые нам кажутся простыми (дело пары секунд — нашел кликнул) могут уходить минуты» — многие незрячие пользователи вас бы разорвали за эти фразы. Краски сгущены и явно проблема качества внешней экспертизы, так как «эксперты», судя по всему, экстраполируют свой личный опыт и проблемы на всё сообщество пользователей этой категории. Такие проблемы, действительно, от части есть, но не повсеместно и не в отношении абсолютно всех задач.
- В Facebook есть своя команда accessibility, в отличии от тех же VK или Одноклассников. Хотя пару лет назад Одноклассники рапортовали о поддержке web accessibility, которую вроде как разрабатывали совместно с «экспертами» из общественных организаций инвалидов. Однако там в принципе многое изначально было сделано неправильно, к тому же в течение пары месяцев всё обратно поломали, а в официальном блоге Mail.ru на Хабре ребята предпочли в своё время замять эту тему, когда им был задан вопрос. Так что с доступностью социальных сетей как раз всё диаметрально противоположно — западные лучше.
- «Пишите альт текст к картинкам!» — при этом вы сами не сделали это для картинки, которую вставили в этой статье. ;-)
В общем хорошо, честь интерес к web accessibility, но вы явно подошли с какого-то не того конца.
- Читайте WAI-ARIA, а не WCAG. Также в контексте вашего проекта имеет смысл ознакомиться с документами «Media Accessibility User Requirements» и «Web Video Text Tracks Format». В последнем даже есть встроенный инструментарий прямо для аудио дискрипции видео контента, правда пока всё это не в статусе рекомендованных стандартов.
- При вёрстке сосредоточьтесь на структурном и семантическом каркасах страницы, то есть структура — заголовки, списки, таблицы, а семантика — роли ARIA.
- RIA проверяйте особенно тщательно, и если ручное функциональное тестирование выявляет проблемы, то по стандарту WAI-ARIA программируйте состояния и свойства для элементов управления, либо заменяйте на стандартные контролы.
- Обеспечивайте полную клавиатурную навигацию по интерфейсу. Для этого используется tabindex.
- Подпись графических элементов подразумевается обычной спецификацией HTML, поэтому это просто то, что должны знать абсолютно все и не допускать таких ошибок даже без валидаторов.
- Избегайте фреймов. Максимум допустим iframe для не основного контента.
- Привлекайте QA-инженеров accessibility, которые способны как изначально подсказать пути реализации, так потом и провести итеративное тестирование и доработку.
А есть какие-то способы понять, что пришёл пользователь, основным инструментом которого будут не глаза? Прежде всего — чтобы понять, какую долю посетителей сайта они вообще составляют.
А то получится, что стараешься, делаешь всё как надо, а пользоваться-то этим некому.
А то получится, что стараешься, делаешь всё как надо, а пользоваться-то этим некому.
Нет, хотя в индустрии периодически поднимается этот вопрос. Тем не менее, это примерно то же самое, что получение информации о национальности, расе или сексуальной ориентации посетителя сайта, то есть вопрос этики стоит в полный рост.
Но у меня есть встречный вопрос: допустим вы получили такую возможность, например, в виде настройки браузера, которая начинает передавать эту информацию в запросах. Какое количество (абсолютное или относительное) пользователей вспомогательных технологий вы будите игнорировать, а после какого начнёте чесаться? А главное, как вы будите чувствовать себя с моральной точки зрения, если будите точно знать, что какое-то число пользователей, которое не вписывается в ваш порог рентабельности, заставляете мучиться? К тому же если в этом месяце не было ни одного слепого посетителя, то это ещё не означает, что в следующем месяце их не будет 100 штук.
Добровольное внедрение accessibility — это вопрос социальной ответственности. У вас есть конкретный числовой порог, после которого у вас включается эта самая ответственность?
Ну и всё это не говоря о проектах, для которых accessibility может являться либо обязательным требованием, либо конкурентным преимуществом.
Но у меня есть встречный вопрос: допустим вы получили такую возможность, например, в виде настройки браузера, которая начинает передавать эту информацию в запросах. Какое количество (абсолютное или относительное) пользователей вспомогательных технологий вы будите игнорировать, а после какого начнёте чесаться? А главное, как вы будите чувствовать себя с моральной точки зрения, если будите точно знать, что какое-то число пользователей, которое не вписывается в ваш порог рентабельности, заставляете мучиться? К тому же если в этом месяце не было ни одного слепого посетителя, то это ещё не означает, что в следующем месяце их не будет 100 штук.
Добровольное внедрение accessibility — это вопрос социальной ответственности. У вас есть конкретный числовой порог, после которого у вас включается эта самая ответственность?
Ну и всё это не говоря о проектах, для которых accessibility может являться либо обязательным требованием, либо конкурентным преимуществом.
Мне бы даже одного такого пользователя хватило, чтобы понять, что усилия приложены не зря. А где один, там и другие появятся. Тем более я некоторые шаги по оптимизации сайта сделал.
Вообще думаю, что доступность сайта сравнима с локализацией: если на начальном этапе это закладывать, то всё будет легко реализовываться. Насколько я понимаю, главная проблема сейчас в том, что нет чёткого описания, кто и где писать, есть только общие рекомендации.
Вообще думаю, что доступность сайта сравнима с локализацией: если на начальном этапе это закладывать, то всё будет легко реализовываться. Насколько я понимаю, главная проблема сейчас в том, что нет чёткого описания, кто и где писать, есть только общие рекомендации.
На мой взгляд, обеспечение accessibility даже проще локализации, потому что поддержание её намного менее трудозатратно, тогда как переводы надо постоянно актуализировать при развитии проекта. За accessibility, конечно, тоже надо приглядывать, чтобы не поломать, но тут речь точно не идёт об умножении работы на число языков.
С чёткими рекомендациями, действительно, есть проблемы, хотя чтение WAI-ARIA может снять многие вопросы. Фокус в том, что с определённого момента речь идёт не столько о доступности интерфейса, сколько о его удобстве и невизуальном дизайне, а это уже творческий вопрос. Мы же не говорим, что вместо юзабелиста и дизайнера визуальных интерфейсов нам нужен список точных рекомендаций.
Однако в самом базовом виде всё сводится примерно к следующему:
Если достаточно добросовестно соблюсти эти базовые вещи, то вашим интерфейсом вполне сможет пользоваться незрячий без особой фрустрации. Они-то, откровенно говоря, не избалованы вылизанными в отношении accessibility интерфейсами, так что с мелкими недостатками вполне готовы мериться.
Если же у вас развесистый Rich Internet Application с кучей JavaScript, динамики через Ajax и прочих выкрутасов, то accessibility тут уже надо поднимать с ручным тестированием через реальные экранные чтецы, причём под несколькими конфигурациями. Здесь без опытного QA-инженера accessibility обойтись будет трудно. Да и если стоит задача вылизать доступность, то, боюсь, без специалиста, понимающего специфику разных чтецов на разных платформах и способного протестировать и подсказать конкретные технические решения, это нереально.
Отдельная история — разруливание конфликтов невизуального и визуального дизайна. Например, надо бы поставить заголовок в начале раздела, но графический дизайнер хватает за руки и рыдает, прося не писать лишних букв. Тогда ставим заголовок, но средствами позиционирования выносим его за видимую часть страницы. После этого, визуально его не видно, но программами экранного доступа он без проблем читается. Но подобные лайфхаки в проект обычно тоже приносит опытный QA-инженер accessibility.
С чёткими рекомендациями, действительно, есть проблемы, хотя чтение WAI-ARIA может снять многие вопросы. Фокус в том, что с определённого момента речь идёт не столько о доступности интерфейса, сколько о его удобстве и невизуальном дизайне, а это уже творческий вопрос. Мы же не говорим, что вместо юзабелиста и дизайнера визуальных интерфейсов нам нужен список точных рекомендаций.
Однако в самом базовом виде всё сводится примерно к следующему:
- Строим семантический каркас, то есть весь контент страницы покрываем ключевыми областями посредством назначения их блокам ролей ARIA. Это как раз даёт незрячему понимание того, где верхний колон-титул, где боковое меню, где основная часть, где нижний колон-титул. В семантические зоны верхнего уровня можно вкладывать другие, например, основную часть страницы блога разбить на область поста и область тегов. Атрибутом aria-label можно подписывать области, например, если есть несколько навигационных меню с ролью navigation, то через aria-label лучше пояснить, чем они отличаются, типа «Разделы сайта» и «Рубрики блога».
- Все ключевые разделы страницы озаглавить HTML-заголовками. Причём заголовок надо вносить под семантическую область (у авторов сайта, которому посвящена эта статья на Хабре, как раз есть такая ошибка).
- Всю структуру страницы максимально оформлять структурными тегами, то есть если заголовок, значит делаем заголовочным тегом, если некое перечисление пунктов, то оборачиваем тегом списка, если таблица, то делаем HTML-таблицей, если цитата, то тегом blockquote и т.п.
- Всем картинкам, кнопкам, полям форм посредством соответствующих тегов добавляем текстовые метки.
- Обеспечиваем полную клавиатурную навигацию атрибутом tabindex, который позволяет как включить в перебор по Tab и Shift+Tab какой-то элемент, так и исключить его оттуда, а также задать порядок перебора. Абсолютно все кнопки и ссылки вашего сайта надо сделать доступными для взаимодействия только с клавиатуры.
- Если есть CAPTCHA, то надо решать проблему недоступности графической задачи для слепых. Это отдельная большая тема, потому что там есть несколько подходов.
- По доступности для слабовидящих нужно, как минимум, соблюсти пороги контрастности текста и фона. Они прописаны в том же WCAG для крупного и мелкого текста. Это можно и автоматизировать, например, через www.dasplankton.de/ContrastA/
- Доступность мультимедийных плееров — отдельная история. Малой кровью это решается использованием стандартных видео и аудиоплееров HTML5.
Если достаточно добросовестно соблюсти эти базовые вещи, то вашим интерфейсом вполне сможет пользоваться незрячий без особой фрустрации. Они-то, откровенно говоря, не избалованы вылизанными в отношении accessibility интерфейсами, так что с мелкими недостатками вполне готовы мериться.
Если же у вас развесистый Rich Internet Application с кучей JavaScript, динамики через Ajax и прочих выкрутасов, то accessibility тут уже надо поднимать с ручным тестированием через реальные экранные чтецы, причём под несколькими конфигурациями. Здесь без опытного QA-инженера accessibility обойтись будет трудно. Да и если стоит задача вылизать доступность, то, боюсь, без специалиста, понимающего специфику разных чтецов на разных платформах и способного протестировать и подсказать конкретные технические решения, это нереально.
Отдельная история — разруливание конфликтов невизуального и визуального дизайна. Например, надо бы поставить заголовок в начале раздела, но графический дизайнер хватает за руки и рыдает, прося не писать лишних букв. Тогда ставим заголовок, но средствами позиционирования выносим его за видимую часть страницы. После этого, визуально его не видно, но программами экранного доступа он без проблем читается. Но подобные лайфхаки в проект обычно тоже приносит опытный QA-инженер accessibility.
Ну у меня проект почти целиком состоит из текстов (сайт о снах, мы по нему с вами некоторое время назад переписывались как раз), так что реализовать всё в лучшем виде не должно составить труда.
Кстати, я сам люблю использовать навигацию клавиатурой, потому что бывает просто лень тянуться за мышкой/тачпэдом, поэтому грамотная навигация в этом ключе поможет не только тем, у кого плохо со зрением.
А как читалки реагируют на CSS-свойства элементов? Скажем, если он задан как display:none (или visibility:hidden), он будет озвучен или проигнорирован? И можно ли через те же метки (aria) задавать разные состояния элемента, когда он «открыт» или «закрыт» (то есть когда меняется display/visibility)?
Кстати, я сам люблю использовать навигацию клавиатурой, потому что бывает просто лень тянуться за мышкой/тачпэдом, поэтому грамотная навигация в этом ключе поможет не только тем, у кого плохо со зрением.
А как читалки реагируют на CSS-свойства элементов? Скажем, если он задан как display:none (или visibility:hidden), он будет озвучен или проигнорирован? И можно ли через те же метки (aria) задавать разные состояния элемента, когда он «открыт» или «закрыт» (то есть когда меняется display/visibility)?
Да, я помню ваш сонник. У вас в принципе итак всё было неплохо. Для вашего интерфейса, насколько я помню, вопрос дальнейшего развития accessibility лежал скорей уже в зоне вылизывания.
Клавиатурная навигация полезна и пользователям с нарушениями моторики. Многие из них не могут нормально работать с мышью. К слову, ещё есть такая штука как атрибут accesskey, который позволяет задавать клавиатурные команды для фокусирования/активации элемента. Правда тут есть неприятность с зависимостью от раскладки, поэтому основные вещи лучше подвешивать на цифры и универсальные знаки типа дефиса и равенства, которые не меняются в кириллической и латинской раскладках.
display:none и visibility:hidden экранными чтецами обрабатываются точно также, то есть информация просто становится невидна (перестаёт зачитываться вслух и выводиться на брайлевский дисплей).
Здесь есть одна тонкость:
Так лучше не делать, потому что пустая семантическая область, к сожалению, продолжает читаться. То есть экранный чтец зачем-то говорит, что есть пустая область, что только захламляет невизуальный интерфейс. Я склонен относить это к недоработкам чтецов, но приходится это учитывать, поэтому лучше скрывать не просто содержимое семантической области, но весь этот блок:
То есть пустые блочные элементы, если у них есть семантическая роль ARIA, в отличии от визуального интерфейса абсолютно бесследно не схлопываются. Ну а если семантической роли нет, то схлопываются и полностью исчезают.
По поводу задавания состояния через метки ARIA не очень понял. Как уже сказал, display/visibility воспринимаются и чтецами, так что вряд ли есть необходимость в дополнительных действиях. Если вы про что-то другое, то поясните.
Через ARIA можно задавать состояния, но это история для программирования кастомных checkbox и прочего. Например, у вас есть нарисованная штучка, которая сделана вообще через div, отслеживает клик мышки и меняет цвет.
С точки зрения accessibility — это плохо, потому что оно не фокусируется с клавиатуры, а также не читается, ибо бвизуально ориентировано. Однако вот такая уж у вас задумка и менять это на нормальный checkbox по каким-то причинам нельзя.
Тогда мы пристраиваем к этому div костыли:
(Магия такого рода описана в WAI-ARIA.)
Вот таким макаром мы чиним доступность изначально безнадёжно недоступного переключателя, который можно было кликать только мышкой и читать глазами, при этом не переделывая сам элемент. Хотя, откровенно говоря, ваять такие переключатели — это, конечно, говнокодерство. Однако это встречается в реальной жизни и подобная реализация переключателя как раз пример изначально абсолютно недоступного элемента интерфейса.
Клавиатурная навигация полезна и пользователям с нарушениями моторики. Многие из них не могут нормально работать с мышью. К слову, ещё есть такая штука как атрибут accesskey, который позволяет задавать клавиатурные команды для фокусирования/активации элемента. Правда тут есть неприятность с зависимостью от раскладки, поэтому основные вещи лучше подвешивать на цифры и универсальные знаки типа дефиса и равенства, которые не меняются в кириллической и латинской раскладках.
display:none и visibility:hidden экранными чтецами обрабатываются точно также, то есть информация просто становится невидна (перестаёт зачитываться вслух и выводиться на брайлевский дисплей).
Здесь есть одна тонкость:
<aside role="complementary">
<p style="display:none">Бла-бла-бла.</p>
</aside>
Так лучше не делать, потому что пустая семантическая область, к сожалению, продолжает читаться. То есть экранный чтец зачем-то говорит, что есть пустая область, что только захламляет невизуальный интерфейс. Я склонен относить это к недоработкам чтецов, но приходится это учитывать, поэтому лучше скрывать не просто содержимое семантической области, но весь этот блок:
<aside style="display:none" role="complementary">
<p>Бла-бла-бла.</p>
</aside>
То есть пустые блочные элементы, если у них есть семантическая роль ARIA, в отличии от визуального интерфейса абсолютно бесследно не схлопываются. Ну а если семантической роли нет, то схлопываются и полностью исчезают.
По поводу задавания состояния через метки ARIA не очень понял. Как уже сказал, display/visibility воспринимаются и чтецами, так что вряд ли есть необходимость в дополнительных действиях. Если вы про что-то другое, то поясните.
Через ARIA можно задавать состояния, но это история для программирования кастомных checkbox и прочего. Например, у вас есть нарисованная штучка, которая сделана вообще через div, отслеживает клик мышки и меняет цвет.
С точки зрения accessibility — это плохо, потому что оно не фокусируется с клавиатуры, а также не читается, ибо бвизуально ориентировано. Однако вот такая уж у вас задумка и менять это на нормальный checkbox по каким-то причинам нельзя.
Тогда мы пристраиваем к этому div костыли:
- Через tabindex делаем его фокусируемым с клавиатуры.
- Через aria-label задаём ему название.
- Через role делаем его как бы флажком для экранных чтецов.
- Через aria-checked задаём ему буливым значением состояние отмеченности.
(Магия такого рода описана в WAI-ARIA.)
Вот таким макаром мы чиним доступность изначально безнадёжно недоступного переключателя, который можно было кликать только мышкой и читать глазами, при этом не переделывая сам элемент. Хотя, откровенно говоря, ваять такие переключатели — это, конечно, говнокодерство. Однако это встречается в реальной жизни и подобная реализация переключателя как раз пример изначально абсолютно недоступного элемента интерфейса.
Я имел в виду переключалки состояния без использования JS, только на селекторах CSS (вот пример: jsfiddle.net/e01ad7rh/ ). Когда чекбокс отмечен, блок скрыт, и наоборот. Сам элемент не отображается (display: none), но управляется через привязанную к нему метку (label for="..."), которая меняет состояние, а в CSS описано правило для отображения или скрытия следующим за чекбоксом элементом, в зависимости от его состояния (отмечен или нет).
Собственно, основной вопрос, как это грамотно описать для таких читалок, ведь изначально элемент скрыт, а при взаимодействии с «кнопкой» появится. Если ему (div) задать aria-label, то читалка укажет, что стал доступным элемент с таким-то названием (в моём случае там внутри будет список со ссылками)?
Отход от стандартных элементов интерфейса типа закрашивания дивами поверх я считаю злом, которое не только путает пользователей, но и часто работает криво.
Собственно, основной вопрос, как это грамотно описать для таких читалок, ведь изначально элемент скрыт, а при взаимодействии с «кнопкой» появится. Если ему (div) задать aria-label, то читалка укажет, что стал доступным элемент с таким-то названием (в моём случае там внутри будет список со ссылками)?
Отход от стандартных элементов интерфейса типа закрашивания дивами поверх я считаю злом, которое не только путает пользователей, но и часто работает криво.
С aria-label проблема в том, что в подавляющем большинстве случаев его значение полностью заменяет текст элемента для программ экранного доступа.
При большинстве основных пользовательских конфигураций, такая ссылка экранным чтецом будет называться «Назад», то есть aria-label перебивает обычный текст. Правда в конфигурации «Экранный чтец JAWS + браузер Internet Explorer» это будет читаться как «НазадВернуться», то есть значение aria-label приклеивается к началу обычного текста ссылки.
То есть если в вашем примере задавать для «Toggle» aria-label, то надо во-первых, в текст метки писать как название, так и состояние, а во-вторых, быть готовым к тому что на JAWS+IE к текстовой метки будет в конце приклеиваться ещё исходный текст «Toggle».
В качестве альтернатив можно рассмотреть либо динамическое изменение прямо текста «Toggle», но тут вопрос, насколько это приемлемо с точки зрения визуального дизайна, либо средствами ARIA превращать этот «Toggle» в checkbox и программировать для него состояния отмеченности и неотмеченности. Во втором случае визуально всё будет точно также, а под программой экранного доступа этот переключатель будет называться флажком, который может быть отмечен, а может быть и неотмечен.
Конечно, надо смотреть по реальному проекту, но если рассуждать чисто теоретически, то, наверное, я бы пошёл по пути превращения переключателя в pseudocheckbox для экранных чтецов.
<a href="../" aria-label="Назад">Вернуться</a>
При большинстве основных пользовательских конфигураций, такая ссылка экранным чтецом будет называться «Назад», то есть aria-label перебивает обычный текст. Правда в конфигурации «Экранный чтец JAWS + браузер Internet Explorer» это будет читаться как «НазадВернуться», то есть значение aria-label приклеивается к началу обычного текста ссылки.
То есть если в вашем примере задавать для «Toggle» aria-label, то надо во-первых, в текст метки писать как название, так и состояние, а во-вторых, быть готовым к тому что на JAWS+IE к текстовой метки будет в конце приклеиваться ещё исходный текст «Toggle».
В качестве альтернатив можно рассмотреть либо динамическое изменение прямо текста «Toggle», но тут вопрос, насколько это приемлемо с точки зрения визуального дизайна, либо средствами ARIA превращать этот «Toggle» в checkbox и программировать для него состояния отмеченности и неотмеченности. Во втором случае визуально всё будет точно также, а под программой экранного доступа этот переключатель будет называться флажком, который может быть отмечен, а может быть и неотмечен.
Конечно, надо смотреть по реальному проекту, но если рассуждать чисто теоретически, то, наверное, я бы пошёл по пути превращения переключателя в pseudocheckbox для экранных чтецов.
Я имел в виду aria-label для следующего за чекбоксом div:
И вот когда чекбокс не отмечен, этот список скрыт, а когда отмечен — виден. Или тогда лучше такой вариант?
Логика такая же: в зависимости от состояния чекбокса список виден или скрыт.
При обычном сценарии после нажатия на «toggle» будет и так понятно, что появился некий список. Для варианта с читалкой ему нужно задать какое-то название, чтобы было ясно, что там появилось (но отображать это название не нужно).
<div aria-label="Список ссылок на нечто">
<a href="/foo">Первая ссылка</a><br />
<a href="/bar">Вторая ссылка</a>
</div>
И вот когда чекбокс не отмечен, этот список скрыт, а когда отмечен — виден. Или тогда лучше такой вариант?
<ul aria-label="Тоже список">
<li><a href="/foo">Первая ссылка</a></li>
<li><a href="/bar">Вторая ссылка</a></li>
</ul>
Логика такая же: в зависимости от состояния чекбокса список виден или скрыт.
При обычном сценарии после нажатия на «toggle» будет и так понятно, что появился некий список. Для варианта с читалкой ему нужно задать какое-то название, чтобы было ясно, что там появилось (но отображать это название не нужно).
Оба варианта не очень:
Таким образом, лучше сделать div или семантический контейнер с ролью, для него прописать aria-label, а внутри поместить список ссылок, размеченный именно структурой HTML-списка. То есть это будет так:
Но, разумеется, в aria-label писать тривиальности не нужно. Поясняющие метки реально нужны, если могут быть трудности с пониманием того, что это за список.
Если, например, у вас дёргается переключатель, который называется «Похожие статьи», после чего вываливается из под спойлера список этих самых статей, то вот дополнительно подписывать список вряд ли нужно. Итак понятно, что это такое выпало под переключателем. То есть переборщить со специальной разметкой тоже можно, так что не надо расшибать лоб. :-)
- У простого div aria-label не читается. Нужно, чтобы блок был либо в семантическом контейнере, типа aside, nav и пр., либо с ролью.
- У списков ul aria-label чтец JAWS воспроизводит, а вот NVDA нет, то есть проблема универсальности.
Таким образом, лучше сделать div или семантический контейнер с ролью, для него прописать aria-label, а внутри поместить список ссылок, размеченный именно структурой HTML-списка. То есть это будет так:
<aside role="complementary" aria-label="Список ссылок">
<ul>
<li><a href="/foo">Первая ссылка</a></li>
<li><a href="/bar">Вторая ссылка</a></li>
</ul>
</aside>
Но, разумеется, в aria-label писать тривиальности не нужно. Поясняющие метки реально нужны, если могут быть трудности с пониманием того, что это за список.
Если, например, у вас дёргается переключатель, который называется «Похожие статьи», после чего вываливается из под спойлера список этих самых статей, то вот дополнительно подписывать список вряд ли нужно. Итак понятно, что это такое выпало под переключателем. То есть переборщить со специальной разметкой тоже можно, так что не надо расшибать лоб. :-)
В Будапеште есть классный музей слепых.
Там работают только слепые экскурсоводы и они водят обычных людей по ситуациям квартира — улица — магазин — парк — бар, но в полной темноте.
Очень интересно для осознания насколько это сложно.
Кстати сам экскурсовод немало рассказал о своей жизни, сказал что вообще не пользуется брайлем, говорит, что на айфоне очень крутой режим для слепых, он же ему читает этикетки. Да, он даже пишет на нем СМСки и почту друзьям.
На компьютере он пользуется виндой и каким-то спец софтом, который читаем ему все сайты, он пользуется обычным интернетом и тд. В целом я был удивлен, что слепые не почти используют специальные приборы, сайты, книги, а используют разные «адаптеры», позволяющие общаться с миров для видящих.
Там работают только слепые экскурсоводы и они водят обычных людей по ситуациям квартира — улица — магазин — парк — бар, но в полной темноте.
Очень интересно для осознания насколько это сложно.
Кстати сам экскурсовод немало рассказал о своей жизни, сказал что вообще не пользуется брайлем, говорит, что на айфоне очень крутой режим для слепых, он же ему читает этикетки. Да, он даже пишет на нем СМСки и почту друзьям.
На компьютере он пользуется виндой и каким-то спец софтом, который читаем ему все сайты, он пользуется обычным интернетом и тд. В целом я был удивлен, что слепые не почти используют специальные приборы, сайты, книги, а используют разные «адаптеры», позволяющие общаться с миров для видящих.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем онлайн-кинотеатр для слепых (WCAG 2.0 AAA)