Как проверить доступность приложения в стране

Обновлено: 05.01.2025

Поддержка этой версии Operations Manager прекращена. Рекомендуем перейти на Operations Manager 2019.

Шаблон мониторинга доступности веб-приложений позволяет создавать тесты отслеживания доступности для одного или нескольких URL-адресов веб-приложений и запускать эти тесты отслеживания из внутренних расположений. Помимо представлений состояний и предупреждений, состояние этих тестов можно отобразить на предоставленной панели мониторинга сопоставления и подробностей.

Сценарии

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

Внутренние расположения

У вас могут быть веб-приложения, которые всегда должны быть доступны во внутренних расположениях. Используйте шаблон мониторинга доступности веб-приложений, чтобы узнать, какие веб-приложения доступны из тех или иных внутренних расположений.

Мониторинг, выполняемый шаблоном мониторинга доступности веб-приложений

По умолчанию шаблон мониторинга доступности веб-приложений настраивает приведенные ниже возможности наблюдения. Вы можете изменить настройки монитора на странице изменения конфигурации шаблона мониторинга доступности веб-приложений.

Просмотр данных мониторинга

Все данные, собранные шаблоном мониторинга доступности веб-приложений, отображаются в папке Мониторинг доступности веб-приложений, вложенной в папку Мониторинг приложений в области навигации Наблюдение. Папка Мониторинг доступности приложений содержит представления по умолчанию и вложенные папки со сведениями о состоянии теста, состоянии веб-приложения и предупреждения, связанные с наблюдаемыми тестами. В представлении "Состояние теста" отображается состояние отдельных тестов. Состояние каждого объекта соответствует состоянию целевого объекта, имеющего наихудшее состояние работоспособности. Таким образом вы можете видеть наихудшее из всех состояний запущенных мониторов. Если для одного или нескольких тестов указана ошибка и при этом хотя бы один тест является работоспособным, возможно, возникла проблема с данным расположением теста. Если все компоненты находятся в неработоспособном состоянии, возможно, возникла проблема с самим веб-приложением.

Папка мониторинга доступности веб-приложений

Чтобы просмотреть состояние отдельных мониторов, откройте анализатор работоспособности для каждого теста.

Параметры мастера

При запуске шаблона мониторинга доступности веб-приложений вам требуется задать значения параметров, указанных в следующих таблицах. Каждая таблица представляет отдельную страницу мастера.

Общие

На странице Общие мастера доступны следующие параметры.

Параметр	Описание:
Имя	Введите понятное имя, используемое для шаблона и создаваемой вами группы тестов. Это имя отображается в консоли управления в представлении состояния веб-приложения и используется для папки в папке Мониторинг доступности веб-приложения. Примечание. После назначения имени и сохранения шаблона это имя нельзя изменить без удаления и повторного создания шаблона.
Описание:	Опишите шаблон. (Необязательный)
Выберите конечный пакет управления:	выберите пакет управления для сохранения представлений и конфигурации, созданных с использованием данного шаблона. Используйте для нового пакета управления то же имя, что и для группы тестов, чтобы вы могли легко сопоставить два этих имени. Можно использовать существующий пакет управления или создать новый. Дополнительные сведения о пакетах управления см. в статье о выборе файла пакета управления.

Объекты наблюдения

На странице What to Monitor (Объекты наблюдения) мастера доступны следующие параметры.

Отправная точка мониторинга

Выберите внутренние расположения для наблюдения за URL-адресами.

На странице Where to Monitor From (Отправная точка мониторинга) мастера доступны следующие параметры.

Параметр	Описание:
Внутренние расположения	Внутренние расположения, которые вы настраиваете для мониторинга.
Добавление или удаление	Добавьте или удалите внутренние расположения, за которыми вы хотите наблюдать.

Выбор внутренних расположений

Выберите внутренние расположения, из которых вы хотите отслеживать URL-адреса, указанные на странице What to Monitor (Объекты наблюдения). Щелкните "Добавить", чтобы добавить внутренние расположения, а затем найдите и выберите внутренние расположения, с которых вы хотите вести мониторинг.

На странице Выбор внутренних расположений мастера доступны следующие параметры.

Параметр	Описание:
Искать:	Параметр, отображающий тип расположений, поиск которых будет осуществляться. Вы можете выбрать агенты или пулы.
Фильтровать по части имени	Выполните фильтрацию поиска по внутренним расположениям.
Система поиска	Выполняйте поиск расположений, доступных для мониторинга. Доступные расположения отображаются в области "Расположение".
Where to monitor (Отправная точка мониторинга): Имя	Список внутренних расположений, из которых можно выполнять мониторинг.
Where to monitor (Отправная точка мониторинга): Расположение	Список расположений, из которых можно выполнять мониторинг.
Add	Добавьте выбранные внутренние расположения в область "Выбранные расположения". Это расположения, которые вы настраиваете как места для мониторинга в мастере.
Выбранные расположения: Имя	Это внутренние расположения, которые выбраны для мониторинга.
Выбранные расположения: Расположение	Список расположений, которые выбраны для мониторинга.

Просмотр и проверка тестов

Это сводка всех тестов, которые будут выполняться. Выберите внутреннее расположение и щелкните Запустить тест, чтобы проверить конфигурацию теста. Выберите "Изменить конфигурацию", чтобы изменить параметры по умолчанию для всех тестов в этом шаблоне.

На странице Просмотр и проверка тестов мастера доступны следующие параметры.

Параметр	Описание:
Искать	Поиск и возврат результатов для элементов в списке имен тестов, URL-адресов, расположений, агентов и пулов. Используйте это поле, чтобы найти конкретные тесты или наборы тестов, которые вы хотите проверить.
Имя теста	Имя теста.
URL-адрес	URL-адрес конкретного теста.
Агент или пул	Расположение агента или пула для внутренних тестов URL-адресов.
Запустить тест	Запустите проверочный тест для выбранных внутренних тестов.
Изменить конфигурацию	Откройте страницу изменения конфигурации, где вы можете изменить параметры для всех тестов в шаблоне, который вы создаете.

Окно "Результаты теста". Вкладка "Сводка"

На вкладке сводки по результатам теста мастера доступны следующие параметры.

Параметр	Описание:
Вкладка "Сводка"	Указано, правильно ли был обработан запрос теста, и отображается URL-адрес и расположение, использованные в тесте. Дополнительно. Отображаются конкретные тесты и результаты: код состояния, время разрешения DNS и общее время ответа.

Параметр

Описание:

Вкладка "Сводка"

Указано, правильно ли был обработан запрос теста, и отображается URL-адрес и расположение, использованные в тесте. Дополнительно. Отображаются конкретные тесты и результаты: код состояния, время разрешения DNS и общее время ответа.

Окно "Результаты теста". Вкладка "Подробности"

На вкладке Подробно окна "Результаты теста" в мастере доступны следующие параметры.

Окно "Результаты теста". Вкладка "Необработанные данные"

На вкладке Необработанные данные окна "Результаты теста" в мастере доступны следующие параметры.

Параметр	Описание:
Что отображается на этой вкладке	Отображаются все неформатированные данные, которые мы получаем с сайта. Если с сайтом возникла проблема, эти сведения могут помочь выяснить, что может быть не так с сайтом.

Изменение конфигурации для набора тестов

На странице Change Configuration for Test Set (Изменение конфигурации для набора тестов) мастера доступны следующие параметры.

Параметры на этой странице применяются ко всем тестам в шаблоне.

Сводка

Создание и изменение шаблонов мониторинга доступности веб-приложений

Изменение имеющегося шаблона мониторинга доступности веб-приложений

Откройте консоль управления под учетной записью с учетными данными "Дизайнер" в группе управления.
Щелкните рабочую область Создание и настройка.
На панели навигации Создание и настройка разверните узел Шаблоны пакета управления и выберите пункт Web Application Availability Monitoring (Мониторинг доступности веб-приложений).
В области Web Application Availability Monitoring (Мониторинг доступности веб-приложений) найдите шаблон, который вы хотите изменить.
Щелкните правой кнопкой группу тестов, которую требуется изменить, и выберите пункт Свойства.
С помощью вкладок перейдите на страницу параметров, внесите требуемые изменения, например перенастройка критериев для тестов в этой группе, а потом нажмите кнопку ОК.

Просмотр мониторов наблюдения за производительностью веб-приложений и собранных данных

После настройки наблюдения за приложениями, используйте указанные ниже три представления, которые помогут приобрести первоначальные навыки наблюдения.

Выпустив рабочую, альфа- или бета-версию приложения, можно выбрать для каждой из них страны, в которых вы хотите ее распространять.

Для чего нужен таргетинг по странам

Ниже описаны ситуации, в которых может пригодиться таргетинг по странам:

Если у вас есть рабочая версия приложения, вы можете запустить бета-версию в другой стране, не изменяя рабочую.
Если бета-версия приложения доступна в ряде стран, вы можете запустить рабочую версию только в некоторых из них.
Если рабочая версия приложения доступна в некоторых странах, а вам необходимо провести глобальное закрытое бета-тестирование.

Если бета- или рабочая версия приложения доступна в некоторых странах, а вам необходимо предоставить доступ тестировщикам для глобального альфа-тестирования.

Таргетинг по странам не применяется в этих случаях:

Для проведения внутреннего тестирования можно приглашать пользователей из любых стран. Если тестировщик находится в стране, где недоступна рабочая, альфа- или бета-версия приложения, он все равно получит APK-файл.

Как охватить подходящую аудиторию

Чтобы управлять доступностью версий по странам, необходимо понять, чем отличается доступность приложения от таргетинга по странам.

Доступность приложения

Доступность приложения – это доступность рабочей версии. Если в этом разделе выбрать страну, в ней будут доступны все последующие рабочие версии приложения.

Чтобы настроить доступность приложения, выполните следующие действия:

Откройте Play Console.
Выберите приложение.
Нажмите Выпуск > Рабочая версия > Страны/регионы.
Выберите необходимые страны.
- Если вы добавляете страну для платного приложения, автоматически добавляются новые цены. При необходимости можно изменить цены в местной валюте.
Опубликуйте обновление.

Примечание. Подробнее о том, как настроить поэтапное внедрение в определенных странах, рассказано здесь.

Таргетинг по странам

Вы можете настроить не только доступность рабочей версии, но и таргетинг по странам для альфа- и бета-версии. По умолчанию он соответствует параметрам доступности рабочей версии.

Внимание! Настроить доступность по странам для альфа- или бета-версии можно, только если соблюдается одно из этих условий:

В вашем приложении нет APK рабочей версии.
Для загруженного APK рабочей версии настроена хотя бы одна страна доступности.

Чтобы изменить доступность альфа- или бета-версии приложения, выполните следующие действия:

Откройте Play Console.
Выберите приложение.
Нажмите Выпуск > Тестирование > Открытое или закрытое тестирование > Страны/регионы.
Выберите, какие страны вы хотите добавить или удалить.
- Проверьте таблицу со странами.
  - Синхронизировано с рабочей версией. Доступность по странам для альфа- или бета-версии соответствует доступности рабочей версии.
  - Настроить доступность. Можно задать разную доступность по странам для рабочей, альфа- и бета-версии.
Обновите доступность по странам.
Опубликуйте обновление.

Пример

Если добавить или удалить страну на странице Цены и распространение приложения, эта страна автоматически добавляется или удаляется для всех версий, которые синхронизируются с рабочей (описано выше).

Если вы отдельно настраивали доступность для альфа- или бета-версии на странице Версии приложений, необходимо добавить или удалить страну отдельно для этой версии.

Чтобы добавить страну только для бета-версии, выполните одно из следующих действий:

На странице Цены и распространение отметьте страну доступной, но не загружайте APK рабочей версии. Бета-версия приложения наследует эту доступность по умолчанию.
На странице Цены и распространение выберите хотя бы одну страну, доступную для рабочей версии приложения. Затем настройте таргетинг по странам для бета-версии на странице Версии приложения.

Чтобы удалить страну только для бета-версии, выполните следующие действия:

Тестирование мобильной доступности с учётом правил A11Y — тема, которая обсуждается всё чаще. И обсуждают её компании разных размеров, которые готовятся выйти на новые рынки либо просто желают сделать приложение доступным для всех.

Как известно, A11Y определяет степень доступности компьютерной системы для всех людей, включая имеющих ограниченные возможности. И прежде чем мы продолжим разговор о тестировании доступности, давайте выясним, о каких конкретно людях идёт речь. Как правило, мы говорим про тех, кто: 1. Имеет нарушения зрения. 2. Имеет нарушения слуха. 3. Имеет нарушения мобильности. 4. Имеет различные сочетания этих нарушений. 5. Пожилых людей.

Нарушения зрения могут быть разными, начиная от неспособности различать цвета, заканчивая полным отсутствием зрения. При наличии проблем со слухом пользователю сложно или невозможно распознавать звуки. В случае нарушения мобильности, пользователю бывает, например, трудно управлять сенсорным экраном. Что касается пожилых людей, то у них нередко возникают когнитивные проблемы, поэтому им могут потребоваться различные вспомогательные технологии для чтения текста и т. д.

Как видите, существует множество групп людей, которые страдают, если приложение оптимизировано не для всех. Чтобы они могли это приложение использовать, нам следует обеспечить соблюдение правил доступности A11Y.

Концепция доступности

Существует несколько вещей, которые мы должны учитывать, говоря о тестировании доступности: 1. Правильное именование элементов специальных возможностей на экране. Соответствие соглашению об именовании типов элементов. 2. Правильный порядок при объявлении элементов через “читатель экрана”. 3. Правильная адаптация текста и элементов интерфейса к настройкам специальных возможностей мобильного устройства. 4. Возможность добавления дополнительных ярлыков или использовании внешней клавиатуры. 5. Обеспечение совместимости приложения с клавиатурой Брайля. 6. Возможность корректировки анимации и цвета/контрастности под конкретные потребности пользователя.

Почему мы должны сделать приложение доступным для всех категорий пользователей?

Все мы знаем, кто такие люди с ограниченными возможностями, и что мы должны им помогать в использовании приложений, но почему нам стоит вкладывать в это своё время и усилия? Существует целый ряд причин: 1. Расширение базы пользователей. Тут поможет предварительное исследование о том, сколько людей с ограниченными возможностями используют ваш продукт и какие у них проблемы. 2. Улучшение описания элементов пользовательского интерфейса. Это сделает приложение лучше и удобнее не только для людей с ослабленным зрением, но и для всех. Например, наведение курсора на изображение покажет правильное описание того, что изображено на картинке, пояснив любые сомнения. 3. Выход на новые рынки. Создание приложения, доступного для всех, может быть полезным для конкретной страны или рынка. Если мы решим, что придание этому приоритетного значения поможет нашему продукту двигаться вперед, то добавление таких функций действительно будет иметь смысл. 4. Иногда это обязательно. В некоторых странах обеспечение доступности для всех людей является обязательным условием и прописано в законодательстве.

Что такое мобильные приложения для людей с ограниченными возможностями?

Мобильное тестирование имеет свои особенности, и основное отличие от стационарных ПК заключается в гораздо меньшем доступном пространстве дисплея и отсутствии физической клавиатуры. Да, Bluetooth-клавиатуру можно подключить к мобильному устройству, но ведь мы, как правило, пользуемся смартфонами и планшетами за пределами дома или офиса.

По этой причине нам необходимо убедиться, что мы располагаем только самой актуальной информацией, предоставляемой пользователю. Как нам этого добиться? Пришло время поговорить о “читателях экрана” (screen readers) — программных средствах чтения с мобильных экранов.

Программы чтения с экрана для мобильных устройств

Применять необходимые изменения, чтобы сделать приложение более доступным, было бы бессмысленно, если бы мы не оптимизировали своё приложение для наиболее популярных программ чтения с экрана: 1. VoiceOver для iOS. 2. TalkBack для Android.

К счастью, по сравнению с настольным компьютером, для мобильных устройств доступно меньше программ чтения с экрана, что облегчает проверку тестировщикам. Основной целью скрин-ридеров является эффективное объявление элементов. Скрин-ридеры могут работать с небольшими различиями, но у них одна и та же цель — помогать пользователям с ограниченными возможностями перемещаться по приложению без изменения его функциональности.

Таким образом, речь идёт не об изменении приложения, а только о его улучшении для обеспечения нужного уровня доступности и удобства использования для этой категории пользователей.

Как сделать приложение оптимизированным для людей с ограниченными возможностями?

К сожалению, секретного рецепта, позволяющего приложению автоматически работать с “читателями экрана”, не существует. Наилучший подход — тестирование доступности на всех этапах разработки.

Доступность — это определенный процесс, который обычно включает следующие операции: 1. Добавление меток специальных возможностей для всех или основных элементов приложения. 2. Проверка, что чтение элементов экрана производится с учетом контекста конкретных диалогов и экранов приложения. 3. Использование дополнительных инструментов для анализа потенциальных проблем с доступностью, таких как WAVE и Developer Tools. 4. Проверка доступности со стороны людей с различными нарушениями, которые могут предоставить действительно ценную информацию о необходимых улучшениях (при наличии таковых в команде).

Вывод

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

На самом деле, сложно достичь идеального состояния доступности. Но приложить соответствующие усилия важно и нужно.

