Что такое скринридер voice over
Обзор полезных функций и способов отключения VoiceOver
Разработчики программного обеспечения для устройств торговой марки Apple стараются учитывать потребности всех людей. Благодаря этому появилась полезная функция VoiceOver. Она предназначена для людей с тяжёлыми нарушениями зрения. Включить подобную опцию очень легко. Неопытные пользователи часто сталкиваются с незнанием, как отключить VoiceOver. Такой режим представляет собой голосовые подсказки, которые сопровождают любое действие, выполненное на девайсе Apple. Программа доступна на операционных системах iOS, установленных на всех Айфонах и Айпадах. Есть возможность использования такой функции на Mac OS. Иногда пользователи случайно активируют режим, в использовании которого нет необходимости. Следует отметить, что существует два способа отключения режима VoiceOver, о которых необходимо знать каждому обладателю мобильных устройств торговой марки Apple.
Характеристика работы VoiceOver
Режим VoiceOver позволяет управлять мобильным устройством при помощи жестов, при этом все действия сопровождаются голосовыми подсказками. Следует отметить, что такая опция позволяет использовать большинство возможностей Айфона либо Айпада, не глядя на экран. Достаточно провести по экрану, чтобы программа озвучила, какие компоненты находятся. Одинарное нажатие позволяет узнать информацию об объекте. Двойное касание обеспечит нажатие кнопки. Смахивание позволяет использовать режим прокрутки.
Существует специальная система управления мобильным устройством, которая разработана в виде диска прокрутки. Он позволяет осуществлять выбор между режимами пролистывания страниц. Если открыта страница интернет-сайта, то прокручивание диска позволит ознакомиться с именами объектов, ссылками, изображениями, подзаголовками и т. д. Можно задать перечень объектов, для которых будет осуществляться управление с помощью диска прокрутки.
Apple идёт навстречу людям с ограниченными возможностями
Активация функции происходит при тройном нажатии кнопки. Существует два режима работы с VoiceOver. При одном из них на экране отображается рамка, благодаря которой окружающие смогут видеть, что происходит на мобильном устройстве. Конфиденциальный режим позволяет скрыть изображение от посторонних глаз. При использовании такой опции снижается громкость воспроизведения аудио- и видеоматериалов, стандартных звуков мобильного устройства. Такая настройка позволяет хорошо слышать звуковые сигналы VoiceOver. Программа совместима с 30 наиболее распространёнными языками, в том числе с русским.
VoiceOver позволяет использовать приложения. Функция корректно взаимодействует со всеми предустановленными приложениями iOS. Среди них давно известные каждому пользователю программы:
У юзеров есть возможность создавать удобные кнопки и задавать им функции приложений. Необходимо отметить, что с каждым днём всё больше программ поддерживают опцию VoiceOver, поскольку она существенно облегчает управление мобильным устройством для человека с ограниченными возможностями. Компания Apple постоянно сотрудничает с разработчиками стороннего программного обеспечения с целью внедрения в них возможностей VoiceOver.
Как деактивировать настройку?
Часто возникают ситуации, когда юзеры включают режим случайно. Отключить функцию несложно. Попробуйте выполнить тройное нажатие кнопки «Home». О том, что мобильное устройство снова вернулось в обычный режим, свидетельствует текстовое уведомление «VoiceOver off». Если опция все ещё активна, то это свидетельствует о том, что были изменены настройки. В таком случае отключение голосового помощника можно выполнить через Меню.
Сложность состоит в том, что пользователи при активном VoiceOver не могут использовать привычное управление мобильным устройством. Необходимо выполнять голосовые подсказки и пролистывать вкладки вместо стандартных касаний сенсорного экрана. Попробуйте провести пальцем и найти необходимый раздел. Внимательно слушайте голосовые подсказки, благодаря которым можно определить, в какой раздел вы осуществили вход. Голосовое описание вызывается одним нажатием. Выбор можно сделать при помощи двойного нажатия кнопки. Прокрутка выполняется с помощью круговых движений тремя пальцами. Ползунок служит для регулировки параметра.
С помощью простых действий необходимо выполнить команду Настройки — Общие — Универсальный доступ — VoiceOver. Двойное нажатие выключит параметр. Такие действия не только смогут выключить опцию, но и настроить другие параметры, которые предназначены для людей с ограниченными возможностями. Среди них контрастная цветовая схема, увеличение отображаемых объектов, гид-доступ.
VoiceOver — это функция, которая позволяет людям с серьёзными нарушениями зрения использовать современные возможности техники Apple. Благодаря такому параметру можно осуществлять звонки, выполнять работу с приложениями, читать текстовую информацию, не имея возможности смотреть на экран. Юзеры, которые не испытывают проблем при использовании гаджетов, могут включить режим исключительно в ознакомительных целях, после чего его необходимо деактивировать.
VoiceOver на iOS: каждый контрол ведёт себя по-разному
Привет, Хабр! Недавно я говорил про адаптацию приложений для незрячих и неподвижных людей. И не договорил!
Сегодня расскажу, как изменить поведение контролов с помощью accessibilityTraits и сделать жизнь незрячих чуть удобней. Знать работу этих трейтов (traits) важно, чтобы не писать свои костыли.
Адаптация iOS-приложения — большая тема, в одну статью всё не влезло, поэтому выпускаю их серией.
В первой части мы начали разбираться с адаптацией приложений для незрячих с помощью VoiceOver: подписали контролы, сгруппировали их, исправили навигацию. В этой статье пойдём дальше и рассмотрим «особенности», которые можно дать контролам, чтобы улучшить их работу для незрячих людей и в целом повысить удобство использования приложения.
Особенности элементов управления — Trait collection
Тип контрола
VoiceOver знает про несколько базовых типов элементов. Часть из них уже настроена в вашем проекте, но всё равно расскажу про них.
Типы контролов используются для навигации: по ним можно быстро перемещаться с помощью ротора.
Состояние контрола
У контрола может быть три состояния: обычный, выбранный и отключенный. Интересно, что произносятся они в разное время и могут быть выбраны одновременно:
Особые свойства контролов
Есть ещё несколько необычных свойств. В нашем случае к экрану с пиццей они не подходят, но я всё равно расскажу про них, потому что информации о них мало. Возможно, это сэкономит вам время.
— standart typing — как простая кнопка в VoiceOver: сначала наведите фокус на букву, а затем нажмите дважды в любом месте, чтобы написать её. Набирать можно быстрее двумя руками: одним пальцем водить по клавиатуре (буквы будут озвучиваться) и касаться другим пальцем, чтобы подтвердить выбор клавиши.
— touch typing — однорукий ускоренный набор: водите пальцем по клавиатуре, чтобы озвучить кнопки. Отпустите палец, чтобы написать букву.
— direct touch typing — как обычный набор, будто VoiceOver выключен.
Видео про разные способы ввода:
Переключатель теста. Настройка теста состоит из пяти кнопок: три для выбора размера пиццы и две для типа теста. Их стоит сгруппировать и подписать, чтобы вместо пяти осталось две: «Размер, средний. Элемент регулировки» и «Тесто, традиционное. Элемент регулировки».
Нужно сделать в 4 шага:
Счетчик количества всего на свете. В данном блоке мы видим четыре контрола: кнопка минус, количество, кнопка плюс и цена. Можно объединить их в одну view и превратить в один контрол: «Количество, 1, 575 рублей. Элемент регулировки». После вертикального свайпа изменится количество, а затем произнесётся новое значение вместе с ценой.
Заключение
В следующий раз посмотрим на решение типовых проблем: порядок обхода, модальные окна, индикаторы загрузки.
А ещё у нас сейчас открыта одна вакансия в мобильном направлении. Так что я просто оставлю это здесь: Senior iOS Developer (Нижний Новгород).
VoiceOver на iOS. Как сделать приложение удобнее для людей с нарушением зрения
Доброго времени суток! Меня зовут Иван Смолин. Я iOS разработчик в Touch Instinct.
Сегодня я хочу рассказать, что из себя представляет технология VoiceOver в iOS. И как мы сделали футбольное приложение более удобным для людей, у которых есть нарушения зрения.
Что такое VoiceOver
Это основанный на жестах способ чтения содержимого на экране мобильного устройства. Технология позволяет пользователям управлять своим мобильным устройством без необходимости видеть содержимое на экране. Она выступает в качестве посредника между интерфейсом приложения и пользователем, проговаривает вслух детали элементов интерфейса и действия в приложении.
Эта функция особенно полезна для людей с нарушениями зрения. VoiceOver упрощает использование мобильного устройства для людей с такого рода проблемами. Если эта функция активирована, пользователи могут ориентироваться в интерфейсе и понимать, какие действия нужно сделать и какими будут результаты этих действий. [1]
Как пользоваться VoiceOver
Когда пользователь тапает по любому месту на экране, его мобильное устройство (iPhone, iPad, Watch) проговаривает вслух элемент, который находится в этом месте.
Как добавить поддержку VoiceOver в ваше приложение
В подавляющем большинстве случаев ваше приложение уже будет хорошо работать с VoiceOver. Тут стоит отдать должное инженерам Apple — все стандартные компоненты полностью поддерживают технологию VoiceOver. Однако, иногда всё же нужно написать немного дополнительного кода, чтобы ваш интерфейс стал более удобным для людей с нарушениями зрения.
Бывают всего два типа компонентов, для которых нужно обязательно реализовывать поддержку VoiceOver самостоятельно:
Так как первый вид встречается довольно редко, мы рассмотрим подробно способы, которые позволят значительно улучшить ситуацию во втором случае.
В остальных случаях можно лишь повысить удобство использования при помощи дополнительных возможностей, которые предоставляет нам VoiceOver.
Дизайн
Если в приложении изначально закладывается поддержка вспомогательных технологий, таких как VoiceOver, то всё начинается с дизайна. Существует специальное руководство по обеспечению доступности веб-контента и руководство, как применять этот стандарт для мобильных платформ. Эти руководства стоит как минимум прочитать перед тем, как начинать рисовать дизайн.
После того, как макеты нарисованы, к ним необходимо приложить дополнительную информацию. Она не видна визуально, но имеет критическое значение для людей с нарушениями зрения. В случае VoiceOver такой информацией будет являться текстовое описание всех элементов экрана, с которыми пользователь может взаимодействовать: видеть или нажимать. Важно текстово описать их характеристики.
Пример
Переключать «запомнить меня» (4) на странице входа.
Разработка
После получения локализованных строк можно начинать разработку. Для начала необходимо прочитать руководство по программированию специальных возможностей. А затем уже углубиться в UIAccessibility API.
UIAccessibility
Этот протокол содержит в себе набор свойств, которые описывают пользовательские элементы интерфейса. Вспомогательные приложения используют эту информацию, чтобы помочь пользователям с ограниченными возможностями.
Этот протокол содержит очень много свойств, которые можно сгруппировать по критериям:
Отвечающие за описание элемента:
accessibilityTraits — комбинация (перечисление) характеристик, которыми обладает элемент. Эти характеристики помогают VoiceOver понять, как нужно взаимодействовать с элементом. Характеристик достаточно много [https://developer.apple.com/reference/objectivec/nsobject/1615202-accessibilitytraits], перечислим только некоторые их них.
Если в вашем приложении есть проблемы с доступностью для людей с ограниченными возможностями, то чаще всего требуется правильно переопределить только первую группу свойств.
Пример UIAccessibility в FotMob
Теперь я приведу пример, как, используя вышеописанные свойства UIAccessibility, решить вполне конкретные проблемы в приложении.
В ходе тестирования был выявлен ряд недочётов, связанных с именованием кнопок в навбаре для VoiceOver. Мы решили порефакторить код создания кнопок, чтобы решить эти проблемы и сделать кнопки переиспользуемыми во всём приложении.
Для начала мы создали enum со списком всех кнопок и значениями, которые эти кнопки могут в себе хранить:
Далее был создан extension, который создавал готовые инстансы UIBarButton и UIButton из значений enum’а:
Создание кнопок в итоге выглядело вот так:
После этих изменений в приложении появились не только правильные названия для VoiceOver, но и добавилась дополнительная информация, которая очень полезна для людей с нарушениями зрения. Например, при выборе кнопки календаря, прочитывается не только его название, но и выбранная дата.
Аналогично для кнопки уведомлений. Мы сообщаем пользователю, находится ли кнопка в выбранном состоянии (уведомления включены) или нет. Также мы сообщаем пользователю, что случится, если он тапнет по той или иной кнопке.
Такие небольшие улучшения значительно упрощают использование приложения.
Другим проблемным кейсом в приложении была таблица со статистикой команд. Для VoiceOver такая таблица представляет из себя просто набор аббревиатур и цифр, которые никак не связаны. Если мы попытаемся запустить приложение с включенным VoiceOver, то сразу станет понятно, что незрячим людям разобраться с этим набором бессмысленных слов просто невозможно.
Здесь мы использовали группировку элементов и специально подготовленные для VoiceOver строки. Например, заголовок таблицы теперь читается не как «PL W D L ± GD PTS», а в развёрнутом виде: «Table header: Played, Won, Drawn, Lost, Goal difference, Goal difference value, Points».
Каждая строка таблицы, как и заголовок, включает в себя полное описание полей: «Position: 4, Manchester United, Played: 36, Won: 21, Drawn: 9, Lost: 6, Goal difference: 72-38, Goal difference value: 34, Points: 72»
Тестирование
Если у вас есть матёрые тестировщики, которые умеют тестировать с закрытыми глазами — вам повезло. Однако часто ответственность за проверку функциональности ложится на плечи программиста.
Симулятор
Несмотря на то, что VoiceOver не поддерживается в симуляторе, тестировать приложение можно и на нём. В этом нам помогает утилита Accessibility Inspector, которая устанавливается вместе с Xcode.
В этой утилите можно:
По своему опыту могу сказать, что этой утилиты вполне достаточно для разработки, но недостаточно для полноценного тестирования. Так как она не проговаривает тексты и мы можем упустить очень важные проблемы, связанные со знаками препинания.
Тестировщики
Лучше всего, когда у вас есть человек с нарушениями зрения, который может по-настоящему попробовать приложение с включенным VoiceOver. Нам повезло, у нас был неравнодушный пользователь, который прошёлся по всему приложению и составил детальное описание всех мест, где VoiceOver работает недостаточно хорошо. Мы смогли исправить все указанные недочёты. Он и дальше помогал нам улучшать доступность приложения, за что ему огромное спасибо.
Забота о пользователях
VoiceOver является продвинутой технологией, которая позволяет вам делать по-настоящему доступные приложения для людей с нарушениями зрения.
Она встроена во все операционные системы Apple и работает фактически «из коробки». Поэтому независимо от того, пользуетесь ли вы VoiceOver или разрабатываете приложение с его поддержкой, VoiceOver везде будет работать одинаково и предсказуемо.
Качественно сделанные приложения с поддержкой VoiceOver могут даже удостоиться премии iOS Design Awards, как это случилось с Workflow в 2015 году.
The Workflow app was selected for an Apple Design Award in 2015 because of its outstanding use of iOS accessibility features, in particular an outstanding implementation for VoiceOver with clearly labeled items, thoughtful hints, and drag/drop announcements, making the app usable and quickly accessible to those who are blind or low-vision. [2]
Наверное, каждая команда хотела бы получить такой же отзыв и о своём приложении. Старайтесь сделать всё возможное для ваших пользователей, чтобы им было удобно пользоваться приложением вне зависимости от их возможностей.
Недоступность в картинках
Когда мы говорим про доступность, мне часто не хватает визуальной составляющей. «Недоступно для скринридера» — как это выглядит?
Когда есть возможность запустить программу экранного доступа и увидеть всё своими глазами, это достаточно освежающий опыт, после которого начинаешь гораздо аккуратнее выбирать теги. Мне хотелось бы, чтобы это попробовал каждый, кто имеет дело с вёрсткой, но я подозреваю, что, хотя многие слышали о доступности и скринридерах, запускать читалку пробовали далеко не все — потому что надо не только найти где включается скринридер, но и разобраться в непривычном и достаточно неинтуитивном интерфейсе.
Я не так часто запускаю скринридер, и каждый раз приходится вспоминать команды и привыкать заново. Вообще попытка разобраться в настройках скринридера даже для зрячего требует усилий, а как с ними разбирается слабовидящий пользователь — страшно представить (а после этого человек заходит в интернет и попадает на сайты, где его никто не ждёт).
Я думаю, что каждому, кто имеет дело с вёрсткой, стоит попробовать читать страницы скринридером, потому что недоступность страниц лучше один раз увидеть, чем сто раз услышать. Ниже мы посмотрим как можно можно проверить веб-страницы с помощью скринридеров и узнаем на что обратить внимание при тестировании.
В данный момент встроенные программы экранного доступа есть и в MacOS (VoiceOver), и в Windows (Narrator). Есть и другие приложения, например, NVDA и JAWS, но для первого знакомства со скринридером проще воспользоваться тем, что у же есть в вашей операционной системе.
По VoiceOver и Narrator есть официальная документация:
По ссылкам очень много текста, но нам достаточно небольшого количества команд.
Команды VoiceOver (MacOS)
Запуск и настройка
Если требуются дополнительные настройки, это можно сделать в Системные настройки/Универсальный доступ, и ещё больше настроек там же в подразделе Утилита VoiceOver.
Последовательный переход между элементами страницы:
Запуск чтения сверху вниз:
Взаимодействие с DOM-элементами:
«Взгляд сверху»:
Последняя команда — самая интересная: она показывает все ориентиры и заголовки страницы, все ссылки и инпуты. Можно сразу перейти в нужный раздел, как по содержанию бумажной книги, пройтись по ссылками или перемещаться по элементам формы.
Команды Narrator (Windows)
Запуск и настройка
Панель настроек: Windows + Ctrl + N
По умолчанию клавишами экранного диктора назначены клавиши Caps Lock и Insert (далее ЭД ).
Последовательный переход между элементами страницы:
Запуск чтения сверху вниз:
«Взгляд сверху»:
Эти команды — примерный аналог ротора в VoiceOver. Хоткеи есть только для этих разделов, но из них можно попасть в другие.
Имея по рукой читалку и команды, можно отважно запустить скринридер и попробовать читать сайты.
Можно начать читать прямо эту страницу или любую другую, но для более глубокого понимания в чём состоит разница между плохой и хорошей разметкой я создала проект, в котором есть оба этих варианта: A11y демо.
Доступная и недоступная страницы визуально ничем не отличаются:
Разница видна только в коде страницы, но для скринридеров эта разница значительна.
Недоступная версия свёрстана так, как если бы разработчик подумал «Какая разница какие теги? Добавлю CSS, и будет выглядеть как надо». Дивы вместо заголовков, вместо списков, кнопок — вместо всего. Зрячему пользователю практически без разницы что там в коде, но для слабовидящих воспользоваться такой страницей будет проблематично.
Ниже будут показаны примеры как именно скринридер видит (или не видит) разные варианты разметки. При чтении страницы VoiceOver дублирует произносимый текст в отдельном попапе, и именно он будет на скриншотах.
Скриншоты помогут понять что и как скринидер может не найти на странице, если полениться сверстать правильно, и подскажут на что обратить внимание, если вы отважились запустить скринридер и почитать страницы самостоятельно.
В примерах ниже все скриншоты будут с VoiceOver. Интерфейс Narrator, конечно, отличается, но структуру страницы они показывают примерно одинаково.
Куда смотреть?
Как мы обычно ориентируемся на веб-страницах? Сканируем глазами крупные элементы и заголовки, обращаем внимание на формы и ссылки. Скринридеры тоже так умеют: и VoiceOver, и Narrator умеют показывать заголовки, ссылки и интерактивные элементы.
Заголовки
Чтобы увидеть какие заголовки доступны читалке, выполните команды:
Для версии с плохой разметкой список заголовков будет выглядеть вот так:
На странице есть только один настоящий заголовок ( H1 ), все прочие заголовки — просто дивы с соответствующими стилями.
С такого заголовка можно попасть только в шапку сайта. На странице есть много других разделов, но для быстрой навигации они недоступны.
На странице с хорошей разметкой в роторе будут представлены все заголовки:
Можно выбрать нужный заголовок и сразу перейти в соответствующий раздел — это как в содержании книги найти нужную главу. Без оглавления пришлось бы листать всю книгу, а в случае с сайтом — прослушать весь сайт сверху вниз.
Почитать про этот способ можно здесь.
Обычные посетители не заметят разницы, а пользователи скринридеров получат возможность быстро попадать в любой раздел страницы.
Проверить иерархию заголовков можно на validator.w3.org/nu/, поставив галочку Outline, отчёт появится внизу страницы:
Также проверить заголовки можно в генераторе HTML-дерева:
Правильное использование уровней заголовков, помимо всего прочего, облегчает выбор нужного тега H1-H6 : когда у вас есть чёткое представление о структуре документа, вы сразу будете знать где какой тег должен быть. Это очень удобно.
Ориентиры
Чтобы увидеть какие ориентиры нашёл скринридер, выполните команды:
Предположим, разработчик не знал об этих тегах либо решил, что без разницы какие использовать. Получится такое:
Скринридер не обнаружил на странице никаких осмысленных элементов. Проблема та же, что и с заголовками: если ротор не показывает ориентир, пользователь не сможет быстро перейти к нужному разделу, а то и вовсе не узнает о его существовании.
А вот так будут выглядеть ориентиры, если использовать теги по назначению:
Не всё переведено, но, по крайней мере, можно примерно понять, что есть на странице, и перейти к нужному элементу.
Элемент main позволит пользователю скринридера сразу перейти к основному содержимому страницы, минуя шапку и верхнее меню. Вам ничего специально не нужно для этого делать, кроме как использовать правильный тег.
Формы
Формы используются на веб-страницах для самых разных целей. Скринридеры умеют читать элементы форм, и, если всё сделано правильно, пользователь сможет заполнить форму даже не видя её глазами.
Сможет купить билет, оформить документы или сделать заказ в интернет-магазине — при условии, что разработчик не поленился и сделал всё как надо. А если поленился, что тогда?
Чтобы увидеть какие элементы формы нашёл скринридер, выполните команды:
Откроем ротор на странице с плохом примером:
Скринридер нашел несколько радиокнопок и чекбокс без описаний. Что делают все эти инпуты — совершенно непонятно.
Иногда на странице с плохом примером скринридер может показывать в качестве лейблов ближайший текст, но это поведение нестабильно. Кроме того, скринридер может подставлять не тот текст. Если перемещаясь по странице несколько раз открыть ротор, можно поймать разные варианты подписей к инпутам.
А вот как выглядит форма на самом деле:
В роторе потерялась половина инпутов и кнопка «Заказать», у оставшихся нет подписей.
В плохом примере можно увидеть несколько распространенных ошибок:
display: none
Во-первых, скрытие инпутов с помощью display: none убирает их со страницы полностью — и визуально, и для скринридеров. Пользователь скринридера не сможет попасть на них никаким образом. На скрине ротора выше видно, что там представлены только радиокнопки с выбором веса и цвета, а чекбоксов с сортами просто нет. Если читать страницу сверху вниз, скринридер честно прочитает подписи к чекбоксам, но сами чекбоксы для него отсутствуют полностью.
Во-вторых, использование display: none создает проблемы при навигации с клавиатуры, потому что лишает возможности попасть на эти инпуты переходя по табу. С точки зрения браузера их вообще нет на странице, поэтому переход по табу просто проигнорирует эту группу инпутов. Зрячие пользователи всё ещё могут выбирать чекбоксы кликая по лейблам, но с помощью Tab это сделать не получится, придётся кликать вручную.
Лейблы для инпутов
Отсутствие лейблов также является серьёзной проблемой. Инпуты доступны для скринридера, к ним можно перейти, но что они делают — совершенно непонятно:
Пользователь может попытаться ориентироваться по окружающему тексту, но так можно запутаться что за чем идёт и выбрать не тот инпут, к которому относится текст. Чтобы избежать путаницы, имеет смысл всегда всем инпутам привязывать лейблы с текстовым описанием.
Лейблы делают форму удобнее и для зрячих пользователей: когда есть лейблы, можно кликнуть по тексту лейбла, а не целиться по инпуту. Сравнить такое поведение можно в плохом примере: чтобы выбрать сорт, достаточно кликнуть по тексту, чтобы выбрать вес — придётся целиться по радиокнопке, что очень неудобно.
Привязать лейбл к инпуту можно через атрибут for :
Или вот так, вложив инпут в лейбл:
Оба способа работают одинаково, так что без разницы какой выбирать. Главное — не забывать добавлять лейблы для всех инпутов на странице.
Лейблы без текста
Даже если лейблы есть, и они привязаны к инпутам, отсутствие в них текста делает их совершенно бесполезными для пользователей скринридеров. Как мы видели на скрине выше, в роторе такие инпуты будут показаны без описаний, а если перейти непосредственно к инпуту, скринридер покажет это:
А так как рядом нет совсем никакого текста, у пользователя скринридера не будет никаких шансов понять что ему предлагается тут выбрать.
Div вместо Button
Последняя проблема — див вместо кнопки. Визуально никакой разницы, и по поведению тоже — по клику на «Заказать» происходит отправка формы, но для скринридера разница будет значительной: div — не интерактивный элемент, поэтому его не будет в роторе:
Если просто читать страницу сверху вниз, кнопка будет озвучена как обычный текст:
И на неё нельзя будет попасть по табу. Даже если пользователь скринридера умудрится заполнить форму, он просто не сможет её отправить.
Скринридер распознает кнопку как интерактивный элемент и озвучит это, покажет её в роторе, на неё можно будет перейти по табу, а нажав Enter или Пробел — отправить форму.
Таким образом, чтобы сделать инпуты доступными, нужно использовать теги по назначению, не скрывать их с display: none и не забывать про текстовые описания.
Для сравнения посмотрим на содержимое ротора на странице с хорошим примером:
В роторе видны все инпуты с описаниями и все состояния, есть текстовое поле и кнопка отправки формы. Уже очень неплохо, но кое-чего не хватает: непонятно что именно предлагается добавить в заказ и к чему относится выбор цветов.
Для вёрстки форм есть ещё пара тегов, которые не показываются в роторе, но они важны для правильного ориентирования в форме:
Fieldset и Legend
Когда инпутов мало, в принципе, даже по списку инпутов в роторе можно понять какие варианты выбора есть. Но формы могут быть очень разными и очень сложными, и тогда будет полезно группировать инпуты, а больших формах это совершенно необходимо.
У fieldset и legend могут быть проблемы со стилизацией в разных браузерах, но это совершенно не повод от них отказываться, все проблемы решаемы, а отсутствие в форме fieldset и legend может создать сложности пользователям скринридеров.
Что будет, если не использовать их вообще? Это можно проверить на странице с плохим примером. Поля не будут явно сгруппированы, а имя группы прочитается как обычный текст:
Если перед набором инпутов совсем не будет текста, у пользователя скринридера не будет совершенно никакой информации о том, что и зачем ему нужно сделать с этими инпутами. Если пролистать все инпуты, скринридер сразу перейдёт к следующему элементу формы никак не обозначив, что это была группа.
Скринридер не умеет делать такие выводы просто на основании того, что мы положили рядом несколько инпутов и текст. Чтобы помочь ему правильно понимать структуру формы, нужно использовать соответствующие теги.
Озвучивает, что сейчас мы находимся внутри группы:
А когда мы выходим из группы, скринридер явно сообщает какую именно группу мы покидаем:
Использование fieldset и legend помогает не только оценить размеры формы, понять, сколько полей нужно заполнить для решения своей задачи, но и уравнивает возможности пользователей. Зрячие увидят заголовок группы и рамки, ограничивающие группы полей и инпутов, пользователи скринридеров — услышат информацию о группе и инпутах внутри неё.
Если форма на сайте сверстана правильно, пользователь скринридера сможет купить билет, отправить письмо или оформить заказ не имея ни малейшего представления как выглядит форма на странице.
fieldset позволяет группировать только инпуты, но на страницах часто можно встретить и другой сгруппированный контент — картинки в галерее, ссылки в навигации, шаги в туториалах. Для этих целей можно использовать списки. Как к ним относятся скринридеры?
Списки
В страницах с примерами много списков, например, в рецептах это ингредиенты и процесс:
Попробуем прочитать верхний список на странице с плохим примером, там он вместо ol и li свёрстан дивами:
Скринридер будет просто читать текст сверху вниз никак не связывая элементы друг с другом.
Сравним с хорошим примером. Скринридер сразу озвучит список и сообщит сколько в нём элементов:
Для каждого пункта списка он зачитает всё текстовое содержимое, то есть не только ингредиент, но и его количество, а также покажет в каком месте списка мы находимся:
И озвучит выход из списка:
Для нумерованного списка, у которого не скрыта нумерация, может показать номер позиции или озвучить буллет:
Это поведение может различаться для разных браузеров.
Когда мы видим список чего-либо на странице, мы можем понять длинный он или короткий, увидеть, в каком месте списка находится нужный нам элемент. В случае с рецептом это поможет оценить его сложность и понять сколько шагов осталось до финиша, если мы таки начали варить компот.
Если мы используем для вёрстки списков правильные теги, пользователи скринридера смогут получить ту же информацию просто прослушав рецепт. Если же верстать списки дивами, для пользователей скринридера они окажутся простынёй бессвязного текста. Чтобы сделать списки доступными, используйте правильные теги.
Ещё скринридер умеет озвучивать ссылки и картинки.
Ссылки
Как посмотреть какие ссылки нашёл скринридер:
Ротор показывает все ссылки на странице, какие ему удалось найти:
Пользуясь таким списком можно, например, на сайте с новостями прочитать все ссылки на статьи и сразу перейти в нужную.
Но это скрин со страницы с плохом примером, и если сопоставить его с содержимым страницы, можно заметить, что части ссылок нет. Например, нет крайних ссылок из нижней навигации:
Если попытаться прочитать непосредственно отсутствующие ссылки, скринридер покажет такое:
А это — ссылка на репозиторий.
Narrator в роторе показывает все ссылки, но ссылки без текста будут в виде полного адреса.
Оба способа работают, ссылки отображаются в роторе:
Картинки
Как посмотреть какие картинки доступны для скринридера:
И будут озвучены при последовательном чтении страницы:
Firefox просто скажет что это картинка без каких-либо описаний и дополнений, а вот хром не только сообщит, что у картинки нет описания, но и предложит открыть контекстное меню, чтобы его получить:
А в нём будет предложено получить описание из Google, такая опция есть только при запущенном VoiceOver. Полученное описание появится в том же попапе:
Описание на английском, но это всё же лучше, чем ничего.
Отсутствие alt является ошибкой (и это покажет валидатор), потому что alt обязательный атрибут, он должен быть у всех картинок на странице.
Выводы
Иногда нам лень верстать семантично и использовать правильные теги, потому что ну какая разница, добавим стили и всё будет выглядеть как надо, но для пользователей скринридеров плохая разметка может стать серьёзной проблемой. Семантичная разметка позволит таким пользователям правильно услышать страницу и воспользоваться сайтом для решения своих задач.
Тема доступности — большая и сложная. Помимо семантической разметки она также включает в себя использование контрастных цветовых схем, упрощение текстов для улучшения восприятия, правильную разметку всплывающих окон и меню и многое другое. Но даже не погружаясь глубоко в эту тему, можно сделать достаточно много просто используя теги по назначению.
Так что если у вас возникала мысль «зачем нам столько разных тегов?» — в том числе, вот за этим, они помогают программам экранного доступа правильно озвучивать страницу. А кроме того, используя теги по назначению, гораздо удобнее верстать. Например, вот так выглядит в коде конец страницы в плохом примере и в хорошем:
В хорошем примере сразу видно где какой тег закрылся, в плохом же можно понять только то, что закрылся див, открытый где-то выше. Если в каком-то месте потеряется закрывающий див или наоборот, заведётся лишний открывающий — страница развалится, а если все теги выглядят одинаково — такую ошибку легко сделать просто по невнимательности.
validator.w3.org/nu/ поможет обнаружить потерявшиеся теги, а использование разнообразных тегов снизит риск возникновения такой проблемы.
Кстати, самый простой способ увидеть структуру страницы (и косвенно оценить доступность) — это посмотреть на неё без стилей. Например, вот так выглядит на разных версиях раздел с рецептами:
Плохая версия без стилей похожа на поток сознания, в то время как хорошую всё ещё можно без проблем прочитать.
Надеюсь, статья поможет вам внимательней относиться к тегам и лучше понимать почему это важно.
Увидеть больше рекомендаций по разметке с примерами кода можно на Веблайнд. Почитать про доступность — в блоге Веб-стандартов.
Upd. от 9.09.2020: как заскринить попапы скринридера? Это нетривиальная задача, потому что при нажатии хоткеев фокус читалки уходит на новое действие. Содержимое попапа с текущим текстом меняется, ротор мгновенно закрывается. Я использовала Monosnap, чтобы записать видео работы со скринридером, сохраняла его в GIF с частотой 1-3 кадра в секунду (чтобы в итоговом файле было как можно меньше одинаковых кадров) и потом из этой гифки в фотошопе вырезала нужный попап. Чтобы содержимое страницы не просвечивалось под попапом, контент можно скрыть с помощью opacity: 0 либо сделать внизу страницы большую белую область и размещать её под попапом прокручивая страницу.