Топ-10 багов доступности 2023 года

Есть такая компания TPGI занимающаяся вопросами доступности на всех уровнях разработки. У них множество инструментов для поиска проблем с доступностью в ПО, в том числе так называемый ARC monitoring для анализа веб-сайтов. С помощью этого и многих других приложений компания выделила 10 самых распространенных багов. Надеюсь знания о них уберегут ваши проекты и ваших пользователей от проблем.

1. Нет текста у ссылок

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

2. Включение фокуса на лишних элементах

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

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

3. Отсутствует атрибут alt ссылок

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

4. Нет атрибута alt изображений

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

5. Неправильная вложенность списков

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

6. Дублирование label'ов

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

7. Положительные значения для tabindex

Как говорилось в пункте 2 использовать tabindex нужно аккуратно, а самое главное либо 0, либо -1. Почему так мне не совсем понятно, если знаете почему, то дайте знать в комментах. Т.е. задание положительных значений создают проблемы.

8. Некорректный aria-describedby

Атрибут aria-describedby связывает несколько элементов, например, span и input. Т.е. в spane'е можно указать подсказу для input'а, а атрибут aria-describedby свяжет их, и при озвучке будет прочтение spana'а для заданно инпута. Пример:

<label for="psw">Пароль</label> <input type="password" name="password" id="psw" aria-describedby="hint" > <span id="hint">Пароль должен содержать не меньше 20 знаков</span>

Важно следить за тем, чтобы aria-describedby был правильно связан по ID с элементов для которого предназначен другой.

9. Нет подписей для кнопок

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

10. Некорректный aria-labelledby

Похожий атрибут, как в пункте 8, но его фишка в том, что он ссылается на другой элемент на стр.

Полезные ссылки

1. Статья в оригинале https://www.tpgi.com/the-top-accessibility-errors-found-in-2023/
2. Доступность простым языком https://doka.guide/a11y/