Создание доступного вспомогательного тултипа

Создание доступного вспомогательного тултипа

От автора: сегодня один из тех дней, когда мне пришлось загуглить очередной вопрос по доступности. Я работаю над новым проектом под названием Provata. Передо мной стала задача создать прикольный и, казалось бы, простой вспомогательный тултип, который пояснял бы читателям/пользователям, что такое Framingham calculator.

Тултип раскрывается при наведении курсора на маленькую иконку в правом верхнем углу, как на скриншоте ниже:

Создание доступного вспомогательного тултипа

Как и во всех проектах, первое, о чем я подумал – какие HTML элементы использовать для разметки компонента. Но оказалось, что для тултипа нет подходящего HTML тега. А если нет подходящего семантического элемента, перед нами встает проблема. Нам нужно убедиться, что вспомогательные технологии (AT), которые обычно понимают и передают смысл через семантику, поймут, что это за элементы, и что они делают.

Помогут ли ARIA атрибуты?

Когда только HTML недостаточно, сделать элементы более читабельными для AT можно с помощью ARIA атрибутов. Например, можно создать прогресс бар, не используя плохо поддерживаемый тег progress. Создать прогресс бар и придать ему вид и поведение можно с легкостью с помощью CSS, однако если вы используете div’ы и span’ы, то чтобы из этих элементов что-то да вышло, нужно дать AT нечто большее. Тут нам и помогут ARIA атрибуты типа role=»progressbar» и его компаньоны, aria-valuenow, aria-valuemin и aria-valuemax. Добавляем немного простого JS и обновляем значение в aria-valuenow по мере продвижения пользователя по этапам. Если интересно, более подробно можете ознакомиться с темой на MDN. Отлично.

У нас есть значение ARIA атрибута, указывающее на тултип – tooltip. Атрибут role=»tooltip» явно говорит AT, что этот элемент является тултипом.

Но тултипы обычно раскрываются после действия над другим элементом.

Вернемся к основам. Из Wikipedia: «Тултип, инфотип или подсказка – общий элемент графического интерфейса. Используется вместе с курсором, обычно типа pointer. Пользователь наводит указатель на элемент, не нажимая на него, после чего появляется тултип – небольшой всплывающий блок с информацией о том элементе, на который наведен курсор. В мобильных операционных системах тултипы не появляются, так как в них нет курсора (они могут отображаться, если использовать мышь).»

У меня возникла проблема с частью «в мобильных операционных системах тултипы не появляются, так как в них нет курсора». Мобильные пользователи имеют столько же прав, сколько и остальные, и должны видеть вспомогательную информацию. Используете вы мышь или палец, у вас должна быть возможность понять, что такое Framingham score. То есть тултип должен быть доступен во всех контекстах. И вот тут начинается веселье.

Вызов открытия/закрытия тултипа

Я понимал, что события hover мне недостаточно (хотя клиент заказывал только hover), так как если у вас нет тач скрина с цифровой ручкой, которая умеет запускать hover, вы не сможете увидеть подсказку в тултипе, что неприемлемо.

Я поставил цель создать тултип, который будет отображаться при наведении и нажатии на иконку.

Стоит отметить, что некоторые тултипы работают как на тач скринах, так и на обычных экранах без дополнительного вмешательства. В качестве примера можно привести тултипы в виде вспомогательных лейблов на полях input, как в примере от Heydon Pickering. В подобных сценариях для индикации AT, что этот кусок текста является тултипом, описывающим контент или функционал поля, достаточно role=»tooltip» в паре с aria-describedby. Маркировать тултип в таком случае очень просто, так как уже понятно, что этот элемент значит. Вам остается показывать/прятать текст, когда поле input получает фокус. А это можно сделать парой строк CSS. Способ отлично и одинаково работает как с мышью, так и на тач скринах.

Однако если у вас пример, как в моем проекте, все не так легко. И, судя по всему, я не один, кто не знал, как решить эту проблему.

Мне пришло в голову несколько идей по реализации такого тултипа:

Открывать и закрывать тултип с помощью button. По умолчанию тултип скрыт, поэтому AT не прочитают его текст вслух. Тултип прерывает поток контента в нашем проекте, поэтому он должен показываться по требованию.

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