Пошаговое руководство для тестировщиков по проверке доступности сайта

Dec 5, 2019 · 9 min read

Про внедрение доступности существует множество статей для разработчиков и сотни страниц подробной документации. Но когда задача про доступность оказывается на стороне отдела QA, эту информацию приходится транспонировать в контексте требований пользователей с ограниченными возможностями.

В статье изложены основные проверки веб приложения на доступность, если этим придется заниматься функциональному тестировщику.

Предполагается, что читатель знаком с понятием цифровой доступности (Accessibility или A11y) и технологиями обеспечения доступности интерфейсов (см. список литературы);
Не затрагиваются инструменты автотестирования;
Перечисленные ниже проверки — базовые, они проводятся без использования скринридера;
В качестве примера выбрана страница популярного подкаста на Яндекс.Музыке.

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

1. Фокус интерактивных элементов

Пробуем пройтись по странице по нажатию TAB, обращаем внимание на выделение активных элементов при навигации — они должны быть заметны, чтобы было понятно в где мы оказались.

У большинства ссылок и кнопок отсутствует фокус;

Ожида л ось: если с элементом можно взаимодействовать, он будет иметь видимый индикатор фокуса.

1.2. Фокус интерактивных элементов — ссылка [технологии] имеет дефолтный стиль фокуса

Зачем? Подсвеченный фокус — визуальная обратная связь для того, чтобы пользователь понимал где он находится.

Это пункт 2.4.7 «Видимый фокус» требований WCAG (подробнее).

Рекомендуется обеспечивать очевидный стиль фокуса (особенно, если стиль по умолчанию оказывается удален):

2. Последовательность элементов при клавиатурной навигации

Навигируемся по странице нажатием TAB, элементы последовательно выделяются слева направо и сверху вниз.

Фактический результат совпадает с ожиданием: навигация происходит в логической последовательности. Визуальный порядок элементов соответствует реальному порядку в DOM-дереве, т.е. CSS свойства не меняют порядок элементов.

3. Расстановка tabindex

Навигируемся по странице нажатием TAB, со всеми интерактивными элементами можно взаимодействовать.

Фактический результат: невозможно запустить произвольный эпизод из списка подкастов, т.к. интерактивные элементы (кнопочки плей, лайк и дизлайк) не являются частью естественного порядка табуляции. Они появляются только при наведении мышки и на них невозможно попасть при навигации с клавиатуры.

3. Расстановка tabindex — запустить трек с клавиатуры не получится, т.к. кнопка ► появляется только при наведении

Ожидалось: на интерактивные элементы можно попасть с клавиатуры.

Зачем? Чтобы пользоваться всеми функциями сайта.

Это пункт 2.1.1 «Клавиатура» требований WCAG (подробнее).

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

4. Значение tabindex

Проверяем значения атрибутов tabindex в коде страницы.

Фактический результат: есть множество элементов с одинаковым tabindex > 0.

Ожидалось: единственный элемент с tabindex > 0.

Зачем? Чтобы не сбивать браузер с толку или специально указать на первый фокусный элемент (при использовании единственного tabindex="1" ).

Не смотря на то, что tabindex может быть больше 0 (но не превышать 32767), желательно иметь единственный элемент с tabindex > 0, т.к. на него первым придет фокус с клавиатуры по TAB.

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

5. Язык документа

У Яндекс.Музыки есть локализация — язык страницы можно поменять на английский, армянский, узбекский, кириллический казахский, украинский или азербайджанский. Поэтому проверяем объявление языка страницы.

Фактический результат: в теге <html> не указан язык документа.

Зачем? Чтобы синтезатор речи точно определил язык страницы. Иначе русские слова он может читать как «Cyrillic letter A, Cyrillic letter Б, Cyrillic letter В», а при смене локали нужно менять lang на соответствующее значение из реестра IANA: en, hy, uz, kk, uk или azb.

6. Структура документа

Проверяем наличие тегов заголовков в коде страницы.

Фактический результат совпадает ожиданием: выбранная страница имеет простую структуру, главный заголовок размечен правильным тегом <h1> .

Зачем? Продуманная структура документа (наличие заголовков в иерархическом порядке) поможет быстрее перемещаться по сайту — скринридеры позволяют «прыгать» между заголовками.

В случае наличия одних <div> ов и невозможности их замены на семантически верные заголовки, нужные блоки можно включить в A11y-дерево через добавление соответствующих ARIA ролей: role="heading" aria-level="1" .

