Управление фокусом и атрибут inert
Множество вспомогательных технологий используют навигацию с клавиатуры для помощи в восприятии и взаимодействии с контентом. Один из способов подобной навигации — клавиша Tab. Возможно, вы знакомы с ним, если используете Tab для быстрого перемещения между полями формы, не дотягиваясь до мышки или трекпада.
Tab будет перемещаться по интерактивным элементам в том порядке, в котором они отображаются в DOM. Вот почему так важно, чтобы порядок исходного кода соответствовал визуальной иерархии вашего дизайна.
Список интерактивных элементов, по которым можно пройтись клавишей Tab:
Интерактивный элемент получает состояние фокуса, когда:
Фокус похож на ховер, поскольку так мы определяем элемент, с которым хотим провзаимодействовать. Вот почему визуально очевидные стили для фокуса имеют огромное значение.
Фокус следует по домашней странице. Начиная с логотипа, затем к товарам, услугам, вакансиям, блогу, контактам и останавливается на кнопке «Learn more».
Управление фокусом Скопировать ссылку
Управлять фокусом — значит определять, какие элементы могут его получать, а какие нет. Это один из самых сложных аспектов при разработке веб-интерфейсов, но он важен для доступности сайтов и приложений.
Полезные практики управления фокусом Скопировать ссылку
В 99% случаев вам стоит оставить порядок фокуса в покое. Не устану это повторять.
Состояние фокуса будет работать без дополнительных усилий, если вы используете для кнопок, для ссылок, для полей форм и т. д.
В редких случаях вам может понадобиться добавить фокус к элементам, к которым обычно событие focus не применимо. Вот некоторые рекомендации относительно того, как реализовать это доступно и интуитивно понятно для пользователя.
✅ Следует: узнать побольше про атрибут tabindex Скопировать ссылку
tabindex делает элементы фокусируемыми. В качестве значения он принимает число, в зависимости от которого меняется поведение фокуса.
❌ Не следует: устанавливать tabindex=»0″ там, где это не надо Скопировать ссылку
Нет необходимости устанавливать tabindex для интерактивных элементов, которые могут получать фокус с клавиатуры (например, ). Кроме того, вам не нужно прописывать tabindex неинтерактивным элементам, чтобы их могли прочесть вспомогательные устройства (на самом деле, отсутствие роли и доступного имени является ошибкой с точки зрения WCAG). На самом деле, это даже усложняет навигацию для тех, кто использует вспомогательные устройства. У таких пользователей уже есть другие, ожидаемые ими способы чтения контента.
✅ Следует: устанавливать tabindex=»-1″ для фокуса с помощью JavaScript Скопировать ссылку
❌ Не следует: использовать положительное значение tabindex Скопировать ссылку
❌ Не следует: создавать собственный порядок фокусировки Скопировать ссылку
Пройтись по интерактивным элементам можно только в том порядке, в котором они следуют друг за другом. Не следует создавать множество tabindex со значением, которое увеличивается для каждого последующего элемента, в соответствии с вашим представлением о том, как пользователь должен читать ваш сайт. Позвольте DOM сделать это за вас.
Ловушка фокуса Скопировать ссылку
Иногда есть необходимость запретить состояние фокуса. Хороший пример запрета — это ловушка фокуса, которая временно ограничивает событие фокуса у родительского элемента и у его дочерних элементов.
Ловушку фокуса не стоит путать с ловушкой клавиатуры. Ловушки клавиатуры — это ситуации, когда невозможно закрыть виджет или перейти к другому компоненту из-за вложенного цикла плохо прописанной логики.
Практический пример того, как вы могли бы использовать ловушку фокуса — это модальное окно:
Фокус проходит по странице и открывает модальное окно, чтобы продемонстрировать отмену фокуса. Далее фокус двигается в рамках контента модального окна, на кнопку «Play», кнопку «Cancel», кнопку «Purchase» и кнопку закрытия (всё это время фокус на странице заблокирован). После закрытия модального окна он возвращается к исходному положению на странице до его открытия.
Почему это важно? Скопировать ссылку
Удержание фокуса в пределах модального окна помогает понять, что является его контентом, а что нет. Это аналогично тому, как зрячий человек может видеть, как окно всплывает поверх контента сайта или приложения. Это важная информация, если:
Как это сделать? Скопировать ссылку
Надёжно управлять фокусом — дело сложное. Нужно прибегнуть к JavaScript, чтобы:
Зачем нам это? Скопировать ссылку
Не стану врать: все эти действия отнимают много времени. Но всё же, управление фокусом и удобный порядок фокусировки являются частью WCAG (руководства по обеспечению доступности веб-контента). Тема достаточна важна, чтобы считать её частью международного правового стандарта о юзабилити.
Видимость Скопировать ссылку
Существует небольшой трюк, с помощью которого можно легко ограничить видимость и интерактивность элемента.
У скринридеров есть режим взаимодействия, который позволяет им проходить по странице или просматривать её с помощью виртуального курсора. А ещё виртуальный курсор позволяет пользователю скринридера обнаруживать неинтерактивные части страницы (заголовки, списки и т. д.). В отличие от использования Tab, виртуальный курсор доступен только пользователям скринридера.
При управлении фокусом может потребоваться ограничить возможность обнаружения содержимого виртуальным курсором. В нашем примере с модальным окном это значит предотвратить случайный выход пользователя за рамки окна при чтении контента.
Знакомство с inert Скопировать ссылку
Атрибут inert — глобальный атрибут в HTML, позволяющий легко убирать и восстанавливать видимость интерактивных элементов, а также их возможность получать состояние фокуса. Вот пример:
Я намеренно избегаю использования для модального окна из-за многочисленных проблем с поддержкой.
Помните: событие закрытия модального окна может быть вызвано не только нажатием на кнопки внутри нашего модального окна из примера, но и при нажатии на Esc. А ещё некоторые модальные окна могут быть закрыты по клику на оверлей.
Поддержка inert Скопировать ссылку
Вдобавок хочется обратить внимание на пометку в README полифила:
Перемещение по DOM подразумевает, что JavaScript в полифиле требует высокой вычислительной мощности и, следовательно, в конечном итоге замедлит использование.
Для устройств с низким энергопотреблением, таких как бюджетные Android-смартфоны и устаревшие ноутбуки, а также тех, что выполняют сложные задачи (например, запуск нескольких приложений сразу), это может привести к зависанию или сбоям. Нативная браузерная поддержка делает такие процессы менее затратными в этом плане, так как у браузера есть доступ ко всем частям DOM, в отличие от JS.
Safari Скопировать ссылку
macOS и iOS всегда имели хорошую поддержку доступности, а поддержка вспомогательных технологий — важная часть их маркетинговой кампании. Поддержка inert представляется как естественное продолжение миссии Apple ввиду того, что сама эта функция смогла бы облегчить разработку доступных веб-интерфейсов в разы.
К сожалению, Apple держит в тайне, когда появится поддержка этого атрибута. Поэтому поддержка inert — всё ещё открытый вопрос.
Igalia Скопировать ссылку
Igalia — компания, работающая над функциями браузеров. Сейчас они проводят эксперимент, в котором каждый может проголосовать за те возможности браузеров, которые ему хотелось бы видеть. Конечно, моя статья совсем не про это, но вы можете узнать больше в Smashing Magazine.
Итог Скопировать ссылку
Управление фокусом требует некоторых навыков и осторожности, но это того стоит. Атрибут inert значительно облегчит эту задачу.
Оформляйте стили наведения, фокуса и активного состояния по-разному
Вот пример кода, который всегда использовал.
Когда я стал уделять больше внимания доступности интерфейса при работе с клавиатуры (состоянию фокуса в частности), пришел к выводу, что мы не должны одинаково стилизовать разные состояния элементов.
Наведение, фокус и активное состояние должны стилизоваться по-разному.
Причина проста: Это разные состояния!
Сегодня я хочу продемонстрировать вам волшебный способ оформить все три состояния без особых усилий.
Стилизация наведения (:hover)
:hover срабатывает, когда пользователь наводит на элемент курсор мыши.
Стилизация фокуса (:focus)
:focus срабатывает, когда элемент получает фокус. Это достигается двумя способами:
Когда пользователи нажимают «Tab», они не знают, к какому элементу перейдет фокус, а могут лишь предполагать. Вот почему нам нужно заметное изменение состояния — чтобы привлечь внимание пользователя на сфокусированный элемент.
В большинстве случаев оформление фокуса по умолчанию вполне подходит. Если вы хотите стилизовать его по-своему, помните об этих четырёх моментах:
Стилизация активного состояния (:active)
При взаимодействии с чем-то в реальной жизни, вы ожидаете своего рода отклик. Например, при надавливании на кнопку, вы ожидаете, что она нажмётся.
Две особенности, которые следует принять к сведению:
Стили ссылок по умолчанию
Ссылки имеют стили активного состояния по умолчанию. При нажатии они становятся красными
Взаимосвязь между :active и :focus
При удержании левой кнопку мыши на фокусируемом элементе, вызывается его активное состояние. Но одновременно с этим вызывается и состояние фокуса.
Когда вы отпускаете левую кнопку мыши, фокус остаётся на элементе.
Это относится к большинству фокусируемых элементов, кроме ссылок и кнопок.
Добавление этого кода изменит поведение нажатия кнопок на следующее:
Теперь, когда вы знаете всё необходимое о состояниях hover, focus и active, я хочу поговорить о стилизации всех трёх
Волшебная комбинация
Волшебная комбинация позволяет пользователям получать отклик, когда они наводят, фокусируются или взаимодействуют с элементом. Вот код, который вам нужен:
Для пользователей мыши:
Для пользователей клавиатуры:
Лучшее из обоих миров!
Не волшебная (но может даже лучше) комбинация
Как я упомянул выше, клики на кнопки имеют странное поведение в Safari и Firefox на Mac OS. Если вы добавили фрагмент JavaScript-кода, который я предлагал выше, магическая комбинация всё еще работает. Но не идеально.
Вот что произойдёт в Safari и Firefox на Mac OS:
Если вы считаете, что этого достаточно, то волшебная комбинация работает. Можете на этом и остановиться.
Поведение кнопки в Safari, если были стилизованы все три состояния
Вот и всё! Благодарю за чтение и надеюсь, сегодня вы узнали что-то новое.
Русский
Чтобы веб-страница была полностью доступной, она должна быть управляема кем-то, кто использует только клавиатуру для доступа к ней и управления ею. Сюда входят пользователи программ чтения с экрана, но также могут быть пользователи, у которых есть проблемы с использованием указывающего устройства, такого как мышь или трекбол, или у которых мышь не работает в данный момент, или которые просто предпочитают использовать клавиатуру для ввода, когда это возможно.
Фокусируемые элементы должны иметь интерактивную семантику
Если элемент можно сфокусировать с помощью клавиатуры, он должен быть интерактивным; то есть пользователь должен иметь возможность что-то сделать с ним и произвести какое-либо изменение (например, активировать ссылку или изменить параметр).
Note: One important exception to this rule is if the element has role=»document» applied to it, inside an interactive context (such as role=»application» ). In such a case, focusing the nested document is the only way of returning assistive technology to a non-interactive state (often called «browse mode»).
Most interactive elements are focusable by default; you can make an element focusable by adding a tabindex=0 attribute value to it. However, you should only add tabindex if you have also made the element interactive, for example, by defining appropriate event handlers keyboard events.
See also
Avoid using tabindex attribute greater than zero
The tabindex attribute indicates that an element is focusable using the keyboard. A value of zero indicates that the element is part of the default focus order, which is based on the ordering of elements in the HTML document. A positive value puts the element ahead of those in the default ordering; elements with positive values are focused in the order of their tabindex values (1, then 2, then 3, etc.).
This creates confusion for keyboard-only users when the focus order differs from the logical order of the page. A better strategy is to structure the HTML document so that focusable elements are in a logical order, without the need to re-order them with positive tabindex values.
See also
Clickable elements must be focusable and should have interactive semantics
If an element can be clicked with a pointing device, such as a mouse, then it should also be focusable using the keyboard, and the user should be able to do something by interacting with it.
An element is clickable if it has an onclick event handler defined. You can make it focusable by adding a tabindex=0 attribute value to it. You can make it operable with the keyboard by defining an onkeydown event handler; in most cases, the action taken by event handler should be the same for both types of events.
See also
Interactive elements must be able to be activated using a keyboard
If the user can interact with an element using touch or a pointing device, then the element should also support interacting using the keyboard. That is, if you have defined event handlers for touch or click events, you should also define them for keyboard events. The keyboard event handlers should enable the effectively the same interaction as the touch or click handlers.
See also
Interactive elements must be focusable
If the user can interact with an element (for example, using touch or a pointing device), then it should be focusable using the keyboard. You can make it focusable by adding a tabindex=0 attribute value to it. That will add the element to the list of elements that can be focused by pressing the Tab key, in the sequence of such elements as defined in the HTML document.
See also
Focusable element must have focus styling
Any element that can receive keyboard focus should have visible styling that indicates when the element is focused. You can do this with the :focus CSS pseudo-class.
Standard focusable elements such as links and input fields are given special styling by the browser by default, so you might not need to specify focus styling for such elements, unless you want the focus styling to be more distinctive.
If you create your own focusable components, be sure that you also define focus styling for them.
Включить: фокус только на использование клавиатуры (или tab нажмите)
Я думал добавить класс enabled-focus на теле на вкладке нажмите, а затем имейте body.enabled-focus a:focus <. >но это добавило бы много дополнительного CSS для каждого элемента, который имеет фокус. Затем удалите этот класс из тела на первой мыши вниз.
как бы я это сделал? Есть ли лучшее решение?
6 ответов
эта отличная статья by Роман Комаров представляет собой эффективное решение для достижения клавиатура-только стили фокусировки на кнопки, ссылки и другие элементы контейнера, такого как охватывает или divs (которые искусственно сделаны фокусируемыми с атрибутом tabindex)
в Решение:
сайт CodePen
1) оберните содержимое исходного интерактивного элемента внутри дополнительного внутреннего элемента с помощью tabindex=»-1″ (см. объяснение ниже)
поэтому вместо того, чтобы сказать:
3) Удалите стиль фокуса по умолчанию из внешних и внутренних элементов:
4) Добавить стиль фокуса обратно во внутренний элемент только после внешний элемент имеет фокус:
почему это работает?
сайт CodePen
1) хотя это кажется слишком сложным решением, для решения без javascript это на самом деле довольно впечатляюще. Более простые css-только «решения» с участием :hover и :active псевдо класс стайлинг просто не работает. (если, конечно, вы не предполагаете, что интерактивный элемент немедленно исчезает при нажатии, как кнопка в модальном сказать)
сайт CodePen
2) это решение не идеально: firefox в windows по-прежнему будет получать стили фокуса для кнопок при нажатии, но это, похоже, ошибка firefox (см. статьи)
прагматическая альтернатива клавиатуре-только стили фокусировки
сайт CodePen
поэтому, хотя технически это не реализует стили только для клавиатуры, это по существу устраняет необходимость в стилях только для клавиатуры.
это проблема, с которой вы, вероятно, столкнетесь много. Хорошая вещь в таких проблемах, если вы однажды найдете решение,это больше не будет беспокоить вас.
самое элегантное решение кажется самым простым: не удаляйте контур на: focus, сделайте это на :active вместо этого-в конце концов: active-это динамический псевдокласс, который имеет дело явно со стилями, которые должны применяться, когда фокусируемый элемент нажат или активирован иным образом.
только незначительные проблемы с этим методом: если пользователь активирует ссылку, а затем использует кнопку «Назад» браузера, контур становится видимым. О, и старые версии Internet Explorer, как известно, путаются с точным значением: focus,: hover и: active, поэтому этот метод терпит неудачу в IE6 и ниже.
Типп
удаление outline ужасно для доступности! В идеале кольцо фокусировки отображается только тогда, когда пользователь намерен использовать клавиатуру.
Я тоже написал более подробно в должности на всякий случай вам нужна дополнительная информация.
Case study: страница входа в Facebook
Facebook использует крошечный бит Javascript на своей странице входа в систему прямо сейчас (июнь 2018).
Javascript обнаруживает, когда пользователь щелкнул мышью или использовал клавиатуру, и переключает класс на теле и выключается:
тогда правила CSS могут использовать этот класс, чтобы показать или скрыть соответствующий стиль фокуса на соответствующих элементах.
вот пример кода (также доступен on Сайт CodePen):
пример: страница входа в GMail
кроме того, GMail просто укладка сфокусированных кнопок с более тяжелой тенью, чем несфокусированные кнопки, независимо от того, находится ли пользователь на мыши или клавиатуре.
это согласованно, проще реализовать и протестировать и не требует Javascript.
но это компромисс. Он передает информацию о фокусе, которую пользователи мыши не действительно интересует, и это, возможно, немного слишком тонкий для пользователей клавиатуры.
играя с принятым решением Danield, я нашел альтернативный, более простой способ, основанный на концепции внутреннего/внешнего div.
1) Создайте внешний и внутренний элемент. Дайте внешнему элементу tabindex= «0»и внутреннему элементу tabindex=»-1″
2) в css удалите контур из внутреннего элемента при фокусировке:
3) примените любые обработчики событий мыши или щелчка к внутреннему элементу. Применить любые события фокуса (onfocus, onblur, onkeydown) к внешнему элементу.
**поддерживайте размер и позиционирование таким образом, чтобы внутренний элемент полностью перекрывал внешний элемент. Расположите всю «кнопку» со стилем на внешнем элементе.
как это работает:
когда пользователь нажимает на «кнопку», они нажимают на внутренний элемент, у которого удален Контур Фокуса. Невозможно щелкнуть по внешнему элементу, так как он покрывается внутренним элементом. Когда пользователь использует клавиатуру для вкладки «кнопка», они попадают во внешний элемент (tabindex=» 0″делает элемент доступным с помощью» tab»), который получает Контур Фокуса, но внутренний элемент не доступен через вкладку (с tabindex= «-1») и не получает Контур Фокуса при нажатии.
нет четкого решения. Я сделал одно хакерское решение : применить событие click на главном контейнере и написать ниже код на click
при нажатии с помощью мыши вы получите событие.detail = 1 на этом щелчке размыть этот элемент, чтобы он удалил контур и на клавиатуре нажмите мы получаем событие.detail = 0 так что в случае клавиатуры ведите себя нормально
Создание кликабельных и фокусируемых при помощи клавиатуры элементов
Как правило, когда вы хотите создать кликабельный элемент веб-страницы с целью привязки его к JavaScript функции, лучшим кандидатом на эту роль являются те элементы, которые собственно и предназначены для взаимодействия с пользователем при помощи клавиатуры. В большинстве случаев кнопка, реализуемая несколькими способами ( или ) — наиболее подходящий для этого элемент, позволяющий активировать необходимую функцию независимо от того что использует для этого пользователь мышь или что-либо другое.
Так почему же для приведения в действие требуемой функциональности на сайте многие веб-разработчики используют неверный элемент? На мой взгляд, основной причиной является вопрос стилизации или другими словами визуального оформления. Было время, когда браузеры не позволяли в достаточной степени изменять внешний вид элементов кнопок, что и вынудило разработчиков использовать взамен те элементы, которые более легко поддаются стилизации. Уже прошло много лет и сменилось множество версий браузеров с тех пор, когда это было единственным выходом из ситуации (взгляните на примеры возможного оформления кнопок на период 2004 года). На сегодняшний день ситуация значительно улучшилась и все широко использующиеся в данный момент браузеры позволяют в достаточной степени изменять внешний вид кнопок.
Другая причина такого поведения – недостаток знаний. Многие делают это по привычке, не зная, что теперь они могут без проблем применять к элементам кнопкам необходимые стили. Кроме того большинство других не понимают, что применение элементов, изначально не предназначенных для взаимодействия с клавиатурой, могут вызвать серьезные проблемы, связанные с доступностью документа.
Что же можно посоветовать в этом случае? Есть два варианта:
Первый вариант самый простой и в тоже время надежный, поэтому его я и рекомендую. Но в том случае, если вы все же остановите свой выбор на втором варианте, обратите внимание на перечисленные ниже рекомендации, направленные на то, чтобы в максимальной степени приблизить вашу фиктивную кнопку к ее реальному варианту:
Взгляните на демо страницу, на которой представлены перечисленные ниже способы создания фокусируемых и кликабельных элементов доступных с клавиатуры:
Если пользователь использует мышь, то все они работают. Кликните по любому, выполненному в виде кнопки элементу и в результате появится окно с сообщением. Но если для их выбора вы используете клавишу табуляции клавиатуры, то вот что происходит в каждом конкретном случае:
Суть рассматриваемого в статье вопроса такова: либо использовать элемент, непосредственно предназначенный для взаимодействия с клавиатурой (рекомендуется), либо взамен использовать другой нужный вам элемент с максимально точной имитацией того, который изначально предназначен для таких целей.
