Пользователь
0,0
рейтинг
14 февраля 2015 в 00:14

Разработка → Делаем онлайн-кинотеатр для слепых (WCAG 2.0 AAA)

В РФ живет около 275 тысяч слепых и слабовидящих людей, 22% молодежь, некоторые из них также являются пользователями интернета, как и мы.

В этой статье я поделюсь с вами инструментами и необычным опытом, который можно получить при создании онлайн-кинотеатра для слабовидящих людей.

image
(пример адаптированной темы на GitHub по ссылке с картинки )

Что такое WCAG 2.0?


Это стандарт доступности сайтов для людей с ограниченными возможностями. Описывает правильные подходы к проектированию интерфейсов и дизайна сайтов. Почитать про стандарт: тут на английском , а тут на русском.

Зачем вообще это нужно?


Слабовидящие люди пользуются интернетом с помощью специального ПО, которое работает качественно только на специальным образом адаптированных сайтах.

Где будут фильмы? что такое тифлокомментирование?

Тифлокомментарии в кино — это дополнительная звуковая дорожка, содержащая закадровое описание видеоряда. Тифлокомментарии составляются по определенным правилам и озвучиваются профессиональным диктором в паузы между диалогами. Фильмы покажут только инвалидам по зрению из соответствующих организаций (но всё это действительно работает).

Инструменты для тестирования

Читалки
Такие пользователи слышат ваш сайт с помощью NVDA и JAWS если используют Win или с помощью встроенного Voiceover на Mac OS Х (она входит в состав операционки и достаточно удобна).

Описание VoiceOver есть здесь, про JAWS можно почитать тут, а вот тут можно узнать больше про NVDA.
Третий продукт — это проект с открытым исходным кодом и вы можете помочь в его улучшении.

Чекеры
Чекры легко нагуглить по запросу «wcag 2.0 checker» (их достаточно), мне понравился вот этот.
Кроме того, есть еще специальный тулбар для FireFox.

Очень удобно, если у вас есть неподалеку подходящий «тестер», но если нет, вы можете воспользоваться готовыми чекерами или включить программу-читалку и попробовать использовать свой сайт с закрытыми глазами.

Впечатления и подводные камни


1. «Обычный сайт» в скринридере звучит как каша, пользоваться стандартной клавиатурной навигацией — невозможно, т.к. не видно состояний, поэтому быстро теряешься. Однако, на сайтах даже с минимальной адаптацией можно понять что где и даже что-то почитать.

2. Скринридеры сами по себе еще недостаточно совершенные, и неясно — это программа глючит, или на сайте косяк.

3. Интересно читать тексты — длинные и скучные можно проматывать. Если текст нормально размечен с подзаголовками — промотка на них ориентируется и можно уловить общий смысл. Если нет, то читалки выхватывают отдельные слова и в итоге получается компот.

4. Интересно ведут себя адаптивные сайты в зуме и с «пропорциональной типографикой» — увеличиваешь размер — получается такой гигантский мобильный лайаут, но пропорции между элементами сохраняются и по прежнему все понятно.

5. В зависимости от браузера скринридеры по разному читают — и вообще они довольно разные.

6. Отсутствуют многие устойчивые конвенции привычные зрячим: например, шапка сайта и «первый экран» не существуют, есть лишь «информация в начале страницы», которая повторяется каждый раз, если разработчики не вставили ссылку для «пропустить».

7. Проблема с ссылками в «новом окне»: человек с большой долей вероятности теряется и не понимает, что произошло и вернуться нельзя, потому что обычная кнопка назад не работает.

8. 404-страница: человек в принципе понимает, что что-то не так, но что именно — сориентироваться сложно. Первая идея — это наиболее частая ошибка. Если сеть часто рвется, то человек думает, что интернет оборвался. Если программа какая-то глючит или виснет — он думает, что она зависла и т.п. Иногда разработчики помещают на 404 какие-нибудь «новости» или еще что — и это еще больше запутывает.

