Screen Reader для Windows
Screen Reader — это простая утилита для слепых или слабовидящих пользователей, которая включает в себя функции преобразования текста в речь и масштабирования. Это небольшое приложение поможет людям с плохим зрением работать без напряжения глаз.
Когда речь идет о доступности, слабое зрение, нарушения зрения или некоторые заболевания становятся непреодолимым препятствием для использования программного обеспечения. Вот почему важно сделать программное обеспечение максимально доступным для широкого круга людей, чтобы каждый мог воспользоваться возможностями, которые могут предложить компьютеры.
Vovsoft Screen Reader пытается обнаружить любой текст, на котором находится курсор мыши, и прочитать его вслух. Это особенно полезно, когда пользователь взаимодействует с любым приложением Windows. Можно выбрать один из установленных голосовых движков и настроить скорость речи.
Также Vovsoft Screen Reader включает встроенную функцию масштабирования. Программа может увеличивать ту часть экрана, на которой находится курсор мыши. Пользователь также может выбрать коэффициент увеличения.
ICE Book Reader Pro — программа для удобного чтения электронных текстов (книг). Может читать тексты.
Govorilka — это небольшая программа для чтения текста голосом. Она может прочитать вслух любой.
Балаболка (Balabolka) — программа предназначена для чтения вслух текстовых файлов. Для.
Программа AudioBook предназначена для создания аудио книг.
Demagog — говорящий текстовый редактор. Программа предназначена для чтения вслух текстовых.
Простая в работе утилита, которая будет полезна людям с проблемами зрения, включающая в.
Отзывы о программе Screen Reader
Отзывов о программе Screen Reader 1.2 пока нет, можете добавить.
Программа чтения с экрана — Screen reader
A программа чтения с экрана является формой вспомогательной технология (AT), которая отображает текст и изображение в виде речи или шрифта Брайля. Программы чтения с экрана необходимы для слепых и полезны для людей с слабым зрением, неграмотных или неспособностью к обучению. Программы чтения с экрана — это программные приложения, которые пытаются передать пользователям то, что люди с нормальным зрением видят на дисплее, с помощью невизуальных средств, таких как преобразование текста в речь, звуковые значки или устройство Брайля. Они делают это, применяя широкий спектр методов, в том числе, например, взаимодействие с выделенными API-интерфейсами доступности, используя различные функции операционной системы (например, межпроцессное взаимодействие и запрос свойств пользовательского интерфейса ) и использование методов подключения.
5 самых неприятных фич для слепого человека на сайтах
Вот пять самых раздражающих своей недоступностью веб-элементов, с которыми я сталкиваюсь как слепая девушка-пользователь скринридера каждый день.
Для слепых и слабовидящих людей, таких как я, доступность — это не просто слово, это реальный выбор: или мы можем работать с сайтом, или не можем.
Как работают скринридеры
Скринридеры позволяют слепым и слабовидящим людям самостоятельно пользоваться компьютерами, телефонами и планшетами. В большинстве скринридеров работает движок Text To Speech (TTS), который преобразует текст с экрана в речь.
Скринридеры воспроизводят вслух всё, что находится на экране, и позволяют осуществлять навигацию сенсорными жестами и сочетаниями клавиш. Они также работают с другими устройствами вывода, такими как дисплей Брайля.
Вот наиболее распространённые проблемы, с которыми я сталкиваюсь ежедневно.
Неподписанные ссылки и кнопки
Пользователи скринридеров полагаются на ссылки и кнопки для навигации по веб-сайту и поиска необходимой информации. Если ссылки и кнопки помечены неправильно или вообще не помечены, то пользователям трудно найти нужную информацию. В конечном счёте, немаркированные ссылки значительно затрудняют простую, быструю навигацию по сайту.
Например, в ссылке на описание компании подпись «Нажмите здесь» не даёт никакого представления о том, куда она ведёт, в отличие от ясной фразы «Узнайте больше о том, кто мы такие».
Если ссылки и кнопки правильно помечены, то скринридеры могут зачитать надпись вслух. Это означает, что слепым и слабовидящим людям не придётся нажимать ссылку или кнопку, не зная, куда она приведёт.
Кроме немаркированных элементов, также действительно расстраивают ссылки и кнопки без ясного описания. Они должны сопровождаться чётким текстом, куда они ведут при нажатии, а не «Нажмите здесь». Никогда не заставляйте пользователей гадать или действовать методом проб и ошибок. Это утомительно и неудобно.
Изображения без описания
Вероятно, это самая распространённая проблема, с которой я сталкиваюсь при просмотре веб-страниц. Описания изображений очень важны для доступности. Они известны как alt text (альтернативный текст).
Скринридеры зачитывают вслух эти описания, так что слепые и слабовидящие люди могут понять содержание изображения в доступной форме. Если у изображений нет альтернативного текста, то скринридеры просто произнесут слово «изображение или «графика», что не даёт никакого контекста или смысла.
Изображения часто передают ценную информацию. Поэтому важно, чтобы люди с нарушениями зрения также могли получить доступ к этой информации, alt text должен быть чётко написан и давать точное описание изображения.
Ознакомьтесь с нашими советами по написанию alt text .
Плохое использование заголовков
Для быстрой и удобной навигации многие пользователи скринридеров перемещаются по странице с помощью различных элементов, таких как заголовки. Это отличный способ быстро находить нужную информацию. Особенно если заголовки следуют логической структуре H1, H2 и H3, которая помогает расставить приоритеты.
Если на сайте нет заголовков, то пользователи скринридеров не могут использовать соответствующие сочетания клавиш. В таком случае на длинной странице приходится перемещаться табами или стрелками, чтобы найти нужную информацию.
Заголовки также помогают визуально разбить контент и улучшить читабельность. Кроме заголовков, пользователи скринридеров могут перемещаться на странице по ссылками, спискам и ориентирам WAI-ARIA.
Недоступные веб-формы
Большинство веб-сайтов так или иначе используют формы. Будь то поиск товара или форма обратной связи. Но если эти формы не маркированы или маркированы неправильно, то мы не можем их использовать.
Например, если поле поиска не помечено, то пользователи скринридеров понятия не имеют о назначении этого поля. Это означает, что люди, использующие программы чтения с экрана, не могут получить доступ к тем же функциям.
Формы обратной связи — это эффективный способ для клиентов связаться с вашей компанией. И для пользователей скринридеров нет ничего более неприятного, чем неправильно помеченные эти формы.
Особенно использование капчи. Если она без звука, то мы не можем самостоятельно заполнить такую форму. Мне часто приходится прибегать к помощи зрячего человека, но такая возможность есть не у всех.
Автоматическое воспроизведение аудио и видео
Большинство людей знает, насколько раздражает веб-страница с громкими рекламными объявлениями, которые внезапно включаются на воспроизведение. Но для пользователей скринридеров ситуация ещё хуже. Автоматическое воспроизведение видео или аудио может заглушить звук скринридера. Это затрудняет поиск кнопок паузы или остановки.
(И если эти кнопки не помечены, то для меня практически невозможно быстро остановить видео, что дополнительно раздражает). Если я не могу остановить звук или видео, я обычно закрываю страницу.
Решение проблемы? Убедитесь, на вашем сайте нет автоматического воспроизведения видео или аудио. Если вы действительно хотите опубликовать видео, убедитесь, что звук выключен и пользователь может остановить воспроизведение или скрыть медиаплеер.
Эти проблемы могут показаться незначительными для зрячих. Но для меня это разница, могу я взаимодействовать с сайтом или нет. И очень важно реализовать их правильно.
Скринридеры
Что такое скринридеры, как они устроены и работают, почему для них важна семантическая вёрстка и как их тестировать.
Время чтения: 13 мин
- Кратко
- Устройство
- Виды скринридеров
- Как работают скринридеры
- Accessibility API
- Дерево доступности
- Татьяна Фокина советует
Обновлено 21 октября 2022
Сайтами и приложениями пользуются разные люди. Кто-то может это делать с любого устройства, а другим нужны вспомогательные технологии (assistive technology). Это такие программы и устройства, которые упрощают взаимодействие пользователей с особыми потребностями с контентом. К примеру, выносные кнопки, трекболы, брайлевские дисплеи, экранные лупы и скринридеры.
Одна из самых популярных вспомогательных технологий — скринридеры ��
Кратко
Скопировать ссылку на секцию «Кратко» Скопировано
Скринридер (screen reader) — программа, которая превращает контент интерфейсов в речь или шрифт Брайля. Другие названия — программа экранного доступа или чтения, программа чтения с экрана и экранное считывающее устройство.
Они нужны людям со слепотой и слабовидящим, а также пользователям с когнитивными особенностями, которым легче воспринимать информацию на слух. Например, людям с дислексией.
Слабовидящие пользователи могут сочетать скринридеры с другой вспомогательной технологией — экранной лупой (screen magnification). Она увеличивает контент на экране и тоже его озвучивает, если это нужно.
Устройство
Скопировать ссылку на секцию «Устройство» Скопировано
Скринридеры состоят из двух частей:
- Программная оболочка — интерфейс программы.
- Движок синтеза речи — способ преобразования текста в речь.
Интерфейсы могут быть написаны на различных языках программирования и поддерживать разные функции, шорткаты (сочетания клавиш), жесты и настройки.
Движки тоже могут отличаться, но чаще всего используют формантный синтез речи (Formant Text-to-Speech). Он основан на искусственных звуках, которые имитируют человеческую речь. Плохо передаёт эмоции, зато тексты зачитываются на любой скорости без потери качества. Это важно, ведь многие люди слушают интерфейсы с высокой скоростью.
Пользователи могут не только изменить движок или скорость речи, но ещё выбрать другие настройки пунктуации, объёма объявлений, голоса, способы навигации и так далее.
Виды скринридеров
Скопировать ссылку на секцию «Виды скринридеров» Скопировано
Операционные системы тесно связаны со скринридерами, поэтому для каждой есть свои программы чтения с экрана:
- Windows — JAWS (платный и скачиваемый), NVDA (бесплатный и скачиваемый) и Narrator (бесплатный и предустановленный).
- macOS и iOS — VoiceOver, предустановлен.
- Android — TalkBack, предустановленный.
- Linux — Orca, тоже установлен по умолчанию в системе.
- Chrome OS — ChromeVox, предустановленный. Можно скачать как расширение в браузеры на Chromium.
Более полный список можно найти в Википедии.
У скринридеров разная популярность среди пользователей, как у браузеров. Следить за статистикой можно через ежегодные опросы пользователей WebAIM. Это американская компания, которая занимается доступностью.
В лидеры чаще всего попадают:
- JAWS или NVDA и Chrome. Периодически меняются местами.
- Десктопный и мобильный VoiceOver и Safari.
- TalkBack и Chrome.
Эта статистика полезна для тестирования и помогает понять, в каких скринридерах лучше тестировать в первую очередь.
Как работают скринридеры
Скопировать ссылку на секцию «Как работают скринридеры» Скопировано
Скринридеры могут озвучить любой контент на странице. Например, текст из параграфов и заголовков, списки, альтернативные описания изображений, ссылки, переключатели и другие интерактивные элементы. Также они озвучивают роли элементов и как с элементом можно взаимодействовать.
Программа не берёт контент сразу из вкладки браузера. Это происходит через посредника — Accessibility API (Accessibility Application Programming Interface). В свою очередь, браузеры передают Accessibility API данные об элементах со страницы в виде дерева доступности (acessibility tree).
Скринридеры могут взаимодействовать и с другими API, но давайте подробнее разберёмся с Accessibility API и деревом доступности.
Accessibility API
Скопировать ссылку на секцию «Accessibility API» Скопировано
Это набор интерфейсов операционных систем, который передаёт скринридерам из браузеров информацию о пользовательских интерфейсах. Если точнее, то о структуре документа, семантике, зависимостях внутри контента и о его состояниях.
Ещё Accessibility API получает от браузеров сообщения о событиях на странице, обрабатывает их и помогает скринридерам на них реагировать. Это может быть всплытие окна с ошибкой, открытие или закрытие выпадающего списка или выбор чекбокса.
Есть несколько реализаций Accessibility API.
- Windows: Microsoft Active Accessibility (MSAA), расширяющий его IAccessible2 (IA2) и более новый UI Automation (UIA).
- macOS, iOS: NSAccessibility (AXAPI).
- Linux: Assistive Technology Service Provider Interface (AT-SPI).
Браузеры умеют поддерживать сразу несколько API.
Нет прямого способа отследить количество пользователей скринридеров, т. к. браузеры не хранят информацию о взаимодействии с Accessibility API. Это не баг, а фича для конфиденциальности данных.
Дерево доступности
Скопировать ссылку на секцию «Дерево доступности» Скопировано
Это представление элементов документа в виде дерева на основе DOM (Document Object Model). Похоже на DOM-дерево, только состоит не из HTML-элементов, а из доступных объектов (accessible object).
Дерево доступности не полностью копирует DOM-дерево. Например, в него не попадают скрытые элементы с display : none , visibility : hidden , атрибутом hidden или декоративные <div> .
Доступный объект включает:
- Роль (role). Она соответствует типу элемента. Например, есть роли button , link или banner .
- Имя (name), если есть. Его также называют доступным именем (accessible name). Помогает лучше понять, что это за объект и его цель. Обычно озвучивается при фокусе. Оно берётся из текстового содержимого тегов или атрибутов. К примеру, имя элемента <button>Зарегистрироваться< / button> — «Зарегистрироваться».
- Описание (description) и/или вспомогательный текст (helper text), если есть. Дополнение к имени. Озвучивается, если выбрана такая настройка в скринридере.
- Свойства и методы. Содержат детали о раскладке (layout) и возможных действиях. К примеру, можно ли изменить значение элемента или как-то иначе с ним взаимодействовать.
Во многие семантические теги роли уже встроены. Роль <a> — link , <header> — banner , <ul> — list . Полный список можно найти на странице с HTML-элементами и именами. Поэтому для доступности важна семантическая вёрстка. Если вместо <button> использовать <div> с событием onclick , то у него не будет роли кнопки и её поведения. Пользователи скринридеров не узнают, что элемент кликабельный.
Посмотреть на дерево доступности можно в инспекторах браузеров во вкладке с доступностью. Например, так выглядит <img> в виде объекта дерева в Firefox. У него роль graphic (в Chrome будет img ), а имя — это описание картинки из атрибута alt .
Роли, имена и поведение элементов можно явно задавать и изменять с помощью ARIA-разметки (Accessible Rich Internet Applications). Это вспомогательная техника для создания более доступного контента для скринридеров. Расширяет возможности HTML с помощью специальных атрибутов и ролей.
Одно из главных правил её использования — стараться не использовать ARIA. Так что она пригодится, когда не хватает возможностей HTML. К примеру, для сложных интерактивных элементов — вкладок, выпадающих списков, модальных окон или оповещений об ошибках. В этом случает ARIA-атрибуты и JavaScript сделают поведение контрола понятным и предсказуемым.
Как взаимодействуют браузеры, скринридеры и Accessibility API
Скопировать ссылку на секцию «Как взаимодействуют браузеры, скринридеры и Accessibility API» Скопировано
Представим, что пользователь скринридера добрался до кнопки «Отправить»:
- Сначала скринридер запрашивает информацию о кнопке.
- Accessibility API получает запрос и передаёт его браузеру.
- Браузер проверяет DOM и находит нужный элемент и его стили.
- Теперь браузер может преобразовать элемент из DOM в понятный формат для Accessibility API. Это и есть объект из дерева доступности с именем и ролью. После этого браузер отдаёт его API.
- API возвращает эту информацию скринридеру.
- Скринридер объявляет: «Отправить, кнопка». Ура!
Теперь пользователь решил нажать на кнопку, чтобы что-то отправить:
- Скринридер вызывает метод из Accessibility API.
- Accessibility API идёт к браузеру и сообщает о вызове метода.
- Браузер ищет и обрабатывает событие с учётом того, есть ли обработчик события.
- Представим, что на сайте есть скрипт, который отслеживает события. В этом случае он выполняется, и происходит нужное действие при клике на кнопку.
Особенности навигации по контенту
Скопировать ссылку на секцию «Особенности навигации по контенту» Скопировано
Навигация со скринридерами по страницам и экранам отличается от обычной.
Клавиатурный фокус устанавливается только на интерактивных элементах. Например, на кнопках и ссылках. Пользователи переходят от одного элемента к другому и так перемещаются по интерфейсу.
Скринридеры при навигации с клавиатуры тоже могут устанавливать фокус на интерактивных элементах и перемещаться по ним, делая при этом объявления. Но это не самый удобный способ навигации для людей, которые не видят интерфейс. Поэтому у пользователей скринридеров есть другой, более удобный вариант — навигация по неинтерактивным элементам. С помощью специальных шорткатов в разных скринридерах открываются списки элементов со страницы. Так можно перемещаться по заголовкам, параграфам, строкам, ориентирам (landmark regions) и другим элементам. Один из самых популярных способов такой навигации — заголовки.
На скриншоте в VoiceOver открыт список всех заголовков из статьи на Википедии.
Пользователи мобильных скринридеров для перемещения по странице проводят пальцем по экрану, слушают объявления и так проходят через все элементы. Для взаимодействия с элементом нужно два раза тапнуть по экрану, а для перехода от одного к другому — свайпнуть вправо или влево. В мобильных скринридерах с помощью жестов тоже можно открыть навигацию по заголовкам, строкам, словам или ссылкам.
Дополнительно скринридеры могут зачитывать всё подряд.
Из видео Молли Бёрк вы узнаете, как выглядит на практике навигация с помощью VoiceOver на телефоне и ноутбуке.
Тестирование
Скопировать ссылку на секцию «Тестирование» Скопировано
У браузеров и скринридеров разная поддержка HTML, CSS и ARIA. Из-за этого объявление контента может отличаться, а где-то могут попадаться специфическое поведение или баги.
Возьмём для примера список со ссылками из демки и послушаем его в разных скринридерах.
- NVDA 2021.2 и Chrome 95: «Список из 3 элементов. Рыбы, ссылка. Пёсели, ссылка. Лягухи, ссылка».
- JAWS 2022 и Chrome 95: «Список из 3 элемента. Рыбы, ссылка. Пёсели, ссылка. Лягухи, ссылка».
- TalkBack на Android 10 и Firefox 94.1: «Рыбы, элемент списка, 2 из 3. Роль «список», 3 пункта. Пёсели, элемент списка, 3 из 3. Лягухи, элемент списка, 4 из 3». Объявляет информацию об элементах на английском, не зачитывает роль ссылки и неправильно считает элементы списка (баг).
- VoiceOver и Safari 15.1: «Рыбы, ссылка. Пёсели, ссылка. Лягухи, ссылка». Не объявляет, что это список из трёх элементов из-за свойства list — style со значением none . Оно сбрасывает семантику списка для этого скринридера.
Чтобы не столкнуться с неожиданной проблемой во время тестирования, можно заранее узнать о поддержке HTML и ARIA скринридерами:
-
. Can I Use в мире доступности. с результатами тестирования совместимости вспомогательных технологий.
Ручное тестирование находит больше проблем с доступностью для скринридеров, чем автоматические инструменты. Для него требуются определённые знания, навыки и опыт, но есть несколько основных советов:
- Навигация по интерфейсу с клавиатуры найдёт многие проблемы до тестирования со скринридерами.
- Тестируйте минимум в одном скринридере на поддерживаемых платформах. Выбрать популярные виды помогут опросы пользователей WebAIM.
- Проверяйте интерфейсы не только в последних версиях скринридеров и браузеров, но и в более ранних. Пользователи с особыми потребностями не так быстро обновляют программы.
- Обращайте внимание на комбинации скринридеров и браузеров. Если программа ведёт себя странно только в одном браузере, то это могут быть особенности совместимости или баг.
У разных скринридеров есть свои шорткаты и жесты, о которых полезно знать при тестировании:
Не обязательно тестировать с реальными скринридерами. Это можно сделать в BrowserStack и в специальном сервисе от Assistiv Labs.
Учитывайте, что реальные пользователи используют скринридеры постоянно и выработали особенные паттерны взаимодействия с интерфейсами. К тому же, они слушают контент на очень высокой скорости. И это быстрее, чем двойная скорость на YouTube! Так что ручное тестирование поможет обнаружить основные проблемы, но полностью не заменит пользовательское.
Выводы
Скопировать ссылку на секцию «Выводы» Скопировано
Вспомогательные технологии важны для многих людей, а для кого-то это единственный способ взаимодействовать с сайтом. Скринридер — одна из самых популярных разновидностей таких технологий.
Скринридер озвучивает контент интерфейсов и помогает пользователям проходить через него разными способами. Это могут быть интерактивные и неинтерактивные элементы.
Озвучивать контент скринридерам помогают Accessibility API и браузеры, которые создают дерево доступности. Часть элементов попадает в дерево вместе со встроенными ролями, доступными именами, дополнительным описанием и способами взаимодействия с ними.
У разработчиков уже есть несколько клёвых инструментов, чтобы сделать доступный интерфейс для скринридеров. Это HTML, CSS, иногда ARIA и JavaScript.
Не всегда получается сразу написать хороший интерфейс. Здесь на помощь приходит тестирование, особенно ручное.
Больше узнать о скринридерах помогут эти ссылки:
На практике
Скопировать ссылку на секцию «На практике» Скопировано
Татьяна Фокина советует
Скопировать ссылку на секцию «Татьяна Фокина советует» Скопировано
�� Сделать сайт базово доступным для скринридеров лучше всего с помощью семантической вёрстки. Для этого не нужно делать отдельную версию для пользователей со слепотой и слабовидящих или использовать оверлей. Это дешевле, лучше для пользователей и безопаснее с точки зрения соблюдения законов о доступности. Например, так не будут нарушены Раздел 508 американского закона о реабилитации 1973 года или Европейский стандарт EN 301 549.
�� Иногда CSS-свойства могут влиять на структуру. В статье уже упоминались display : none и visibility : hidden , которые скрывают от скринридеров элементы. И также list — style : none , которое отменяет семантику списка в VoiceOver. Есть и другие коварные свойства:
- width : 0 и height : 0 тоже убирают элемент из дерева доступности.
- display : table изменяет роль на table .
- text — transform : uppercase превращает в ранних версиях VoiceOver слова в акронимы. Например, текст кнопки «ВОЙТИ» он прочтёт с паузами между буквами.
- В дерево доступности попадает содержимое псевдоэлементов : : before и : : after .
А вот свойство order влияет только на визуальное отображение элементов и не изменяет порядок табуляции и объявления элементов.
�� Чтобы таблица была доступна для скринридеров, не забывайте использовать тег <th> . В него оборачиваются заголовки ячеек или строк. Он нужен по двум причинам:
- Если у таблицы нет <th> , то она не получает роль table и становится для скринридеров декоративной таблицей для раскладки.
- Так пользователям будет проще перемещаться по ней.
Улучшить таблицы для скринридеров помогут дополнительные подписи. Например, в <caption> .
�� Когда нужно скрыть неинтерактивный элемент только от скринридеров, используйте атрибут aria — hidden . В этом примере скрываем эмодзи-буллит внутри параграфа.
Приём полезен, когда таких буллитов много и их названия плохо подходят к тексту. Довольно утомительно слушать через каждые пару секунд «Голова единорога». При этом эмодзи остаются видны остальным пользователям.
�� Используйте вспомогательный класс .visually — hidden или .vh , если хотите визуально скрыть элемент, но оставить его для скринридеров.
Если поддерживаете старые браузеры, используйте вместе с clip — path устаревшее свойство clip : rect ( 0 0 0 0 ) .
Так можно скрыть <h1> , если его нет в макете, или добавлять для кнопок и ссылок с иконками или картинками тексты.