Pull to refresh

Рекомендации по доступности страниц для людей с ограниченными возможностями

Accessibility
Sandbox
Многие слышали о рекомендациях WAI-WCAG (Web Accessibility Initiative Web Content Accessibility Guidelines), призванных в частности помочь пользователям с ограниченными возможностями (например с дефектами или отсутствием зрения).

Но, зачастую, он игнорируется или отправляется как backlog task в долгий ящик. Это кажется лишним, не востребованным, да и в принципе, что слепой будет делать у меня на сайте?

Braille

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

В моем же случае — это требование заказчика. Согласно Section 508 если я хочу продать продукт любому федеральному органу США – я должен поддерживать этот стандарт.

Многие скажут, что вряд ли собираются что-то продавать правительству США, но в России такой стандарт тоже есть (ГОСТ Р 52872–2007) и никто не гарантирует, что завтра он вас/нас не коснется.

Следует также отметить, что если вы уже следуете принципам корректной разметки (согласно w3c) и оптимизации для поисковых систем, то кардинальных изменений от вас не потребуется.

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

Изображения:
  • Если изображение несёт какую-либо информацию – поместите описание в атрибут alt;
  • Если изображение используется в качестве ссылки – используйте alt для пояснения куда ведет ссылка;
  • Если вы используете изображения без какой-либо информационной нагрузки (spacer.gif например) оставьте alt="" пустым.

Таблицы
  • Добавьте название таблицы в элемент CAPTION;
  • Опишите сжато, какую информацию содержит таблица, и поместите ее в summary;
  • Укажите THEAD, TFOOT, TBODY. (Причем футтер должен идти до тела таблицы TBODY, чтобы он успел отрендериться раньше всей таблицы)
  • Используйте TH – для обозначения ячеек-заголовков в колонках, а TD — для данных;
  • Строчную ячейку-заголовок обозначайте атрибутом scope=«row». Это позволит ассоциировать эту ячейку со всеми ячейками в строке TR;
  • Используйте атрибут abbr для указания коротких названий заголовков;
  • Не допускайте вложенности таблиц. Если вложенная таблица простая — замените её списком. В противном же случае screen-reader`ам будет сложно ассоциировать вложенные ячейки.

Обработчики событий.
  • Пытайтесь избегать «узких» обработчиков таких как onMouseOver и onMouseOut. Пользователь не сможет работать с ними посредством только клавиатуры. В таком случае добавляйте дополнительные обработчики:
Соответствие обработчиков
текущий обработчик дополнительный
onClick onKeyPress
onMouseDown onKeyDown
onMouseUp onKeyUp
onMouseOver onFocus
onMouseOut onBlur
onDblClick onKeyDown
  • Следует отметить, что большинство браузеров вызывает событие onClick для некоторых элементов при нажатии Enter. Поэтому добавление дополнительного обработчика приведет к вызову события дважды. Для этих элементов – A, INPUT, AREA, BUTTON достаточно оставить только onClick;
  • Элемент A всегда должен содержать атрибут href пусть всего лишь с #. В противном случае ссылка не получает фокуса при табуляции;
  • Если для навигации используются не ссылочные элементы, а допустим блочные — DIV, то для получения фокуса следует обеспечить его атрибутом tabindex;
  • Не следует забывать и о логичной системе табуляции. Если же времени на это не хватает, а вырывать навигационный элемент из общего потока табуляции не хочется – просто поставьте значение tabindex равное 0.

Навигация

Рекомендуется в начале меню ставить ссылку для перехода сразу к контенту. Это даст возможность не проходить по одинаковым ссылкам на каждой странице.

Элементы формы.
  • Каждый элемент формы должен иметь понятную метку (LABEL) которая стоит рядом. В основном слева, а для элементов checkbox и radio button – справа;
  • В исключительных случаях если метку разместить негде, — следует к элементу формы добавить атрибут title с описанием что пользователь должен ввести;
  • Использование атрибута title и меток одновременно крайне не желательно – это вызывает конфликт у многих вспомогательных устройств чтения информации;
  • Для сложных форм необходимо применять группирующий элемент FIELDSET c элементом LEGEND

Для примера не корректного применения меток приведу форму песочницы хабрахабра:

Код песочницы

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

Утилиты для облегчения разработки

Это плагины WAVE для Firefox`а и InFocus Toolbar для IE от SSB Bart Group. Оба плагина бесплатны.

Есть так же очень удобный screen-reader JAWS. Однако, он платный и купить его не так просто.

Ссылки


P.S. И главное, — если не знаешь таких людей это не значит, что они не пользуются интернетом. А ведь завтра и сам можешь оказаться ограниченным в возможностях.
Tags:wai-wcagвеб-стандартыaccessibilitywai-ariasection 508web standardstipsинтерфейсыюзабилити
Hubs: Accessibility
Total votes 63: ↑63 and ↓0 +63
Views5K

Popular right now

Web-analyst/Веб-аналитик
to 150,000 ₽SapeМоскваRemote job
Веб-дизайнер
from 40,000 ₽Территория РостаRemote job
UX-исследователь (UX-researcher)
from 120,000 to 240,000 ₽Ю-экспертRemote job
Веб-дизайнер
from 80,000 ₽Синергия-ИнфоМоскваRemote job
Веб-дизайнер
to 150,000 ₽ITSOFTМоскваRemote job

Top of the last 24 hours