8. Поп-апы: например, галерея типа лайбокс вроде бы доступная потому, что фокус на миниатюре и дальше всё с клавиатуры управляется, но для скринридера в ней особых подсказок нет и не понятно как с ней быть.

9. «Разделы в разработке»: человеку очень сложно сориентироваться, что это такое. Он не понимает, что «там просто ничего нет» и думает что «оно есть», но по какой-то причине ему не показывается или что-то сбойнуло у НЕГО.

10. Есть интересные баги: например, в FF плеер — это ловушка — попадаешь в него, а выйти назад с клавиатуры нельзя, так и бродишь по кругу по всем его кнопкам, пока мышкой не ткнешь куда-нибудь (youtube плеер, любой плеер в ифрейме). Cпастись невозможно — существует целый тред на багзилле по этому поводу.

11.Самый распространенный браузер у таких людей — ИЕ и чудо если 9. Это сложный социальный феномен — есть социальная программа РФ, по которой инвалидам по зрению выделяют бесплатно специально оборудованные компьютеры (жуткое старье), они берут «как есть» и пользуются «как есть». Только более-менее молодые соображают что-то туда поставить. Даже если есть Chrome, то они им не пользуются почти, тк ИЕ удобнее. Они к нему привыкли и знают, что как называется, где какие меню и они не меняются никогда (теперь особенно).
Все новые прекрасные функции — им до одного места потому, что не поймешь где что стало и вообще все по другому

12. Приоритеты совсем другие в плане софта: нам нравится новое — удобнее, клево, красота,
а им наоборот — лучше оставить все как было иначе потеряешься и ничего не поймешь и будешь слушать свой скринридер по 10 раз пока въедешь.

13. Иногда у них стоят программы для удаленного управления компом — и когда дело совсем плохо — удаленный собеседник может подключиться и ткнуть мышью куда надо (доверенное лицо или друзья).

14. Про социальные сети: Вконтакте довольно трудно, но возможно пользоваться, а вот в ФБ — практически невозможно — очень много всплывающего и такого где нужно ориентироваться по изображению. Кстати, у Яндекса (по слухам) есть практически слепой человек в штате, который всякие штуки им помогает адаптировать.

15. Если сайт понятен скринридеру — остальным должно быть понятнее в 2 раза. Скринридер — это крутая штука для тестирования — если что-то «странно» в скринридере, то это в большинстве случаев ошибка. Да и тексты начинаешь писать короче и более внятные.

16. Мир (внутри компьютера), который все время с тобой говорит: я кнопка, я ссылка, я всплывашка, да еще с ошибками и сбоями. На вещи, которые нам кажутся простыми (дело пары секунд — нашел кликнул)
могут уходить минуты.

17. На MacOS Маверикс — скринридер называет картинку «образом». Пишите альт текст к картинкам!

Дополнительные ссылки на полезные ресурсы:

Много информации по доступности проектов на WordPress выложено тут, еще кое-что можно подчерпнуть отсюда — здесь собрано множество текстов в одном месте.

П.С.

Особую благодарность заслуживает Фитисов Алексей Владимирович, который выступил тестировщиком и очень помог своими комментариями и отзывами о работе различных программ-читалок, а так же Анна Ладошкина из Теплицы социальных технологий, которая сделала over90% работы.

Создавайте доступные сайты!

Update. В среднем, если использование WCAG закладывается на уровне технического задания — то стоимость проекта увеличится на не более чем 10%.
Глеб Суворов @gsuvorov
карма
35,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (21)

  • +3
    Спасибо, было очень интересно про это почитать.
    Добавьте возможность сделать пожертвование с помощью карточки/электронных денег, а не только квитанции.
    • 0
      Вам спасибо! Делайте доступные сайты;)
      Про пожертвования: это требует определенных организационных действий со стороны СВЕТ'а, к которым они не совсем готовы, в силу своего повышенного консерватизма. Может быть в следующем году они созреют и до приема платежей яндекс.деньгами и карточками. Технически-то всего лишь галочку в админке лейки поставить.
  • +3
    Правильную тему затронули!
    Вот бы еще какую-нибудь краткую версию документации WCAG20 чтобы веб-разработчики хотя бы минимально уделяли время тому чтобы сделать свои сайты еще доступнее и проще для всех.
  • +13
    К слову, самый крутой русскоязычный синтезатор голоса RHVoice пишет слепая девушка Ольга Яковлева.
    • +1
      Круче Acapela?
  • 0
    Добавлю ссылок:

    1. Cайт Алексея Владимировича, эксперта, который помогал нам с тестированием — fitisov.cfspb.org/
    2. Профиль Анны Ладошкиной на гитхабе — github.com/foralien
    3. ИТВ — место, где десятки подобных некоммерческих задач ждут вас: https://itv.te-st.ru/
    • 0
      А почему у «эксперта» Алексея Владимировича сайт свёрстан без элементарных заголовков? Заголовки — это более приоритетное требование, чем семантические области.
      • 0
        Алексей Владимирович не является веб-разработчиком — сайт ему помог сделать его друг (тоже не веб-разработчик). Ему всё (более-менее) нравится, возможно потому, что он ээээ видит этот сайт несколько иначе чем вы. Если вы предложите свою помощь в переделке в соответствии со всеми стандартами — это будет просто отлично.
  • +6
    Извините, но у вас какая-то каша в голове по поводу web accessibility:

    1. Насколько мне известно, в РФ около 280 тыс. тотально слепых, около 600 тыс. так называемых слабовидящих, то есть инвалидов с остаточным зрением, а те или иные нарушения зрения разной степени критичности имеются примерно у 10 млн россиян. Но вот сколько из них ходит в Интернет — это очень спорный вопрос.
    2. WCAG — это в большей степени менеджерский документ и технологам он даёт крайне мало. То есть как именно сверстать доступную страницу из WCAG почерпнуть не получится. Технологам надо читать WAI-ARIA, но многие вещи в web accessibility формализовать практически невозможно, поэтому в идеале нужен ещё грамотный QA-инженер accessibility. Причём далеко не каждый слепой может быть хорошим QA-инженером, хотя обычно предпочитают просто брать первого попавшегося слепого пользователя из какой-нибудь общественной организации инвалидов, в итоге, результат соответствующий.
    3. Автоматическая проверка web accessibility помогает отловить совсем базовые проблемы, типа отсутствующего alt-текста, необходимость которого вообще предполагается даже по стандартам общей валидации W3C. По-настоящему проверить accessibility можно только функциональным ручным тестированием, который должен делать грамотный специалист, способный проверить структуру страницы, доступность по базовым пользовательским сценариям и дать конкретные технические рекомендации, а не просто отзывы, типа «здесь работает, а здесь не работает».
    4. Обычный сайт не читается как каша. У программ чтения экрана есть ряд функций для того, чтобы обеспечить относительно приемлемую степень удобства навигации даже по совсем неподготовленной странице. Криминал — это полная вёрстка в flash, развесистые Rich Internat Applications и прочие вещи. Но чтобы сделать совсем или практически недоступный сайт, надо постараться.
    5. Если текст не размечен заголовками — это, конечно, плохо, но его можно читать итак, а также перемещаться по нему и экранный чтец не будет выхватывать отдельные слова. Это какая-то глупость.
    6. Принципиально экранные чтецы читают сайт практически одинаково. Есть всего два основных концептуальных подхода: документоподобное представление web-контента и объектное. Объектное представление характерно для мобильных платформ и OS X, а документоподобное для всех остальных, в том числе JAWS и NVDA на Windows или Orca на *nix.
    7. Повторяющийся контент в верхней части страницы основными экранными чтецами пропускается, так что это надуманная проблема. Кроме того, концепция шапки, бокового меню, основной части страницы и для незрячих также существует, просто немного в другом виде. Это реализуется через специальные роли WAI-ARIA. В WCAG, разумеется, это не описано, поэтому и надо использовать техническую, а не менеджерскую документацию.
    8. Проблема со ссылками в новом окне надумана. Программы экранного доступа, как правило, сообщают об открытии страницы в новом окне или вкладке.
    9. При загрузке новой страницы сразу читается её заголовок, поэтому если 404 написано прямо в title, то пользователь сразу понимает, что произошло. Первый раз слышу, что страницы 404 являются какой-то проблемой в контексте web accessibility.
    10. С разделами в разработке вообще не понял, в чём вы видите проблему. Если у вас грамотно размечена страница и пользователь без проблем понимает, где её основная часть, а в этой основной части написано, что раздел в разработке, то никаких проблем нет. Если же у вас на странице явно не указано, что раздел в разработке, то и зрячий останется в непонятках, что это у вас такое.
    11. Про браузеры лучше так не говорить. Ситуация намного сложнее и не так однозначна.
    12. "…им наоборот — лучше оставить все как было иначе потеряешься и ничего не поймешь и будешь слушать свой скринридер по 10 раз пока въедешь", «На вещи, которые нам кажутся простыми (дело пары секунд — нашел кликнул) могут уходить минуты» — многие незрячие пользователи вас бы разорвали за эти фразы. Краски сгущены и явно проблема качества внешней экспертизы, так как «эксперты», судя по всему, экстраполируют свой личный опыт и проблемы на всё сообщество пользователей этой категории. Такие проблемы, действительно, от части есть, но не повсеместно и не в отношении абсолютно всех задач.
    13. В Facebook есть своя команда accessibility, в отличии от тех же VK или Одноклассников. Хотя пару лет назад Одноклассники рапортовали о поддержке web accessibility, которую вроде как разрабатывали совместно с «экспертами» из общественных организаций инвалидов. Однако там в принципе многое изначально было сделано неправильно, к тому же в течение пары месяцев всё обратно поломали, а в официальном блоге Mail.ru на Хабре ребята предпочли в своё время замять эту тему, когда им был задан вопрос. Так что с доступностью социальных сетей как раз всё диаметрально противоположно — западные лучше.
    14. «Пишите альт текст к картинкам!» — при этом вы сами не сделали это для картинки, которую вставили в этой статье. ;-)


    В общем хорошо, честь интерес к web accessibility, но вы явно подошли с какого-то не того конца.

    1. Читайте WAI-ARIA, а не WCAG. Также в контексте вашего проекта имеет смысл ознакомиться с документами «Media Accessibility User Requirements» и «Web Video Text Tracks Format». В последнем даже есть встроенный инструментарий прямо для аудио дискрипции видео контента, правда пока всё это не в статусе рекомендованных стандартов.
    2. При вёрстке сосредоточьтесь на структурном и семантическом каркасах страницы, то есть структура — заголовки, списки, таблицы, а семантика — роли ARIA.
    3. RIA проверяйте особенно тщательно, и если ручное функциональное тестирование выявляет проблемы, то по стандарту WAI-ARIA программируйте состояния и свойства для элементов управления, либо заменяйте на стандартные контролы.
    4. Обеспечивайте полную клавиатурную навигацию по интерфейсу. Для этого используется tabindex.
    5. Подпись графических элементов подразумевается обычной спецификацией HTML, поэтому это просто то, что должны знать абсолютно все и не допускать таких ошибок даже без валидаторов.
    6. Избегайте фреймов. Максимум допустим iframe для не основного контента.
    7. Привлекайте QA-инженеров accessibility, которые способны как изначально подсказать пути реализации, так потом и провести итеративное тестирование и доработку.
    • 0
      Спасибо за содержательную критику! Описал впечатления полученные непосредственно в процессе работы, не более того.
      Сколько из таких пользователей ходит в интернет — вопрос открытый. Несколько десятков тысяч, точно.
  • 0
    А есть какие-то способы понять, что пришёл пользователь, основным инструментом которого будут не глаза? Прежде всего — чтобы понять, какую долю посетителей сайта они вообще составляют.
    А то получится, что стараешься, делаешь всё как надо, а пользоваться-то этим некому.
    • 0
      Нет, хотя в индустрии периодически поднимается этот вопрос. Тем не менее, это примерно то же самое, что получение информации о национальности, расе или сексуальной ориентации посетителя сайта, то есть вопрос этики стоит в полный рост.

      Но у меня есть встречный вопрос: допустим вы получили такую возможность, например, в виде настройки браузера, которая начинает передавать эту информацию в запросах. Какое количество (абсолютное или относительное) пользователей вспомогательных технологий вы будите игнорировать, а после какого начнёте чесаться? А главное, как вы будите чувствовать себя с моральной точки зрения, если будите точно знать, что какое-то число пользователей, которое не вписывается в ваш порог рентабельности, заставляете мучиться? К тому же если в этом месяце не было ни одного слепого посетителя, то это ещё не означает, что в следующем месяце их не будет 100 штук.

      Добровольное внедрение accessibility — это вопрос социальной ответственности. У вас есть конкретный числовой порог, после которого у вас включается эта самая ответственность?

      Ну и всё это не говоря о проектах, для которых accessibility может являться либо обязательным требованием, либо конкурентным преимуществом.
      • +2
        Мне бы даже одного такого пользователя хватило, чтобы понять, что усилия приложены не зря. А где один, там и другие появятся. Тем более я некоторые шаги по оптимизации сайта сделал.
        Вообще думаю, что доступность сайта сравнима с локализацией: если на начальном этапе это закладывать, то всё будет легко реализовываться. Насколько я понимаю, главная проблема сейчас в том, что нет чёткого описания, кто и где писать, есть только общие рекомендации.
        • 0
          На мой взгляд, обеспечение accessibility даже проще локализации, потому что поддержание её намного менее трудозатратно, тогда как переводы надо постоянно актуализировать при развитии проекта. За 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.
          • 0
            Ну у меня проект почти целиком состоит из текстов (сайт о снах, мы по нему с вами некоторое время назад переписывались как раз), так что реализовать всё в лучшем виде не должно составить труда.

            Кстати, я сам люблю использовать навигацию клавиатурой, потому что бывает просто лень тянуться за мышкой/тачпэдом, поэтому грамотная навигация в этом ключе поможет не только тем, у кого плохо со зрением.

            А как читалки реагируют на CSS-свойства элементов? Скажем, если он задан как display:none (или visibility:hidden), он будет озвучен или проигнорирован? И можно ли через те же метки (aria) задавать разные состояния элемента, когда он «открыт» или «закрыт» (то есть когда меняется display/visibility)?
            • 0
              Да, я помню ваш сонник. У вас в принципе итак всё было неплохо. Для вашего интерфейса, насколько я помню, вопрос дальнейшего развития accessibility лежал скорей уже в зоне вылизывания.

              Клавиатурная навигация полезна и пользователям с нарушениями моторики. Многие из них не могут нормально работать с мышью. К слову, ещё есть такая штука как атрибут 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.)

              Вот таким макаром мы чиним доступность изначально безнадёжно недоступного переключателя, который можно было кликать только мышкой и читать глазами, при этом не переделывая сам элемент. Хотя, откровенно говоря, ваять такие переключатели — это, конечно, говнокодерство. Однако это встречается в реальной жизни и подобная реализация переключателя как раз пример изначально абсолютно недоступного элемента интерфейса.
              • 0
                Я имел в виду переключалки состояния без использования JS, только на селекторах CSS (вот пример: jsfiddle.net/e01ad7rh/ ). Когда чекбокс отмечен, блок скрыт, и наоборот. Сам элемент не отображается (display: none), но управляется через привязанную к нему метку (label for="..."), которая меняет состояние, а в CSS описано правило для отображения или скрытия следующим за чекбоксом элементом, в зависимости от его состояния (отмечен или нет).

                Собственно, основной вопрос, как это грамотно описать для таких читалок, ведь изначально элемент скрыт, а при взаимодействии с «кнопкой» появится. Если ему (div) задать aria-label, то читалка укажет, что стал доступным элемент с таким-то названием (в моём случае там внутри будет список со ссылками)?

                Отход от стандартных элементов интерфейса типа закрашивания дивами поверх я считаю злом, которое не только путает пользователей, но и часто работает криво.
                • 0
                  С aria-label проблема в том, что в подавляющем большинстве случаев его значение полностью заменяет текст элемента для программ экранного доступа.

                  <a href="../" aria-label="Назад">Вернуться</a>
                  


                  При большинстве основных пользовательских конфигураций, такая ссылка экранным чтецом будет называться «Назад», то есть aria-label перебивает обычный текст. Правда в конфигурации «Экранный чтец JAWS + браузер Internet Explorer» это будет читаться как «НазадВернуться», то есть значение aria-label приклеивается к началу обычного текста ссылки.

                  То есть если в вашем примере задавать для «Toggle» aria-label, то надо во-первых, в текст метки писать как название, так и состояние, а во-вторых, быть готовым к тому что на JAWS+IE к текстовой метки будет в конце приклеиваться ещё исходный текст «Toggle».

                  В качестве альтернатив можно рассмотреть либо динамическое изменение прямо текста «Toggle», но тут вопрос, насколько это приемлемо с точки зрения визуального дизайна, либо средствами ARIA превращать этот «Toggle» в checkbox и программировать для него состояния отмеченности и неотмеченности. Во втором случае визуально всё будет точно также, а под программой экранного доступа этот переключатель будет называться флажком, который может быть отмечен, а может быть и неотмечен.

                  Конечно, надо смотреть по реальному проекту, но если рассуждать чисто теоретически, то, наверное, я бы пошёл по пути превращения переключателя в pseudocheckbox для экранных чтецов.
                  • 0
                    Я имел в виду aria-label для следующего за чекбоксом div:
                    <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» будет и так понятно, что появился некий список. Для варианта с читалкой ему нужно задать какое-то название, чтобы было ясно, что там появилось (но отображать это название не нужно).
                    • 0
                      Оба варианта не очень:

                      1. У простого div aria-label не читается. Нужно, чтобы блок был либо в семантическом контейнере, типа aside, nav и пр., либо с ролью.
                      2. У списков 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 писать тривиальности не нужно. Поясняющие метки реально нужны, если могут быть трудности с пониманием того, что это за список.

                      Если, например, у вас дёргается переключатель, который называется «Похожие статьи», после чего вываливается из под спойлера список этих самых статей, то вот дополнительно подписывать список вряд ли нужно. Итак понятно, что это такое выпало под переключателем. То есть переборщить со специальной разметкой тоже можно, так что не надо расшибать лоб. :-)
  • +1
    В Будапеште есть классный музей слепых.
    Там работают только слепые экскурсоводы и они водят обычных людей по ситуациям квартира — улица — магазин — парк — бар, но в полной темноте.
    Очень интересно для осознания насколько это сложно.

    Кстати сам экскурсовод немало рассказал о своей жизни, сказал что вообще не пользуется брайлем, говорит, что на айфоне очень крутой режим для слепых, он же ему читает этикетки. Да, он даже пишет на нем СМСки и почту друзьям.
    На компьютере он пользуется виндой и каким-то спец софтом, который читаем ему все сайты, он пользуется обычным интернетом и тд. В целом я был удивлен, что слепые не почти используют специальные приборы, сайты, книги, а используют разные «адаптеры», позволяющие общаться с миров для видящих.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.