По умолчанию тултип скрыт с помощью display: none и показывается по требованию.

Я всегда пишу HTML код с упором на семантику и то, «как машины будут читать это», поэтому я подумал: если я использую button, мне придется использовать aria-controls для указания того, что контролирует эта кнопка, а также что она будет показывать/прятать некий элемент по клику. Все хорошо.

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

При использовании ссылки, пользователь будет перепрыгивать на определенную секцию страницы. Я ненавижу прыжки по страницам. Стараюсь избегать их, как чумы. Использую только, когда понятно, что это якорь (например, ссылка «наверх» на слишком длинных страницах).

Чтобы не использовать <a>, а кнопка button открывала и закрывала тултип, мне нужен JS.

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

Обычно если я начинаю разрываться между двумя решениями, думаю о том, использовать или нет JS, я ищу второе мнение. Мой первый источник второго мнения – Google. Я подумал: «кто-то должен был создать такой тултип, нужно посмотреть, как он решил эти проблемы».

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

Google привел меня на форумы, где задавались те же самые вопросы, что и у меня в голове. Я нашел много похожих вопросов, но все они были по тултипам на поле input. Я нашел очень старую ветку Zoe Gillenwater, она задавала такой же вопрос еще в 2011 году. Я понимал, что часть технических деталей в наше время могли быть неправильными, но основные принципы были верны. Перед тем как продолжить, советую прочитать эту ветку, так как вся дальнейшая информация основана на ней. Основные моменты из той ветки:

Избегайте button, лучше используйте <a>, так как ссылки можно использовать с чем угодно, а кнопки нужно использовать в формах. Здесь я не согласен. Если можете назвать реально хорошую причину, почему не стоит использовать button, напишите мне.

При использовании <a> нужно учесть/запомнить — если вы используете <a>, и подсказка находится внутри ссылки:

Код будет следующий:

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

На чистом CSS прятать и показывать текст можно с помощью display: none и display: block при наведении курсора на элемент. Удобно для видящих пользователей, использующих мышь. Однако…

Если прятать текст с помощью display: none в теге <a> и показывать его по получению фокуса, AT не сможет считать отображаемый текст, так как контент ссылки объявляется при первом focus и не объявляется повторно, когда текст отображается внутри ссылки с помощью display: block.

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

(Мое мнение: мне не нравится тот факт, что ссылка никуда не ведет. Это ссылка на себя, если так можно выразиться, что сводит на нет ее роль. Я попробовал ссылку чисто из любопытства, хотя знал, что использовать ее не хочу.)

Если вы используете <a>, и ссылка ведет на отдельный кусок текста (не в самой ссылке):

Код будет:

Если не использовать JS, ссылка опять вызывает перепрыгивание.

На тач скринах при касании ссылка получает фокус, что в свою очередь открывает тултип. Однако изображение ссылки остается тем же, и тултип нельзя закрыть, кроме как кликнуть в любом месте за пределами тултипа, чтобы снять фокус. Такой способ не интуитивный, так как пользователи будут напрягаться и думать, «как мне закрыть эту подсказку», особенно если тултип закрывает контент в открытом виде.

У всех способов без JS есть большой минус, который негативно сказывается на пользовательском опыте. С помощью JS все можно сделать правильно, и у всех пользователей все будет одинаково. JS решает все вышеупомянутые проблемы, кроме того, что ссылка никуда не ведет. Но эту проблему можно решить, не используя ссылки, которые никуда не ведут. 😀 (некоторые скажут, что в пустых ссылках нет ничего плохого, но я не люблю их использовать). Остановился я на методе с JS и неплохим фолбэком. Он учитывает мои основным мысли и соображения. Разметку и функционал я закину в пример этого проекта.

Заключение?

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

Хотите подробно изучить требования атрибутов, настоятельно рекомендую ARIA Role Matrices от WhatSock. Очень простой в чтении обзор.

Paul J Adam также создал демо, в котором показал разные способы отображения тултипов по наведению мыши. Его пример использует JS, чтобы сделать компоненты более доступными с помощью переключения ARIA атрибутов при открытии/закрытии тултипа. Рекомендую посмотреть.

Источник: //sarasoueidan.com/

Редакция: Команда webformyself.

Метки:

Похожие статьи:

Комментарии Вконтакте: