Состояния и свойства объектов — ARIA-атрибуты
Атрибутов спецификации, как нетрудно догадаться, гораздо больше. Их делят на следующие секции.
Эта секция содержит атрибуты, определенные для элементов пользовательского интерфейса, (GUI) веб-документов или интернет-приложений, взаимодействующих с пользователем. Эти атрибуты предназначены для поддержки ролей-виджетов:
— aria-autocomplete — показывает, применяется ли автозаполнение для текстового поля;
— aria-checked — показывает состояние «checked» у чекбоксов или радиокнопок;
— aria-disabled — показывает состояние «disabled» у элементов упражнения;
— aria-expanded — показывает, развернут или свернут текущий элемент;
— aria-hidden — показывает состояние «hidden» у текущего элемента;
— aria-multiline — показывает возможность многострочного ввода у текстового элемента;
— aria-multiselectable — показывает возможность множественного выбора у элементов управления у тега ;
— aria-orientation — показывает положение элемента (горизонтальное или вертикальное);
— aria-readonly — показывает состояние «readonly» у элементов управления;
— aria-required — аналог HTML5 атрибута required;
— aria-selected — показывает состояние «selected» у элементов управления;
— aria-sort — показывает порядок сортировки у строк таблицы или элементов с ролью «grid».
Атрибуты для Live Region
Live Region — это элементы страницы, обновляемые в результате внешнего события, обычно вне пользовательского фокуса. Канонический пример Live Region — информер биржевых сводок.
Задача этих атрибутов — отобразить, какие изменения содержимого могут произойти, когда элемент не в фокусе, и обеспечить вспомогательным технологиям информацию о способе обработки обновления этого содержимого.
— aria-busy — указывает, обновляются ли элемент и его поддерево, в настоящее время.
— aria-live — указывает, что элемент будет обновлен, и описывает типы обновлений браузеру.
Атрибуты перетаскивания (Drag-and-Drop)
Тут все понятно — эти атрибуты обеспечивают эффект drag-and-drop:
— aria-grabbed — указывает, может ли элемент быть захвачен перетаскиванием;
— aria-dropeffect — определяет функции, которые могут быть задействованы в процессе и при завершении перетаскивания.
В этой секции — атрибуты, указывающие на отношения или ассоциации между элементами, которые не могут быть полностью определены структурой документа.
— aria-activedescendant — указывает на элемент, чей контент является активным потомком составного виджета;
— aria-controls — указывает элемент (элементы), чьим содержанием или поведением управляет текущий элемент;
— aria-describedb — указывает элемент (или элементы), описывающие объект;
— aria-owns — определяет положение в иерархии документов по схеме потомок/родитель;
— aria-posinset — определяет позицию элементов наборе;
— aria-setsize — определяет число пунктов в текущем наборе lis-titems или treeitems.
По состоянию на сегодняшний день это почти все, ну а чтобы покончить с этой непростой темой, приведем как пример использования технологии реализацию дерева на html-разметке с применением WAI-ARIA (пример из спецификации):
Валидация HTML5-форм
В этой статье, я собираюсь разобрать валидацию на примере простой формы заказа, используя Constraint API, сделав акцент на том, чтобы не снизить удобства использования.
Несмотря на то, что использование валидации форм на стороне клиента очень удобно и позволяет быстро оповестить пользователя об ошибках во введенных данных без необходимости обращения к серверу, это не отменяет необходимости проверять данные перед их отправкой.
Давайте разберем пример, чтобы понять, как можно проводить валидацию, используя лишь встроенные средства браузера. Ниже приведен код простой формы заказа:
Метки также помогают сделать интерфейс более наглядным. Для слабовидящих людей это незаменимо – программа, читающая с экрана, будет произносить текст метки, давая пользователю понять назначение поля. Также это полезно, чтобы указать на обязательные к заполнению поля, как это сделано в примере выше.
Это отображается, когда поле ввода получает фокус, предоставляя контекстно-зависимую справку:
Чтобы провести валидацию этой формы, нам необходимо:
Обязательные поля
Если мы попытаемся отправить данную форму, не заполнив всех обязательных полей, браузер оповестит о необходимости это сделать:
Наверное, вы заметили, что наличия атрибута ‘required’ в тегах меток для обязательных полей теперь не требуется. Это сделано потому, что программы, читающие с экрана, указывают наличие атрибута required также и для меток. В таком случае, сообщение о том, что поле обязательно к заполнению, прозвучит два раза, что, естественно, лишнее.
Предупреждение: не все браузеры имеют поддержку атрибута required, поэтому в некоторых комбинациях « браузер/программа чтения с экрана » могут возникать ошибки. Поэтому, на данный момент лучшей практикой будет указание атрибута aria-required=”true” :
Валидация данных
Теперь, после того как пользователь ввел данные в обязательные поля, нам необходимо убедиться, что они заполнены в соответствии с требуемым форматом.
Нам нужно, чтобы содержимое поля ‘Name’ имело формат ‘ Firstname Lastname ‘ и включало в себя только буквы и пробелы (в реальных сценариях, возможно, нужно будет принять во внимание и другие символы).
Этого можно достичь, добавив атрибут pattern к полю ‘Name’, установив его значение в виде регулярного выражения, которое описывает правило, которому должны соответствовать вводимые данные:
Вы можете помочь пользователю, использовав атрибут title, который подсказывает требуемый формат ввода:
Текст в атрибуте title затем присоединяется к встроенному валидационному сообщению:
Стоит заметить, что некоторые сочетания « программа чтения с экрана/браузер » могут привести к ситуации, когда значение атрибута title будет прочитано несколько раз, в дополнение к тексту атрибута aria-describedby, поэтому обратите на это внимание.
К примеру, я обнаружил, что использование программы NVDA с IE10 ведет к двойному прочтению: как атрибута title, так и aria-describedby. Однако NVDA с Chrome и Firefox ведет себя совершенно нормально – читается только текст атрибута aria-describedby.
Далее, мы рассмотрим этот вопрос и покажем решение с использованием CSS3.
Валидация email, URL и номеров
Чтобы убедиться, что пользователь ввел верные данные в поля email, website и number of tickets, мы можем использовать новые элементы ввода, появившиеся в HTML5:
Выбрав соответствующий тип поля, мы можем поручить браузеру проверку на наличие и правильность введенных данных.
Также заметим, что атрибут type больше не является обязательным. Если вы явно не укажете тип элемента ввода, то по умолчанию он будет равен type=»text».
Предположим, что мы хотим ограничить число билетов, которое может купить один человек. Это можно реализовать, используя атрибуты max и min :
Если пользователь введет число меньшее 1 или большее 4, то выведется сообщение о том, что диапазон ввода ограничен.
Использование CSS для подсветки обязательных полей и неверно введенных данных
Вкупе с новыми типами элементов ввода и атрибутами, появившимися в HTML5, CSS3 также предлагает новые псевдоклассы, которые можно использовать для визуальных подсказок пользователю о том, какие поля являются обязательными, какие опциональными, а какие содержат ошибки валидации.
Селекторы обязательных полей могут использовать псевдокласс :required :
А дополнительные – псевдокласс :optional :
Успешное или неудачное прохождение процедуры валидации может показываться пользователю с помощью псевдоклассов :valid, :invalid, :in-range и :out-of-range :
Ранее, я заметил, что определенные сочетания « программа чтения с экрана/браузер » ведут к двойному прочтению атрибутов title и aria-describedby.
Что ж, одним из способов обойти это препятствие является удаление атрибута title из тега элемента ввода и использование CSS3-псеводкласса :invalid, чтобы показать текст атрибута aria-describedby:
Далее, в дополнение к отображению текстовой справки при получении полем ввода фокуса, мы будем отображать эту подсказку, когда в поле ввода внесены неверные данные.
После всех манипуляций HTML-код должен выглядеть так:
Отключение встроенной в браузер валидации
Вы можете отключить встроенную в браузер валидацию, добавив атрибут novalidate к тегу
Кроссбраузерность
Хорошая новость состоит в том, что валидация HTML-форм поддерживается всеми новыми браузеры для настольных компьютеров и большинством мобильных браузеров.
Плохая же новость заключается в частичной поддержке в настольной версии Safari и её отсутствии во всех браузерах iOS Safari и в стандартных браузерах для Android. Если вам нужна поддержка старых версий IE (ниже версии 10), то там вы ее также не обнаружите.
Что же можно сделать, если требуется поддержка браузеров, которые не имеют встроенных средств валидации?
Первый вариант это положиться на валидацию на стороне сервера. Это не потребует от вас дополнительной работы и, в то же время, позволит пользоваться предлагаемыми возможностями тем, чьи браузеры не поддерживают клиентскую валидацию.
Второй способ это продолжить использовать исключительно JavaScript для валидации на стороне клиента, не добавляя возможности, которые были обсуждены выше.
Третий подход подразумевает использование JavaScript для обнаружения поддержки валидации форм в браузере, и, если таковая имеется, то использовать её; в противном же случае обратиться к JavaScript-валидации.
Библиотеки наподобие Modernizr могут помочь обнаружить поддержку HTML5, но вы всегда можете написать собственный код, если не хотите подключать стороннюю JavaScript-библиотеку:
Заключение
В этой статье мы обзорно изучили использование HTML5-валидации форм на стороне клиента, приведя пример её применения в форме заказа, и при этом мы не пользовались средствами JavaScript.
Также мы указали на некоторые вопросы, связанные с реализацией поддержки для людей с ограниченными возможностями, которые стоит иметь ввиду.
Также, было рассмотрено использование новых CSS3-псеводклассов для отображения визуальных подсказок о том, какие поля обязательны к заполнению, а какие нет, какие поля заполнены правильно, а какие — нет.
Наконец мы поговорили об отключении HTML-валидации форм и обнаружении поддержки этой возможности в различных браузерах.
HTML5 атрибуты форм (часть 1)
Дата публикации: 2017-03-09
От автора: данная статья является выдержкой из книги HTML5 и CSS3 для реального мира, 2-е издание за авторством Алексиса Гольдштейна, Луи Лазариса и Эстель Вейль. Книгу можно найти в магазинах по всему миру, а также купить цифровую версию.
Атрибут required
Булев атрибут required говорит браузеру, что форму можно отправить только при заполнении этого поля. То есть поле не может быть пустым. Однако это также значит, что поле может поддерживать только заданные типы значений. Далее в этой главе мы расскажем про разные способы установки определенных типов данных для формы.
Если обязательное поле пустое, форма не отправится. Opera, Firefox, Internet Explorer 10+ и Chrome выдают пользователю сообщение с ошибкой. Например, «пожалуйста, заполните это поле» или «необходимо указать значение».
Заметка: пора сосредоточиться
Пора освежить память: элемент формы получает фокус по клику на поле мышкой, касанию поля пальцем на устройстве с тачскрином, нажатию клавиши tab на клавиатуре, а также по клику или касанию на лейбл, привязанный к этому элементу формы. В полях input ввод с клавиатуры забивает данные в сам элемент.
По терминологии JS событие focus срабатывает на элементе, когда он получает фокус, а событие blur запускается при потере фокуса.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
В CSS для стилизации элементов с фокусом можно использовать псевдокласс :focus.
Атрибут required подходит для любых типов полей кроме button, submit, image, range, color и hidden. У всех этих типов есть значение по умолчанию, поэтому данный атрибут здесь лишний. Как и с другими Булевыми атрибутами, синтаксис простой: required или required=»required» на XHTML.
Добавим атрибут required в форму регистрации. Сделаем обязательными поля имя, email, пароль и начальная дата оформления подписки:
Заметка: улучшаем доступность
Для улучшения доступности можно добавить WAI-ARIA атрибут aria-required=»true». Большая часть браузеров и скрин ридеров уже имеют встроенную поддержку атрибута required, так что скоро WAI-ARIA атрибут станет не нужен. Краткое введение в WAI-ARIA смотрите в Приложении В.
На рисунках 4.1, 4.2 и 4.3 показано поведение атрибута required при попытке отправить форму.
Рисунок 1 сообщение о проверке обязательного поля в Firefox
Рисунок 2 сообщение в Opera
Рисунок 3 и в Google Chrome
Стилизация обязательных полей формы
Обязательные поля формы можно стилизовать через псевдокласс required, необязательные поля через псевдокласс optional (или с помощью отрицательного псевдокласса :not(:required)). Также можно стилизовать валидные и невалидные поля с помощью :valid и :invalid. Эти псевдоклассы и немного CSS магии подскажут зрячим пользователям, какие поля обязательны, а также сообщат об успешном вводе данных:
Мы добавим фоновое изображение (звездочку) к обязательным полям формы. Использовать сгенерированный контент на полях input не получится, он заменяется на пустые элементы. Поэтому мы добавим фоновое изображение. Также добавим разные фоновые изображения для валидных и невалидных полей. Изменения будут видны только при получении элементом фокуса, чтобы не загромождать форму.
Предупреждение: Firefox применяет стили к невалидным элементам
Обратите внимание, что Firefox применяет свои стили к невалидным элементам (красная тень). Посмотреть пример можно на рисунке 1 выше. Возможно, вы захотите избавиться от нативной тени с помощью CSS:
Совет: таргетированные стили для старых браузеров
Старые браузеры типа IE8 и IE9 не поддерживают псевдокласс :required, но можно использовать таргетированные стили с помощью селектора с атрибутом:
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Этот атрибут можно использовать как хук для валидации форм в браузерах без поддержки HTML5 валидации форм. JS код может проверять инпуты без значений на наличие атрибута required и не отправлять форму, если таковой найден.
Атрибут placeholder
Атрибут placeholder позволяет отображать небольшую подсказку (если таковая имеется) внутри поля формы, которая будет говорить пользователю, какой тип данных принимается данным полем. Текст плейсхолдера пропадает, когда поле получает фокус, и пользователь ввел хотя бы один символ. Подсказка появляется снова, когда значение становится null. Разработчики уже много лет пользовались похожим функционалом на JS. Добавлялось временное значение, которое по фокусу очищалось. Сейчас же HTML5 атрибут placeholder позволяет сделать это нативно без подключения JS. Текст остается виден до тех пор, пока не будет введено значение.
В форме регистрации на сайте The HTML5 Herald мы добавим атрибут placeholder к полю URL и стартовой дате подписки:
В IE поддержка атрибута placeholder появилась только с версии 10. Текст подсказки исчезает, как только пользователь ввел данные. Поэтому не стоит полагаться только на такой способ информирования пользователей. Если подсказка не помещается в поле, опишите требования в атрибуте title данного поля, лейбле или рядом с полем. Многие советуют добавлять «например» в подсказку, чтобы точно дать понять, что это плейсхолдер, а не заполненные данные.
Все браузеры с Safari 4, Chrome 10, Opera 11.1, Firefox 4, Android 2.3 и Internet Explorer 10 поддерживают атрибут placeholder, хотя начальная имплементация placeholder удаляла текст при получении фокуса, а не при вводе текста.
Поддержка полифилов на JS
Как и все остальное в этой главе, атрибут placeholder не будет лишним даже в старых браузерах без поддержки.
Как с атрибутом required, атрибут placeholder и его значение можно использовать в старых браузерах. Однако для этого понадобится небольшой JS полифил.
Что нужно сделать: сперва с помощью JS определите браузеры без поддержки. Затем с помощью функции создайте ложный плейсхолдер. Функция должна определить, в каких полях есть атрибут placeholder, после чего временно взять из них контент и вставить его в качестве значения в атрибут value.
Далее необходимо настроить два обработчика событий: первый для очистки значения поля по фокусу, второй для замены значения placeholder по событию blur, если значение поля осталось пустым. Если хотите воспользоваться этим трюком, проверьте, чтобы значение атрибута placeholder не совпало с тем, что может вбить пользователь. Можете использовать приставку «например», чтобы дать понять, что плейсхолдер это просто пример, а не правильное значение. Не забудьте очистить ложный плейсхолдер при отправке формы. Или вы получите много “(XXX) XXX-XXXX подписок!
Рассмотрим пример кода на JS, который с помощью техники прогрессивного улучшения работает с элементами формы, у которых есть атрибут placeholder.
Первое, на что следует обратить внимание в этом скрипте – это то, что для определения поддержки атрибута placeholder мы используем JS библиотеку Modernizr. В Приложении А Modernizr описана более подробно. Сейчас же достаточно знать, что эта библиотека дает нам целый набор свойств с true и false для определенных HTML5 и CSS3 нововведений. Свойство, которое мы будем использовать, говорит само за себя. Modernizr.input.placeholder будет true, если браузер поддерживает placeholder, и false, если нет.
Если мы определили, что placeholder поддерживается, необходимо взять все элементы на странице с атрибутом placeholder. Далее у всех полей проверяется значение на пустоту, после чего значение заменяется на значение атрибута placeholder. В процессе всего этого элементу добавляется класс placeholder, через который можно осветлить цвет шрифта через CSS или сделать его наоборот больше похожим на родной. Когда пользователь фокусируется на поле с ложным плейсхолдером, скрипт очищает значение и удаляет класс. Когда пользователь смещает фокус, скрипт проверяет поле на значение. Если оно пусто, текст плейсхолдера и класс возвращаются.
Перед отправкой формы необходимо проверить все поля формы на совпадение значения с атрибутом placeholder. Также можно было бы проверить, остался ли класс placeholder на обязательных полях при отправке формы. Если в форме нужно что-то исправить, мы формируем сообщение об ошибке и запрещаем отправку. Если форма валидна, очищаем значения плейсхолдеров. Очищаем только плейсхолдеры обязательных полей.
Перед добавлением кнопки сброса формы подумайте, а захотят ли ваши пользователи стереть все данные. Если ответ да, и вы добавите кнопку сброса, учтите, что после нажатия на reset ложные плейсхолдеры исчезнут, а класс placeholder останется, так как он используется в полифиле.
Это хороший пример HTML5 полифила: с помощью JS мы добавляем поддержку только в те браузеры, в которых ее нет. И делаем это мы с помощью HTML5 элементов и атрибутов, которые уже есть в разметке, не прибегая к дополнительным классам и жестким значениям в JS коде.
Атрибут placeholder может быть не так важен для создания полифила, но это хороший пример того, как можно упростить скрипт валидации формы, обеспечивая поддержку всех новых атрибутов через полифил. И все это с разделением контента и представления.
Автор: Alexis Goldstein, Estelle Weyl, Louis Lazaris
Источник: //www.sitepoint.com/
Редакция: Команда webformyself.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Пять правил использования ARIA
Эта статья — вольный перевод оригинала. Я добавляю свои примеры и мысли, пишу как чувствую и ставлю смайлики 🙂 Автор статьи сказал, что ему понравилась моя интерпретация! Джерард занимается доступностью в Twitter и попросил поделиться с вами ссылкой на его курсы по доступности. Курсы лаконичные и очень понятные, я их посмотрела по 10-дневной бесплатной подписке. Итак, к делу!
Опасности, которые таит в себе ARIA Скопировать ссылку
В оригинальной статье введение более содержательное, так что почитайте его хотя бы ради практики английского языка 🙂 Я передам только несколько тезисов — прим. переводчицы.
ARIA — (Accessible Rich Internet Applications) это набор атрибутов, который позволяет сделать наши приложения более доступными, особенно если они написаны на JS. Из моего опыта — это, например, легаси-код, где давно-давно наверстали дивами, а теперь надо как-то добавить доступность, но нет доступа к HTML.
Если вы хотите познакомиться с ARIA — начинайте с официальных спецификаций. Не нужно сразу читать их глубоко и полностью, но парочку секций лучше изучить. Например, самое важное, с чем следует ознакомиться в спеке — это понятие роли.
Роль — это семантика вашего элемента, подсказка для ассистивных технологий, что можно делать с этим элементом, как его обрабатывать, как с ним взаимодействует клавиатура и так далее.
В ассистивные технологии входят скринридеры, брайлевские клавиатуры, голосовые помощники и другие средства доступа к информации, помимо привычных клавиатур, экранов и мышей.
Важно: роли (и вообще любые ARIA-атрибуты) не добавляют элементам никаких стилей и поведения!
У ролей есть классификация. Например, бывают роли для виджетов, для структуры документа, для лайв-областей, которые как-то обновляются на фоне независимо от действий пользователя и о чём-то ему сообщают. Практически для каждой роли есть свой набор обязательных ARIA-атрибутов. Некоторые роли нельзя использовать отдельно от родительских ролей.
Вот и пробежались по введению в статью 🙂 Переходим к правилам!
Пять правил использования ARIA Скопировать ссылку
Если вы уже понимаете, что вынуждены как-то накручивать доступность на ваши интерфейсы, нужно следовать нескольким основным правилам. Это облегчит принятие решений при разработке приложений и конкретно виджетов.
Правило 1 Скопировать ссылку
Не используйте ARIA
Читая это правило, я всегда очень радуюсь — так однозначно и бескомпромиссно оно звучит 🙂 На практике смысл его в том, что сначала вы должны полностью положиться на HTML и использовать его семантику, и только тогда, когда вам не хватило или есть какой-то сложный составной случай (например, аккордеон или вкладки) — тогда подключайте ARIA. Также приходится использовать эти волшебные атрибуты в уже упомянутом мной легаси-коде, где нет доступа к HTML и можно только с помощью JS добавлять что-то к существующим тегам.
Правило 2 Скопировать ссылку
Не изменяйте семантику нативных контролов.
Вы уже начали писать чистый, красивый и семантичный HTML, но поняли, что везде используете таблицы для вывода простых списков. У вас есть возможность явно задать элементу роль, чтобы переопределить его семантику:
Так вот, не переопределяйте дефолтную семантику без острой необходимости! Лучше замените тег:
