Хотелось бы сразу подчеркнуть, что данная статья не претендует на какой-либо стандарт, не является прямым руководством к действию, а также содержит в себе только самые распространенные, но от того не менее критичные ошибки accessability при создании сайта.
Картинки и атрибут ALT
Самой распространенной ошибкой многих web мастеров является неиспользование атрибута alt="" в теге <img/> или неправильное его использование.
Если хотя бы указывать атрибут кое-как приучили требования поисковиков, то верно указывать мало кто умеет. Ниже приведу примеры неграмотного содержимого атрибута:
- Использование одного и того же слова для разных картинок (alt=«image»);
- Использование не несущего смысла набора символов (alt=«dsf86sdfgbvc94nf56»);
- Дублирование заголовка страницы;
- Размещение в атрибуте целого предложения, словосочетания;
- Указание в атрибуте одной буквы, зачастую не являющуюся даже первой буквой названия предмета на изображении.
Как наиболее логично использовать данный атрибут, разберем на примере.
Предположим, что у вас на сайте есть список пользователей, напротив аватарки каждого отображается его имя. Также предположим, что в списке пользователей попалось три пользователя с именем «Игорь». Если обычный пользователь среди Игорей найдет нужного по аватарке, то пользователь программы экранного доступа по одному имени нужного определить не сможет.
В этом случае самым верным решением будет у каждой аватарки в атрибуте alt="" вывести имя с фамилией пользователя. Таким образом, с точки зрения графического отображения, ничего не изменится, а незрячий посетитель сможет найти нужного человека.
Заголовки
Всем отлично известны теги заголовков с <h1> по <h6>. Думаю логично, что они должны использоваться именно для заголовков, а не для изменения размера шрифта, но находятся и такие умные люди.
В программе экранного доступа можно задать длину строки, обычно по умолчанию это 100 символов.
Когда символов в заголовке оказывается больше, чем одна сотня, скринридер перебрасывает остаток на новую строку.
Таким образом, при нажатии стрелки вниз на слишком длинном заголовке, программа озвучивает на двух строках «Заголовок уровня 1-6».
Всплывающий подсказки
На многих сайтах, в том числе некоторых регистраторов доменных имен, любят указывать цены за продление услуги во всплывающей подсказке при наведении мыши. Я не говорю, что это плохая тактика, но стоит задуматься о доступности этих подсказок для всех клиентов.
Решение очень простое, достаточно использовать у ссылок атрибут title="", но никак не использовать скрипты.
Примечание: есть непроверенная информация, что на планшетах атрибут title не озвучивается, но в статье речь идет в первую очередь о программах экранного доступа для Windows: Jaws и NVDA.
Таблицы и табличная верстка
Я не знаю, кто сейчас еще использует табличную верстку, но все же стоит от нее отказаться, если вы хотите сделать свой ресурс удобным для незрячих и слабовидящих.
Основные ошибки при использовании таблиц:
- Вложенность одной или нескольких таблиц в другую очень затрудняет навигацию, так как скринридер читает координаты каждой ячейки;
- Использование тега <th> там, где он не требуется. Примером может выступить скрипт игр «Ogame», «2moons», «Supernova» и подобных;
От вложенности таблиц лучше отказаться совсем, а атрибут <th> использовать в таблицах с расценками, со списком терминов, а не просто для красоты.
Роли и метки
Наверное самое известное из accessability — это роли и метки.
Атрибут role="" обычно прописывают в блоках <div>, но с приходом HTML5 надобность прописывания ролей в блоках исчезла.
В таблице представлен список ролей и заменяющих тегов из HTML5.
| Роль | Заменяющий тег | Представление скринридером |
|---|---|---|
| banner | <header> | Банер ориентир |
| navigation | <nav> | Навигация ориентир |
| main | <main> | Основной ориентир |
| complementary | <aside> | Добавочный ориентир |
| contentinfo | <footer> | Информация о содержимом ориентир |
| search | - | Поиск ориентир |
Как видно из таблицы, в HTML5 нет альтернативного тега для роли «search», ну или я ее не знаю.
Если на сайте встречается несколько разных меню, полей поиска, все ведь с одинаковой ролью, а если каждый подписывать обычным текстом, может получиться визуально слишком много информации.
В этом случае выручает атрибут area-label="".
В данном атрибуте вы можете указать любую информацию для пользователя программы экранного доступа, которая поможет ему сориентироваться среди однородных областей.
Важное дополнение: не стоит сразу же прописывать роли и метки ко всем областям сайта, это ужасно затрудняет навигацию.
Как по мне, например, роль «banner» вообще только мешается, так как всем понятно, что сверху шапка, а не подвал.
Капча
Напоследок хотелось бы затронуть тему капчей.
Благодаря специальным плагинам и аддонам, у современного пользователя скринридера не должно возникать проблем с прохождением защиты от роботов в следующих случаях:
- капча представлена текстовым арифметическим примером с просьбой ввести ответ;
- В форме используется виджет Recaptcha от Google, в котором необходимо просто отметить флажок;
- если используется графическая картинка, то у нее должен быть атрибут alt, желательно alt=«captcha» или alt=«картинка с кодом».
Если же картинка с кодом без атрибута alt, либо защита представляет собой паззл, либо вообще картинка вшита в дизайн сайта и символы генерируются прямо на фоне, то форму самостоятельно отправить незрячий посетитель уже не сможет.
На этом все
Я постарался описать основные ошибки, из-за которых сайты могут быть мало доступны для пользователей программ экранного доступа. Надеюсь, что кому-нибудь данная статья поможет в создании доступного сайта.
Если у кого-то остались еще какие-либо вопросы, охотно постараюсь ответить на них в комментариях.
Комментарии (43)
ht-pro
10.08.2017 16:56Если серьезно, о чем пост?)
Все правила, перечисленные в нем, учатся на фундаментальном уровне современной верстки. И даже более того…
maniyax Автор
10.08.2017 16:57+1Серьезно?
Вот давайте для развенчания этого мифа разберем какой-нибудь сайт.
Предлагаю вам выбрать для примера, чтобы ваши слова были чем-то подтверждены.
pepelsbey
10.08.2017 18:11+1Пост о том, что 2 из 10 верстальщиков знают об этом, а применяют — 0,5 из 10.
maniyax Автор
10.08.2017 18:13Угу.
Статья ведь не зря называется «Ошибки». Мало знать, изучив курсы, надо применять уметь.
demimurych
10.08.2017 20:43Дело не в ошибках, а в деньгах. Нет смысла тратить время для 1% аудитории, если можно потратить то же время для 10% аудитории. Такие вещи должны регулироваться государством на уровне дотаций. Бизнес на это реагировать будет ровно так же как и сейчас — нет смысла тратить на это деньги.
Aingis
11.08.2017 13:58В США суды уже штрафуют сайты за плохую доступность. Во многих странах есть нормы регулятора по доступности сайтов, как минимум государственных. Так что шанс отхватить за дискриминацию клиентов заметно отличен от нуля.
maniyax Автор
11.08.2017 13:59Та вон, дело в финансировании только. Все все знают, хотя на деле знают только в теории и очень отдаленно.
calliko
11.08.2017 15:29Здравствуйте. Уважаю людей с ограниченными возможностям. разрабатываю сайты (и дорабатываю ). в том году надо было для сайта детского садика поставить плагин оптимизирующий сайт для людей с ОВ по нажатии кнопки. бюджет 500рублей. ну естественно, что я не стал убирать верстку табличную или alt к картинкам дописывать. просто возможность увеличить шрифт, убрать картинки и сменить контраст. это все ))) вред ли это поможет, но сайт в соответствии ). грустно все это.
derSmoll
14.08.2017 00:42Спасибо за статью, а особенно за живые примеры.
Вы практически не упомянули формы. Значит ли это, что вцелом с ними все ок в плане доступности?
Еще интересны рекомендации по использованию JS на страницах. Есть ли какие-то популярные JS плагины или техники, которых лучше избегать?
Есть ли смысл в хардкорной оптимизации сайта по wcag ААА, или часть требований оттуда не имеют смысла?
Есть ли рейтинг фреймворков/cms, у которых все хорошо/плохо с доступностью из коробки?maniyax Автор
14.08.2017 01:00+1Здравствуйте!
Удивлен после всех комментариев и минусов, что статья для кого-то оказалась полезной. Радость.
Пойдем по порядку:
1. В целом с формами все нормально, кроме некоторых комбинированных списков, как в Qiwi, Yandex, например. Но я не разбирал код тех элементов, поэтому прописывать их в статье не стал. Да и не так часто они встречаются.
2. По JS ничего особого сказать не могу, ибо JS JS-у рознь. Если бы для примера что-то взять, а так не смогу ответить.
3. Читал я когда-то тот гост, вообще не понимаю, кто его писал и для кого. Для слабовидящих, не пользующихся скринридерами, там может что-то и есть полезное, но для программ экранного доступа ничего нужного.
4. Рейтингов нет, ибо зависит все в первую очередь от шаблона, а не CMS.
По личному опыту могу самым идеальным вариантом из коробки назвать тему Twenty Sixteen для Wordpress.
UPD: Drupal 8 вообще не доступен.
nohuhu
14.08.2017 21:05Есть ли смысл в хардкорной оптимизации сайта по wcag ААА, или часть требований оттуда не имеют смысла?
WCAG 2.0 наполнен смыслом до краёв, это крайне серьёзный документ. Кроме слабо- и полностью незрячих людей, есть ещё очень много видов ограниченных возможностей, WCAG пытается охватить всё, что можно.
Прочите документ, большая часть рекомендаций не выходит за рамки здравого смысла. Level AAA это жёсткий хардкор, на практике можно начать с первого уровня и дальше улучшать по мере необходимости.
nohuhu
14.08.2017 21:33+1Вот только что вспомнил важную штуку про тег alt, которую имеет смысл добавить в статью и выделить жирным шрифтом:
Если на сайте используются изображения, заданные через data URL, то надо обязательно присваивать таким элементам либо описание через alt="текст", если изображение несёт какой-то семантический смысл, либо role="presentation", если это просто фоновая картинка или спрайт.
Почему? А потому, что некоторые версии некоторых экранных читалок (JAWS! ненависть!) будут читать содержимое data-url, если нет alt. Т.е. например:
<img src="data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7" width="16" height="14">
… будет анонсировано в виде длинной строки букв, цифр и символов, что звучит ужасно конфузно. :(
Справедливости ради надо отметить что, сайт, с которого я взял этот пример, использует тег alt. В данном случае это неправильное решение, незрячим пользователям совершенно всё равно, есть эта картинка или её нет. Это элемент визуального оформления, который нужно "спрятать" от экранных читалок через role="presentation".
maniyax Автор
14.08.2017 21:40Если бы я еще знал, как тут редактировать публикации...)))
То наверное удалил бы ее в первый же день :-)
k12th
Самое главное — попробуйте сами свой сайт через IE и NVDA (щас расскажу почему), узнаете много интересного о себе и о своем коде.
Jaws является самой популярной программой среди слепых пользователей, но на самом деле она ужасна:
При всем при этом стоит 900 баксов для некорпоративного пользователя. В бесплатной версии работает по 40 минут после каждого ребута. В таких условиях я бы лично отдал эти лишние 900 баксов за макбук.
В NVDA таких проблем нет, плюс бесплатно. Синтез речи там немного похуже, но в любом случае надо в настройках включать Microsoft TTS, остальные все кромешный мрак.
Ни тот, ни другой софт не позволяют поставить себя на паузу. Поскольку кодить под аккомпанемент роботического голоса, произносящего каждую нажатую клавишу нереально, проще всего отрубить софтине звук через микшер.
maniyax Автор
Здравствуйте!
Я не знаю, где вы взяли такой бред. Видимо, вы не являетесь незрячим человеком и программами экранного доступа не пользуетесь.
1. Оптимизировать что-то под IE — это себя не уважать. Да и IE сам по себе не самый доступный из браузеров для программ экранного доступа.
Большинство незрячих людей пользуются спокойно Mozilla Firefox и не знают горя.
2. Jaws является известной, но не самой часто используемой программой. У 85% всех незрячих и слабовидящих установлена NVDA, причем Jaws из них дополнительно использует всего не более 40%.
3. Нажатием на клавишу CTRL любой синтезатор можно остановить, нажатием на SHIFT — поставить на паузу.
4. Самыми распространенными синтезаторами для NVDA являются Ispeak, Newfon, RHVoice и голоса для SAPE5, например Милена.
P.S.
При всем уважении, в чем смысл вашего комментария? Как он относится к теме данной публикации?
k12th
А я не знаю, где вы взяли свои манеры, но крайне рекомендую обратиться туда с рекламацией и потребовать деньги назад.
Интересно, что вас навело на эту мысль? Уж не то ли, что я заметил испорченные шрифты и мигающий курсор?
У вас свои источники, у меня свои.
А вы сами пробовали это?
Аналогично, вы сами их пробовали?
maniyax Автор
Ничуть, только ваше полное невежество и предложение во время кодинга отключать программу экранного доступа.
Если я тотально слепой человек и пользуюсь программой экранного доступа семь лет, может я понимаю, о чем говорю?
Успешно сейчас работаю с RHVoice на максимальной скорости.
И я повторяю вопрос: как данная тема относится к текущей публикации?
k12th
Ваш тон и ваш подбор слов это не извиняет, даже если это и правда.
Я буду приспосабливать сайты для пользователей с ограниченными возможностями, но в число таковых люди с функциональной неграмотностью не относятся.
nohuhu
Используйте виртуальные машины, я так и делаю несмотря на наличие коробочной версии JAWS на полке. :) Перезагрузить VM раз в 40 минут не проблема, и звук заглушить тоже можно отдельно от системного.
Только учтите, что использование демо-версии JAWS для любых целей, кроме ознакомительных, будет нарушать лицензию. Да, даже тестирование своих сайтов на совместимость. Freedom Scientific известные м%@#ки. :(
Тестировать в IE имеет смысл, только если есть отдельный заказ именно на это. Поддержка WAI-ARIA сломана во всех версиях IE вплоть до 11, плюс навзничь кривая прокладка между браузером (MSAA) и Windows 7+ (UIA) = адская боль и безнадёга.
Firefox + NVDA это основная связка для тестирования в 2017. В Firefox лучшая среди браузеров поддержка WAI-ARIA.
Источник: 4 года запиливания accessibility support в одном большом и развесистом JavaScript фреймворке. :)
maniyax Автор
Святой вы человек! Может хоть не пользователя программ экранного доступа, но профессионального верстальщика послушает эта странная персона)
nohuhu
Спасибо, но я даже близко не святой. Мне за эту работу хорошо платят. :)
Вёрстку знаю больше по касательной, моя задача это widgets. Делать в HTML + JavaScript годные компоненты UI как на десктопе это больно, а сделать, чтобы эти компоненты работали с экранными читалками это испытание характера и полный хардкор. Уже неплохо получается (после 4-х лет!), но до полной победы ещё ой как далеко...
maniyax Автор
Та я про другое))
Если потребуется сайт какой проверить на доступность, подсказать с точки зрения не просто доступности для галочки, а конкретно доступности для длительного использования, привычности, то стучитесь на admin@maniyax.ru.
Ну, разумеется, если вам не лень и за это платят)
nohuhu
Спасибо, непременно обращусь в будущем. Мне как зрячему человеку очень трудно оценивать доступность сайтов и веб-приложений, т.к. я не пользуюсь экранными читалками постоянно и у меня нет набора привычек и ожиданий. Грубо говоря, я не знаю, как оно должно себя вести. :)
В прошлом году была возможность консультироваться с ребятами из University of Washington, там есть большой специалист по accessibility, при этом сам незрячий. Очень помогло сдвинуть тему из категории "ну вроде работает, фиг знает" в сторону "да вроде можно использовать". :) Помощь реальных пользователей очень ценна в таких вопросах.
maniyax Автор
Сам занимаюсь разработкой сайтов (правда в последнее время переползаю в область хостинга, администрирования linux серверов), так что всегда буду рад помочь.
k12th
Ну винда в виртуалке тоже лицензию требует, разве нет?) Плюс пожирание ресурсов хоста и тормоза внутри, в общем, не идеальный выход.
Ну не знаю — то, что мы хотели, у нас в IE11 работало на таком же уровне, как в FF и Chrome.
nohuhu
Windows в виртуалке можно использовать с бесплатной лицензией: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. Microsoft предоставляет эти образы для веб-разработки, ну так мы же о ней как раз и говорим. В эти же виртуалки можно установить JAWS и NVDA, насколько я понимаю, лицензии Microsoft это не противоречит.
К тому же, если вы серьёзно относитесь к поддержке IE, то вам всё равно придётся держать под рукой зоопарк разных версий Windows + IE. Проще всего делать это в виртуальных машинах.
Очень хорошо если так, рад за вас. У меня ситуация другая: есть набор очень сложных и навороченных виджетов, которые надо "сделать доступными". Нативные HTML элементы весьма, гхм, ограничены, поэтому приходится использовать разные ухищрения + толстый слой WAI-ARIA соуса поверх. Вот тут IE и ломается с громким треском. :(
Самое смешное, что во многих случаях IE8 в Windows XP работает с экранными читалками намного прямее, чем IE11 в Windows 10. Это потому, что IE использует старое MS Accessibility API, а в Windows Vista и последующих его заменило более новое UI Automation API. Между старым и новым API сделали прокладку, кривую и безумно глюкавую. Чинить её не будут, потому как IE уже всё, а Edge использует новое API напрямую. А вот насколько хорошо Edge поддерживает WAI-ARIA это тоже открытый вопрос. :(
maniyax Автор
Мы с одним незрячим знакомым планируем перевод WAI-ARIA сделать с разбором каждой роли, с тестированием NVDA/Jaws/Orca в FF и возможно Chrome.
Потихоньку может так весь стандарт и протестируем, может сюда будем публиковать, если оно конечно для кого-то надо.
Просто не нашел русского перевода стандарта, тем более с тестами.
nohuhu
Мне кажется, более полезным был бы перевод критериев WCAG с рекомендациями по их выполнению. WAI-ARIA это набор инструментов для постройки сложных компонентов UI, использовать их нужно аккуратно и без фанатизма.
Есть мнение, что использование нативных элементов HTML может давать неплохие результаты, к этому надо стремиться. А если сходу кидаться использовать роли и атрибуты ARIA направо и налево, то результат будет менее, чем оптимальный. Плавали, знаем. :(