7. Ориентиры документа

Проверяем наличие атрибутов ARIA Landmark Roles в коде страницы.

Фактический результат: ничего.

Ожидалось: разметка областей страницы основными ролями в соответствии с их содержимым: banner, complementary, contentinfo, main, navigation, search.

7. Ориентиры документа — пример расстановки ARIA Landmarks

Зачем? Ориентиры, как и заголовки, помогают быстрее перемещаться по сайту — скринридеры позволяют «прыгать» между размеченными блоками.

Ориентиры определяют предназначение области страницы и, по сути, дублируют контентные HTML5 элементы: <header> , <aside> , <footer> , <main> , <nav> . Однако нужно дополнительное указание ARAI ролей в HTML5 тегах для поддержки старых браузеров и обхода багов, например когда <footer> не попадает в A11y-дерево и ему приходится назначать role="contentinfo" .

8. Описание интерактивных элементов

Проверяем наличие и понятность описания интерактивных элементов (кнопок и ссылок). Здесь пригодится включение скринридера, чтобы понимать, как эти элементы прочитываются.

Фактический результат: описаний нет или они непонятны.

Ожидалось: описания отражают логический смысл интерактивных элементов. Например:

Вместо стандартного наименования ссылки [технологии] можно aria-label="Открыть страницу подкастов жанра технологии" ;
Вместо стандартного наименования кнопки [Слушать] можно aria-label="Слушать подкаст" ;
Вместо отсутствия описания кнопки […] нужно aria-label="Открыть меню подкаста" .

Когда не видно интерфейса, его можно и нужно описывать: что именно делают кнопки и ссылки;
Указанный aria-label — это то, как будет прочитан этот элемент.

9. Описание изображений

Проверяем наличие атрибута alt у изображений.

Фактический результат: отсутствуют описания изображений.

9. Описание изображений — у тега <img> отсутствует alt

У обложи подкаста будет атрибут с описанием alt="Обложка подкаста Слушай, Алиса!" ;
У логотипа сайта будет описание. Не смотря на то, что логотип размещен на сайте не через <img> , а через свойство background-image , у ссылки логотипа должно быть описание: aria-label="Яндекс Музыка" .

Зачем? Для контекстных картинок (которые несут какой-то смысл) необходимо предусматривать альтернативный текст, чтобы пользователь со скринридером получил представление об изображении.

10. Цветоощущение

Отображение сайта в монохромном режиме и режимах имитации дальтонизма и дальнозоркости (размытие картинки) с помощью встроенного в Firefox симулятора или стороннего расширения для браузера (см. список литературы);
Отображение ссылок в каждом из режимов;
Контрастность текста с помощью Accessibility Inspector в Firefox.

Неконтрастный текст: «ПОДКАСТ», «Популярно у слушателей», «2019» и «технологии» слишком светлые — коэффициент контрастности должен составлять не менее 4,5:1 для текста стандартного размера (подробнее);

Не видно состояния ссылки [технологии] при наведении в монохромном режиме.

10.3. Монохромазия (отсутствие цветовосприятия), 10.4 Дальнозоркость или затуманенное зрение

10.5. Протанопия (нарушение цветовых ощущений в красной части спектра), 10.6 Тританопия (нарушение цветовых ощущений в сине-фиолетовой области спектра)

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

Чтобы не использовать исключительно цвет для передачи информации;
Чтобы позаботиться о пользователях с нарушением цветовых ощущений и сделать текст и ссылки читабельнее.

11. Увеличение шрифта

Увеличиваем размеры текста на странице до 200 %.

Фактический результат совпадает с ожиданием: верстка адаптировалась под изменившиеся пропорции текста.

12. Самопроверка в Lighthouse

Смотрим, что было упущено при ручных проверках.

Остались некоторые кнопки без описаний;
Фреймы <iframe> остались без описаний (вне текущей области тестирования);
Подписи к картинкам покрыты в п. 9;
Элементы форм <input> остались без описаний (строка поиска вне текущей области тестирования);
Подписи к интерактивным элементам покрыты в п. 8.

Если не знать что искать, то автоматический аудит можно было бы запустить в начале тестирования или использовать Accessibility Inspector в Firefox для выявления проблем в конкретных элементах.

Перечисленных проверок достаточно для проведения первичного тестирования и/или аудита.

Читайте также: