screen reader text что это
WordPress.org
The Accessibility Accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team provides accessibility expertise across the project to improve the accessibility of WordPress core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and resources.
The WordPress Accessibility Coding Standards state that “All new or updated code released in WordPress must conform with the Web Content Accessibility Guidelines 2.1 at level AA.”
Find out how you can help!
For questions or support related to WordPress & accessibility, please visit the WordPress Accessibility forum.
Learn how to design, develop, and write accessible code in our Handbook – best practices.
Chapters
The CSS class screen-reader-text
Topics
Use # Use
The screen-reader-text class is used:
The CSS CSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. class screen-reader-text is a WordPress Generated Class. Each theme should have these styles in its CSS.
The :focus style is primarily used by skip links. The colors, borders and padding of the focus style can be adjusted to match the styling of the theme. The styles defined below are those used by WordPress core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for Skip Links.
If you’re using the class ‘.screen-reader-text’ on any other focusable element (buttons, links, or form fields), then these focus styles will also apply. If this is the case, you may need to change the positioning rules, depending on the location of the focusable element.
The CSS # The CSS
The below CSS will hide elements visually but keep them available to screen readers.
Explanation of some of these CSS properties # Explanation of some of these CSS properties
Note: display: none; and visibility: hidden; hide text from screen, but also for a screen reader, so they can’t be used to give extra information to screen reader users.
Practical examples # Practical examples
Invisible text to make a link meaningful out of context:
A caption of a table:
A heading to make the heading structure meaningful and understandable. This also prevents an overload of H2s and gives the heading structure more context:
Note: If you include screen-reader-text as a part of a longer string in your WordPress theme, make sure the construction is translatable as a whole string (see I18n for WordPress Developers), because the word order may vary in different languages.
Доступность – во главу угла: как создать доступные WordPress-темы
Доступность – важная черта современной веб-разработки. Мы, создатели тем WordPress, несем свою ответственность за то, чтобы сделать темы доступными для всех пользователей на всех устройствах. В данной статье я приведу несколько простых подсказок по поводу того, как создать более доступные темы WordPress.
Это – не всеобъемлющее руководство по доступности. Вы не станете экспертом в сфере доступности после прочтения статьи. Однако я хотел бы поделиться своим опытом, который я получил, создавая доступные темы WordPress. Хотелось бы надеяться, что это позволит кому-либо создавать более доступные темы, и мы сможем делиться идеями по поводу того, как сделать сеть комфортным местом для всех нас.
Большую часть своего опыта я получил от таких экспертов, как Джо Долсон и Дэвид Кеннеди. Они оба помогают команде доступности WordPress и любезно отвечают на вопросы в Github и Twitter. Наша цель – понять основы доступности, а также узнать, как подготовить темы к тому, чтобы они получили официальную метку accessibility-ready.
Что такое «доступность» и почему мы должны беспокоиться о ней?
Веб-доступность означает, что все пользователи – включая пользователей с ограниченными возможностями – могут просматривать веб-сайты с любых устройств. В данной статье я сконцентрируюсь в основном на людях с ограниченными возможностями (со зрительными, слуховыми, физическими, вербальными, когнитивными и неврологическими отклонениями). Мы можем улучшить наши сайты и позволить этим людям использовать наш сайт, перемещаться по нему и взаимодействовать с ним.
Вильями Салминен рассказал о различных методах ввода, а также о производительности, в своей статье, которая называется «The Many Faces of the Web»:
«Если брать более крупный масштаб, мы должны сделать наши сайты доступными для всех. Чтобы эти сайты работали с разными техниками ввода, такими как сенсорные дисплеи, мышь, клавиатура или голосовое управление. Чтобы сайты быстро загружались. Чтобы они предлагали всем доступ к обширной сети связанных между собой вещей. И если мы не станем бороться за это, какой смысл тогда вообще улучшать сеть?»
Если все это вас не убеждает, вы должны хотя бы подумать о деньгах! Брэд Фрост раскрыл это в своей статье о доступности и маломощных устройствах:
«Хотите получить больше клиентов?» На этот вопрос я всегда слышу ответ: «Да». Когда я спрашиваю: «Хотите ли вы, чтобы ваш сайт загружался молниеносно?», то слышу в ответ: «Да». Доступность и производительность – невидимые аспекты опыта взаимодействия, однако они должны быть рассмотрены даже в том случае, когда они не являются явными целями проекта.
Сделайте опыт взаимодействия в сети более доступным и производительным – заработайте больше!»
Давайте начнем с обязательных требований для создания доступного сайта.
.screen-reader-text для скрытия текста
Следующий фрагмент является рекомендуемым методом для добавления класса screen-reader в стили вашей темы. Вы можете также воспользоваться темой Underscores или другими рекомендуемыми методами:
Вы можете стилизовать :focus по-другому, однако этого кода хватит для начала.
Заголовки и их иерархия
Заголовки – важный способ навигации по вашему сайту. Именно на них ориентируются пользователи, которые используют программы чтения с экрана. Обычные пользователи также могут быстрее перемещаться по сайту, если он имеет структурированные заголовки.
Однако заголовки и структура заголовков могут вылиться в проблему, с чем я и сам столкнулся на своем опыте. Должны ли мы использовать единственный h1 элемент на каждой странице? Может быть, лучше будет, если их будет несколько? Что по поводу других заголовков: H2, H3 и т.д.?
Если учитывать стандарты HTML5, то на одной странице может быть несколько заголовков h1, однако важно, чтобы они не противоречили выбранной вами иерархии заголовков. Вот пример мой структуры заголовков для блога:
И для отдельных записей:
Проблема в том, что иерархия заголовков нарушается, если пользователь вводит заголовок h1 в текст статьи или смешивает заголовки между собой. Плагины, которые выводят разметку, также могут нарушать иерархию.
Прочитайте текст про иерархию заголовков и придерживайтесь этой иерархии в своей теме.
Роли ARIA
Роли ARIA позволяют программно определить разделы страницы. Это дает возможность пользователям ассистивных технологий переходить к различным секциям страницы.
Есть следующие общие роли:
Если одна и та же роль представлена на странице несколько раз, вы должны задать aria-label для этой роли:
Старайтесь не использовать слишком много разных ролей ARIA. Иначе пользователи программ чтения с экрана вряд ли смогут легко перемещаться по вашему сайту. От десяти до пятнадцати ролей вполне достаточно.
Пример того, как будет выглядеть HTML-структура с ARIA ролями:
На скриншоте представлен сайт инспектора ARIA:
Текст ссылок
Представьте себе, что ваши архивы блога используют десятки ссылок Read More. Пользователям программ чтения с экрана будем неудобно перемещаться по этим ссылкам. Нужно стараться обходить повторяющиеся текстовые строки, не дающие никакого контекста.
Использование функции the_content()
Использование функции the_excerpt()
По умолчанию функция the_excerpt() добавляет многоточие в квадратных скобках в самый конец цитат. Мы можем заменить его на что-то подобное тому, что мы использовали в примере с the_content, при помощи фильтра excerpt_more:
У вас может быть другая структура HTML, однако теперь вы понимаете, как добавить заголовок записи после стандартного текста.
Дескриптивный текст ссылки
Элементы управления
Пусть ссылки остаются ссылками, кнопки – кнопками, блоки div – блоками div, span’ы – span’ами, чтобы добиться совместимости с клавиатурой и взаимодействия с программами чтения с экрана. Ссылки в статье, div’ы и span’ы не должны быть кнопками.
К примеру, для переключения к меню должна использоваться кнопка – не ссылка, не div и не span.
Вы можете также стилизовать кнопку с помощью CSS. Многие разработчики тем добавляют текстовую иконку, указывающую на меню, которая часто называется «гамбургером». Плохой способ добавления текстовой иконки:
Текстовые иконки сами по себе не несут никакого смысла для программ чтения с экрана. Вообще, лучшая иконка – это текстовый label.
Вместо этого вы можете использовать следующий код:
Затем уже добавьте текстовую иконку с помощью псевдо-элемента, такого как, к примеру, #nav-toggle::before.
Зрячие пользователи будут видеть только иконку гамбургера, а пользователи программ чтения с экрана поймут, что этот элемент управления предназначен для меню.
Навигация с клавиатуры
На ThemeShaper есть прекрасная статья, посвященная клавиатурной доступности. Говоря коротко, пользователи должны быть в состоянии взаимодействовать с вашим сайтом при помощи одной лишь клавиатуры. К примеру, пользователи с плохим зрением или с нарушенной моторикой используют клавиатуру практически всегда.
Я предлагаю вам отставить в сторону мышь и попробовать протестировать свой сайт. Сможете ли вы переходить по ссылкам, выпадающим меню, элементам управления форм с помощью клавиш tab и shift + tab? Enter может использоваться для активации ссылок, кнопок и других интерактивных элементов.
:focus очень важен
Обратите внимание, что по умолчанию фокус могут получать только ссылки, кнопки и поля форм. Именно по этой причине я говорил вам, что ссылки должны быть ссылками, а кнопки – кнопками. Не пытайтесь заместить их div’ами или span’ами. Элементы должны иметь визуальные эффекты, позволяющие отразить их состояние, когда пользователи перемещаются по вашему сайту с помощью клавиатуры. Именно для этих целей и применяют :focus.
Она отключает стили контура для всех ссылок! Вот это будет в разы лучше:
Теперь пользователи могут насладиться визуальным эффектом – контуром из точек вокруг ссылки – когда ссылка будет в фокусе. Вы можете стилизовать ссылки по-другому, однако не убирайте стилизацию совсем. Помните, что вы можете, конечно, стилизовать кнопки с помощью CSS – к примеру, сменить фон во время :focus.
Убедитесь в том, что цвета – не единственный способ подачи важной информации. Они помогут людям с плохим зрением воспринять визуальные эффекты.
Выпадающие меню и клавиатурная доступность
Пытались ли вы когда-либо получить доступ к вашим подменю в выпадающем меню с помощью одной клавиатуры? Если вы не можете эффективно выполнить это, давайте посмотрим, как это улучшить. Начнем мы с того, что приведем текущие требования к навигационным меню.
Неправильно: выпадающие навигационные меню скрыты с помощью display:none; и выводятся на экран во время :hover
Удовлетворительно: Навигационные меню скрыты с помощью position: absolute; и выводятся на экран во время :hover и :focus, также по ним можно перемещаться при помощи tab.
Идеально: Выпадающие навигационные меню скрыты с помощью position: absolute;, выводятся на экран во время :hover, :focus, по ним можно перемещаться при помощи tab, а также при помощи стрелочек на клавиатуре.
Опять же, тема Underscores содержит прекрасный пример разметки выпадающих меню, по которым можно перемещаться с помощью клавиши Tab. Я надеюсь, что в ней появится поддержка стрелочек в ближайшем будущем. Я обычно использую Responsive Nav для создания адаптивных, доступных меню.
Чтобы включить поддержку клавиатуры для выпадающих меню, нам понадобится JavaScript. Для ознакомления посмотрите файл navigation.js. Вот основная идея:
Есть и другие аспекты, которые нам нужно рассмотреть для создания более доступных меню:
Здесь можно написать целую статью по поводу созданию доступных адаптивных меню, поэтому мы двинемся дальше.
Контрасты
Цветовой контраст – то, ради чего мы пойдем на компромисс в нашем веб-дизайне. Нам нужно обеспечить достаточный контраст между цветом текста и фона, чтобы текст могли прочитать люди с умеренно плохим зрением. Есть много красивых тем, которые используют, к примеру, светло-серые цвета, однако вряд ли они выполнят требования цветового контраста.
Авторы тем должны гарантировать, что все цветовые контрасты фона/текста находятся на уровне AA коэффициента контрастности (4.5:1), который определен в Web Content Accessibility Guidelines (WCAG) 2.0 для яркости цвета.
Я протестировал цветовой контраст с помощью специального инструмента Джо Долсона. Доступность не сделает ваш сайт уродливым или некрасивым, вы должны это помнить! Однако доступность выставляет некоторые требования, которые мы должны соблюдать. У Аарона Джорбина было прекрасное выступление по поводу теории цвета и доступности на WordCamp Chicago 2014.
Ссылки «пропустить»
Базовый контент веб-сайта обычно находится не в самой верхней области страницы. Над ним располагаются разные выпадающие меню, формы поиска, а также другая информация. Пользователям клавиатуры или программ чтения с экрана будет раздражать тот факт, что им нужно всякий раз перемещаться вниз по этому многочисленному содержанию, чтобы перейти наконец к вашему основному контенту. Именно по этой причине темы должны включать в себя ссылку «пропустить», которая поможет перейти сразу к основному контенту. Такая ссылка обычно добавляется в header.php после body или первого тега div.
Также нужно перенести фокус на область основного контента страницы, когда активируется ссылка «пропустить». Я считаю, что до сих пор в WebKit-браузерах осталась ошибка, которая препятствует переносу фокуса. Тема Underscores дает хороший пример этого переноса.
Формы
Стандартные формы комментариев и поиска в WordPress являются доступными, однако вам нужно настроить их. Я уже допускал одну ошибку, связанную с ними, в прошлом.
Если вы используете произвольный файл searchform.php в своей теме, задавайте всегда соответствующие подписи полей (label); не устанавливайте только текстовые иконки для кнопки Submit!
Также следите за набором паттернов для создания доступных WordPress-тем. Как, к примеру, доступная форма комментариев, выполненная при помощи JavaScript и ARIA.
Изображения и альтернативный текст
Мне не удалось добавить альтернативный текст (атрибут ALT) к моим изображениям в контексте – по крайней мере, хороший текст. Я обещаю улучшить это! Незрячие люди вряд ли смогут разглядеть ваши изображения. Компьютеры и программы чтения с экрана не могут понять, что представляет собой изображение. Вот почему и был создан ALT атрибут, а также руководства по изображениям.
Медиа-элементы
Слайдеры и карусели не должны включать по умолчанию. То же самое относится к видео и аудио. Это по большей части территория плагинов, однако это очень важно помнить, особенно учитывая тот факт, что в сети все чаще встречается автоматическое воспроизведение этого контента.
Не поддерживаются
Есть несколько вещей, которые не поддерживаются
Создание доступных тем
Мы изучили требования для получения официальной метки accessibility-ready при отправке тем в каталог WordPress. Все было не так уж и сложно!
Я советую вам попробовать создать доступную тему, когда вы начнете свой следующий проект. Либо изучите свой сайт и добавьте к нему небольшие улучшения, как, к примеру, улучшенная клавиатурная поддержка. Надеюсь, что эта статья помогла вам понять, что такое доступность и почему очень важно ее учитывать.
WordPress.org
The Accessibility Accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team provides accessibility expertise across the project to improve the accessibility of WordPress core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and resources.
The WordPress Accessibility Coding Standards state that “All new or updated code released in WordPress must conform with the Web Content Accessibility Guidelines 2.1 at level AA.”
Find out how you can help!
For questions or support related to WordPress & accessibility, please visit the WordPress Accessibility forum.
Learn how to design, develop, and write accessible code in our Handbook – best practices.
Hiding text for screen readers with WordPress Core
How to use screen-reader text
The purpose of screen-reader targeted text is to provide additional context for links, document structure, and form fields. Usually, that context is readily available to a sighted user because of visual cues and familiar patterns.
Screen reader text has many specific applications. One common example of this is a link that says “read more”. On its own, this link lacks context in a screen reader. While a sighted visitor can easily identify the context from the surrounding text and images, a screen reader user benefits from including the title of the target in the link:
Defining the class
The clip method is used by WordPress core, and is the preferred method. The ‘clip’ property has been deprecated, but its replacement ‘clip-path’ has poor browser support, so providing both is necessary.
Note: this CSS CSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. is updated on October 2017
The absolute positioning method is simpler, but requires you to provide alternate styles for right-to-left and left-to-right languages:
Bring Hidden Text into Focus
In some cases, it’ll be necessary to bring your hidden text into view when it receives keyboard focus. This is relatively rare, and primarily effects Skip links, which need to be made visible for keyboard users. You shouldn’t apply a focus state on most screen reader text; if that text doesn’t need to be seen in order for the context to be understood by a sighted user, don’t make it visible on focus.
If you do need to bring screen reader text into focus, you can use these base styles to move the text into view when using the clip method:
Using the absolute positioning method, it’s simply a matter of changing the value of the left positioning so that the text is on screen.
Скринридеры
Что такое скринридеры, как они устроены и работают, почему для них важна семантическая вёрстка и как их тестировать.
Время чтения: 13 мин
Обновлено 20 декабря 2021
Сайтами и приложениями пользуются разные люди. Кто-то может это делать с любого устройства, а другим нужны вспомогательные технологии (assistive technology). Это такие программы и устройства, которые упрощают взаимодействие пользователей с особыми потребностями с контентом. К примеру, выносные кнопки, трекболы, брайлевские дисплеи, экранные лупы и скринридеры.
Одна из самых популярных вспомогательных технологий — скринридеры 🤖
Кратко
Скринридер (screen reader) — программа, которая превращает контент интерфейсов в речь или шрифт Брайля. Другие названия — программа экранного доступа или чтения, программа чтения с экрана и экранное считывающее устройство.
Они нужны людям со слепотой и слабовидящим, а также пользователям с когнитивными особенностями, которым легче воспринимать информацию на слух. Например, людям с дислексией.
Слабовидящие пользователи могут сочетать скринридеры с другой вспомогательной технологией — экранной лупой (screen magnification). Она увеличивает контент на экране и тоже его озвучивает, если это нужно.
Устройство
Скринридеры состоят из двух частей:
Интерфейсы могут быть написаны на различных языках программирования и поддерживать разные функции, шорткаты (сочетания клавиш), жесты и настройки.
Движки тоже могут отличаться, но чаще всего используют формантный синтез речи (Formant Text-to-Speech). Он основан на искусственных звуках, которые имитируют человеческую речь. Плохо передаёт эмоции, зато тексты зачитываются на любой скорости без потери качества. Это важно, ведь многие люди слушают интерфейсы с высокой скоростью.
Пользователи могут не только изменить движок или скорость речи, но ещё выбрать другие настройки пунктуации, объёма объявлений, голоса, способы навигации и так далее.
Виды скринридеров
Операционные системы тесно связаны со скринридерами, поэтому для каждой есть свои программы чтения с экрана:
Более полный список найдёте в Википедии.
У скринридеров разная популярность среди пользователей, как у браузеров. Следить за статистикой можно через ежегодные опросы пользователей WebAIM. Это американская компания, которая занимается доступностью.
В лидеры чаще всего попадают:
Эта статистика полезна для тестирования и помогает понять, в каких скринридерах лучше тестировать в первую очередь.
Как работают
Скринридеры могут озвучить любой контент на странице. Например, текст из параграфов и заголовков, списки, альтернативные описания изображений, ссылки, переключатели и другие интерактивные элементы. Также они озвучивают роли элементов и как с ним можно взаимодействовать.
Программа не берёт контент сразу из вкладки браузера. Это происходит через посредника — Accessibility API (Accessibility Application Programming Interface). В свою очередь, браузеры передают Accessibility API данные об элементах со страницы в виде дерева доступности (acessibility tree).
Скринридеры могут взаимодействовать и с другими API, но давайте подробнее разберёмся с Accessibility API и деревом доступности.
Accessibility API
Это набор интерфейсов операционных систем, который передаёт скринридерам из браузеров информацию о пользовательских интерфейсах. Если точнее, то о структуре документа, семантике, зависимостях внутри контента и о его состояниях.
Ещё Accessibility API получает от браузеров сообщения о событиях на странице, обрабатывает их и помогает скринридерам на них реагировать. Это может быть всплытие окна с ошибкой, открытие или закрытие выпадающего списка или выбор чекбокса.
Есть несколько реализаций Accessibility API.
Браузеры умеют поддерживать сразу несколько API.
Нет прямого способа отследить количество пользователей скринридеров, т. к. браузеры не хранят информацию о взаимодействии с Accessibility API. Это не баг, а фича для конфиденциальности данных.
Дерево доступности
Это представление элементов документа в виде дерева на основе DOM (Document Object Model). Похоже на DOM-дерево, только состоит не из HTML-элементов, а из доступных объектов (accessible object).
Доступный объект включает:
Роли, имена и поведение элементов можно явно задавать и изменять с помощью ARIA-разметки (Accessible Rich Internet Applications). Это вспомогательная техника для создания более доступного контента для скринридеров. Расширяет возможности HTML с помощью специальных атрибутов и ролей.
Одно из главных правил её использования — стараться не использовать ARIA. Так что она пригодится, когда не хватает возможностей HTML. К примеру, для сложных интерактивных элементов — вкладок, выпадающих списков, модальных окон или оповещений об ошибках. В этом случает ARIA-атрибуты и JavaScript сделают поведение контрола понятным и предсказуемым.
Как взаимодействуют браузеры, скринридеры и Accessibility API
Представим, что пользователь скринридера добрался до кнопки «Отправить»:
Теперь пользователь решил нажать на кнопку, чтобы что-то отправить:
Особенности навигации по контенту
Навигация со скринридерами по страницам и экранам отличается от обычной.
Клавиатурный фокус устанавливается только на интерактивных элементах. Например, на кнопках и ссылках. Пользователи переходят от одного элемента к другому и так перемещаются по интерфейсу.
Скринридеры при навигации с клавиатуры тоже могут устанавливать фокус на интерактивных элементах и перемещаться по ним, делая при этом объявления. Но это не самый удобный способ навигации для людей, которые не видят интерфейс. Поэтому у пользователей скринридеров есть другой, более удобный вариант — навигация по неинтерактивным элементам. С помощью специальных шорткатов в разных скринридерах открываются списки элементов со страницы. Так можно перемещаться по заголовкам, параграфам, строкам, ориентирам (landmark regions) и другим элементам. Один из самых популярных способов такой навигации — заголовки.
На скриншоте в VoiceOver открыт список всех заголовков из статьи на Википедии.
Пользователи мобильных скринридеров для перемещения по странице проводят пальцем по экрану, слушают объявления и так проходят через все элементы. Для взаимодействия с элементом нужно два раза тапнуть по экрану, а для перехода от одного к другому — свайпнуть вправо или влево. В мобильных скринридерах с помощью жестов тоже можно открыть навигацию по заголовкам, строкам, словам или ссылкам.
Дополнительно скринридеры могут зачитывать всё подряд.
Из видео Молли Бёрк узнаете, как выглядит на практике навигация с помощью VoiceOver на телефоне и ноутбуке.
Тестирование
У браузеров и скринридеров разная поддержка HTML, CSS и ARIA. Из-за этого объявление контента может отличаться, а где-то попадаться специфические поведение или баги.
Возьмём для примера список со ссылками из демки и послушаем его в разных скринридерах.
Чтобы не столкнуться с неожиданной проблемой во время тестирования, можно заранее узнать о поддержке HTML и ARIA скринридерами:
Ручное тестирование находит больше проблем с доступностью для скринридеров, чем автоматические инструменты. Для него требуются определённые знания, навыки и опыт, но есть несколько основных советов:
У разных скринридеров есть свои шорткаты и жесты, о которых полезно знать при тестировании:
Не обязательно тестировать с реальными скринридерами. Это можно сделать в BrowserStack и в специальном сервисе от Assistiv Labs.
Учитывайте, что реальные пользователи используют скринридеры постоянно и выработали особенные паттерны взаимодействия с интерфейсами. К тому же, они слушают контент на очень высокой скорости. И это быстрее, чем двойная скорость на YouTube! Так что ручное тестирование поможет обнаружить основные проблемы, но полностью не заменит пользовательское.
Выводы
Вспомогательные технологии важны для многих людей, а для кого-то это единственный способ взаимодействовать с сайтом. Скринридер — одна из самых популярных разновидностей таких технологий.
Скринридер озвучивает контент интерфейсов и помогает пользователям проходить через него разными способами. Это могут быть интерактивные и неинтерактивные элементы.
Озвучивать контент скринридерам помогают Accessibility API и браузеры, которые создают дерево доступности. Часть элементов попадает в дерево вместе со встроенными ролями, доступными именами, дополнительным описанием и способами взаимодействия с ними.
У разработчиков уже есть несколько клёвых инструментов, чтобы сделать доступный интерфейс для скринридеров. Это HTML, CSS, иногда ARIA и JavaScript.
Не всегда получается сразу написать хороший интерфейс. Здесь на помощь приходит тестирование, особенно ручное.
Больше узнать о скринридерах помогут эти ссылки:
На практике
Татьяна Фокина
🛠 Сделать сайт базово доступным для скринридеров лучше всего с помощью семантической вёрстки. Для этого не нужно делать отдельную версию для пользователей со слепотой и слабовидящих или использовать оверлей. Это дешевле, лучше для пользователей и безопаснее с точки зрения соблюдения законов о доступности. Например, так не будут нарушены Раздел 508 американского закона о реабилитации 1973 года или Европейский стандарт EN 301 549.
А вот свойство order влияет только на визуальное отображение элементов и не изменяет порядок табуляции и объявления элементов.
🛠 Чтобы таблица была доступна для скринридеров, не забывайте использовать тег
Приём полезен, когда таких буллитов много и их названия плохо подходят к тексту. Довольно утомительно слушать через каждые пару секунд «Голова единорога». При этом эмодзи остаются видны остальным пользователям.
, если его нет в макете, или добавлять для кнопок и ссылок с иконками или картинками тексты.
Добавим скрытый текст «Закрыть» для кнопки с SVG-иконкой.