От автора: атрибут title всегда окружен шумихой. И понятно, почему презрение к атрибуту в значительной степени оправдано. В июне 1993 года, двадцать четыре с половиной года назад, title был предложен в рамках проекта HTML 1.2. В основном он отображается как всплывающая подсказка в настольных браузерах, или, когда пользовательская мышь наводится на элементы разметки, где установлен данный атрибут. Из-за этого с момента его создания он стал универсальной задачей обеспечения удобства использования, так как не все пользователи постоянно могли взаимодействовать с ним.
Ошибочные и устаревшие методы SEO наряду с общими недоразумениями в правильном использовании превратили title в парию для многих разработчиков и укрепили его слабую репутацию.
Если бы этого было недостаточно, руководство по спецификации HTML W3C довольно сложное: В настоящее время полагаться на title не рекомендуется, так как многие пользовательские агенты не предоставляют атрибут доступным образом, как этого требует спецификация (например, требуется, чтобы указывающее устройство, такое как мышь, вызывало всплывающую подсказку, что исключает пользователей keyboard-only и touch-only, или, например, любого, у кого есть современный телефон или планшет).
Поддержка доступности для различных программ чтения экрана поступает в dribs и drabs в течение многих лет жизни title. На самом деле, это намного проще, чем вы думаете.
Хотя большая поддержка должна быть хорошей, на самом деле это одна из самых больших проблем, с которой я сталкиваюсь при работе с атрибутом. Из-за неправильного использования поддержки чтения экрана опыт, который получают пользователи, может быть печальным.
Даже несмотря на то, что были написаны статьи , излагающие dosи dont для title, время и многие вещи изменились. Имея это в виду, я написал статью, которая не направленна на содействие использованию атрибута, поскольку я полностью согласен с заявлением, сделанным здесь:
Так что, если вы собираетесь остановиться на TLDR , тогда я прошу вас помочь исполнить желание Карла.
Но если вас в целом интересует текущее состояние поддержки доступности title, вы хотите узнать несколько примеров, где атрибут действительно может быть полезным, и понять, почему этой встроенной подсказке HTML никогда не удается оправдать ожидания, есть еще много, чего почитать.
Настройка уровня
Когда кто-то думает о title атрибуте, то, вероятно, в контексте ссылок. Если вы знакомы с управлением носителями в WordPress, вы также можете связать их с изображениями. Но знали ли вы о поддержке доступности title для полей формы? Знаете ли вы, что при выпуске спецификации HTML5 title он стал глобальным атрибутом и может использоваться для любого элемента HTML?
Что все это означает с точки зрения title «полезности»? И самое главное, что из этого действительно доступно?
Если бы title был просто :focus!
В течение всего времени большинство браузеров до сих пор не реализовали никакой поддержки title, чтобы выявить ценность атрибута для зрячих пользователей, не использующих мышь.
Это означает, что зрячие пользователи, использующие клавиатуру в качестве основного средства навигации по сети, скорее всего, не столкнутся со всплывающими подсказками title. Пользователи, которые полагаются на другие средства, такие как программное обеспечение для распознавания голоса, тоже не получат много пользы от title. По сути, если зависание не вариант, вы никогда не узнаете, что всплывающая подсказка существует.
Тем не менее, есть множество пользователей, которые могут получить доступ к некоторым файлам title в своем браузере на рабочем столе без мыши. До тех пор, пока они просматриваются с помощью Internet Explorer 10, 11 или Microsoft Edge.
Правильно, потребовалось девятнадцать лет, но начиная с Internet Explorer 10, выпущенного в 2012 году, сфокусированные элементы с titles отображают свои подсказки после короткой паузы, как если бы они были под зависшим курсором мыши.
Тем не менее, ни один поставщик браузеров, осуществляющий поддержку фокуса, не обеспечивает надежного доступа для всех. И никто не делает ничего, чтобы выявить неактивные элементы title, вроде изображений. И если вы думаете: «Ну, мы могли бы добавить tabindex=»0″к этим элементам, чтобы они реагировали на фокус клавиатуры», остановитесь. Просто остановись прямо сейчас.
Добавление tabindex к не-фокусируемым элементам приводит к дополнительным остановкам фокуса. Это создает плохое впечатление пользователей, нарушая ожидания того, что должно быть ориентируемо, и приводит к тому, что требуется больше времени для навигации по клавиатуре.
Теперь отодвинем tabindex в сторону, давайте не будем забывать о title на сенсорных устройствах. Если вы не используете устройство чтения экрана (немного подробнее об этом), title атрибуты почти полностью бесполезны, за исключением одного элемента: изображений.
Снимок экрана iOS 11 показывает, что title изображение будет отображаться в popover-меню, которое загружается, когда пользователь выполняет длительное нажатие на изображение. Это работает в мобильных Safari и Chrome на iOS и Chrome на Android. Но это не является неотъемлемой функцией всех мобильных браузеров. Например, используя Brave браузер iOS, title изображение не отображается при выполнении такого же длительного нажатия.
Опять же, один элемент, раскрывающий таким образом ценность title, который не является дискуссивно простым или хорошим пользовательским интерфейсом (UX), не универсален ни в коем случае.
Таким образом, с точки зрения полезности для зрячих пользователей, помимо нескольких примеров дополнительной поддержки, здесь и там, если не полагаться на использование мыши, title все еще довольно плох, особенно если они используется для не-фокусируемых элементов.
Что насчет экранных считывателей?
Хотя поддержка не идеальна, она может быть намного лучше, чем вы думаете. Понятно, что, если кто-то знает о проблемах доступности title для зрячих пользователей, почему бы не предположить, что пользователи с экрана читают лучше?
Вот где предположения и устаревшая информация о поддержке title омрачили некоторые из достижений атрибута.
Хотя он title может использоваться для любого элемента HTML, в отношении считывателей экрана он в первую очередь остается полезным (более или менее) только для некоторых элементов.
Глобальные элементы
Хотя атрибут title может использоваться для любого элемента HTML, он по существу растрачивается на большинство встроенных элементов текстового уровня. Поскольку эти элементы обычно не включены в дерево доступности , нет никаких оснований для того, чтобы считыватель экрана искал информацию об этих элементах для объявления.
Элементы обтекания блока могут получить некоторое использование из title. JAWS, NVDA и VoiceOver будут все объявлять title об элементах как ориентиры (header, footer, main и т.д.), но поддержка может варьироваться в зависимости от других элементов и в зависимости от вашего браузера. Например, JAWS не будет анонсировать title на div без дополнительных role обновлений.
Другие элементы упаковки, такие как списки и абзацы, объявляются в JAWS и VoiceOver, но NVDA игнорирует атрибут этих элементов. Честно говоря, использование title подсказок на этих элементах очень подозрительно. Почему вы хотите, чтобы всплывающая подсказка постоянно появлялась на большом фрагменте контента? Если вы целенаправленно не пытаетесь скрыть контент, то, не думаю, что нужно использовать title.
Изображения, поля формы и привязки — это элементы, которые, скорее всего, будут ассоциироваться с title атрибутом. Что касается считывателей экрана, атрибут title по существу получает оценку «B» при просмотре общедоступных графиков поддержки чтения экрана от powermapper.com.
Атрибуты title предназначены для описания дескриптивного текста. И в основном только в ситуациях, когда нет доступного имени для изображения, поля формы или элемента привязки, заголовок будет повышен до доступного имени. Например:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<img src="my-image.jpg" title="The 3 little pigs build their houses"> <input type="text" title="First Name"> <a href="/" title="home" style=" display: inline-block; height: 20px; width: 20px; background: url(home-icon.png) no-repeat; "></a> |
В значительной степени по всему экрану считыватели экрана объявят title как доступное имя элемента в примере кода. (проверьте, пожалуйста, с этой демонстрацией CodePen).
Но поддержка со стороны, это еще не самый лучший выбор, как последовательное средство для передачи доступной информации. Потому что, хотя title обеспечивает доступное имя элементам в отсутствие других источников, он всё же считается резервным. За исключением некоторых заметных исключений (подробнее об этом позже), другие механизмы всегда будут предпочтительнее.
Изображения
При использовании title вместо изображения alt, как уже упоминалось, title будет использоваться как доступное имя для изображения. Но, немного отступлю, с этим есть некоторые проблемы. Во-первых, валидаторы все равно будут выдавать ошибку, если alt отсутствует в изображении.
Валидатор Nu HTML по-прежнему будет возвращать ошибку, поскольку отсутствует alt, даже если был установлен title.
Кроме того, если изображение должно сломаться или быть целенаправленно подавлено, большинство браузеров не будут печатать значение title на своем месте.
Хром разбивает пресс-форму так, как будто нет alt, title отображается на экране. Однако, поскольку мы должны искать надежность согласованности, поддержка браузера по-прежнему неадекватна.
Если кто-то хочет предоставить изображение с дополнительным контекстом, то title это плохой выбор из-за всех тех вещей, которые мы уже рассмотрели, а также того факта, что ценность title должна быть строго написана, чтобы не вызывать ненужной многословности пользователей экранного чтения. Например:
|
1 |
<img src="banana.jpg" alt="A yellow banana" title="a yellow banana"> |
Вышеприведенное img имеет alt и title с тем же значением, за исключением того, что alt начинается с заглавной «А».
Эта, казалось бы, незначительная разница заставляет VoiceOver + Safari читать оба значения. Если изображение сломано, JAWS18 + Firefox также прочитают оба значения. В сценариях, где отображается изображение, title игнорируется в пользу alt, даже когда значение alt и title очень разные. NVDA также никогда не читает title, если существует alt.
Имея соответствие alt и title могут показаться глупостью для большинства, но это, к сожалению, намного более распространено, чем можно подумать. Как отмечалось ранее, казалось бы, незначительные детали, такие как капитализация, могут вызывать повторяющиеся объявления, которые, к сожалению, также не уникальны для анонсов изображений.
Вместо этого используются шаблоны figure и figcaption, если дополнительный контекст должен быть передан всем пользователям:
|
1 2 3 4 5 6 7 8 |
<figure> <img src="banana.jpg" alt="a banana"> <figcaption> <p>Outside of knowing this is an image of a banana, here is context, useful to all users, as to why said banana image was included here. Now you know.</p> </figcaption> </figure> |
Якорные ссылки и поля формы
Давайте посмотрим, title как тарифы со ссылками и полями формы (в частности, текстовые входы в этом примере):
Чтобы быстро обобщить некоторые выводы:
В зависимости от взаимодействия браузера и экрана, результаты могут быть не такими, как ожидалось. Результаты зависят от метода навигации по документу.
Например, при использовании клавиш arrow для навигации по контенту обычно игнорирует title атрибут.
Однако при использовании клавиш tab (или быстрых клавиш чтения с экрана) обычно объявляются как доступное имя, так и значение.
Как упоминалось в изображениях, разные комбинации браузеров и скринсейверов будут иметь избыточные объявления, если title и доступные значения имени имеют незначительные различия в капитализации. В некоторых случаях одинаковые значения могут по-прежнему выдавать индивидуальные объявления в зависимости от режима чтения с экрана + браузера.
Это распространенное злоупотребление title атрибутом:
|
1 |
<a href="/" title="home">Home</a> |
Там, где разработчики могут подумать, что они «помогают» в доступности ссылок, это фактически делает ссылку раздражающей для разбора, поскольку «home» объявляется дважды.
В контексте inputs title можно считать полезным, чтобы помочь передать контекстуальную помощь для ввода данных. То есть, если бы не тот факт, что за пределами браузеров Microsoft наблюдаемые пользователи клавиатуры не будут иметь доступ к подсказке при начальном фокусе ввода.
Кроме того, атрибуты title и aria-describedby плохо работают вместе. Что имеет смысл: title это aria-describedby, как label есть aria-label.
Примите во внимание следующее:
|
1 2 3 4 5 6 7 |
<label for="un"> Set Username </label> <input type="text" id="un" title="these special characters (!, *, $, %) are not allowed" aria-describedby="error_msg"> <span id="error_msg"></span> |
В приведенном выше примере показано, что input с title информирующие пользователей специальными символами запрещены. Опять же, эта информация недоступна для знакомых нам пользователей клавиатуры за пределами браузеров Microsoft, но давайте отложим это на минутку.
Считыватели экрана будут сообщать информацию о специальных символах, и это хорошо. Однако возникает проблема, если там пробирается специальный символ. Сообщение об ошибке обновляется и говорит: «Вы использовали специальный символ! Прекратите!». Примечание. Мне не разрешено писать копию ошибки.
Теперь текст title был заменен aria-describedby текстом ошибки, поэтому инструкции исчезли, и пользователь не может вспомнить, какие специальные символы не были разрешены. Бу.
Хотя я не являюсь частью первоначальных тестов, Стив Фолкнер отметил, что, если использовать валидацию формы HTML5 по умолчанию для браузера, то title можно использовать при отображении сообщения об ошибке для input.
Пример Chrome, отображающий сообщение об ошибке, используя сообщение обозревателя запаса и включая значение заголовка с отображаемой подсказкой всплывающей подсказки.
Ознакомьтесь со строкой валидации и title демо.
Краткое резюме результатов:
На Mac Safari не использует сообщение об ошибке title в строке. Chrome использует, но сообщение о валидации не объявляется с помощью VoiceOver.
В Windows, Firefox, IE11, Edge и Chrome все они используют title с собственным неверным сообщением об ошибке, которое появится при попытке отправить форму.
С NVDA, Chrome, Firefox и Edge объявят сообщение об ошибке title и значение в строке.
С JAWS18 только при использовании Firefox будет выдано неверное сообщение об ошибке и title будет объявлено.
В конечном счете, видимая метка с четкими инструкциями намного лучше для всех пользователей, включая тех, кто перемещается с помощью вспомогательных технологий, чем title, применяемый только для небольшого количества неизвестных пользователей. Например:
|
1 2 3 4 5 6 7 8 |
<div class="always-be-wrapping"> <label for="password"> Create password </label> <p id="instructions"> Use at least one special character, so as to better ensure you'll consistently forget your password and throw your keyboard out a window. </p> </div> |
Использование углового случая Title с входами
Несмотря на то, что рекомендация должна состоять в том, чтобы просто держаться подальше от title атрибута для ввода данных, на самом деле существует пара примеров, когда использование title как доступного имени будет правильном решением.
Поиск inputs или inputs в таблицах
Вы, вероятно, встречали эти шаблоны много раз. Поиск в заголовке документа, где нет видимого ярлыка. Или как inputs (флажки или текстовые входы) в таблицах, где флажок может использоваться для маркировки строки для редактирования или удаления. Или текстовый ввод, поэтому отдельные данные ячеек могут быть изменены.
В случае ввода поиска обычно есть увеличительное стекло в виде значка на входе. Шаблон настолько распространен, что местоположение и значок обычно являются единственными ссылками, цели ввода которых пользователь должен понимать. Вместо того, чтобы создавать визуально скрытую метку или использовать aria-label, чтобы объявить доступное имя input, используйте title=»Search site/app». Вы получите бесплатную подсказку для пользователей и доступное имя, которое вам нужно для чтения экрана.
Что касается inputs в таблицах, часто недостаточно места, чтобы выделить видимую метку для ввода. Однако, если таблица настроена соответствующим образом с четко определенными заголовками столбцов и/или строк, то потенциальные пользователи могут, вероятно, объединить цель этих входов. Опять же, вместо использования скрытого текста или ARIA, попробуйте использовать собственный title атрибут, чтобы дать этим входам уникальные доступные имена.
Другие варианты использования title
Вне потенциальных возможностей использования input элементов присутствуют заметные случаи, когда рекомендуемый атрибут для доступа пользователей с точки зрения доступности это title.
Использование title на abbr элементах
Сокращения, аббревиатуры и числонимы (например, «a11y» ) весьма полезны для уплотнения длинного слова или слов в единый сокращенный объект. Но они могут быть неприятными для тех, кто не знаком с стенографией.
Хотя всегда лучше написать полную версию слова (ов) и сделать прямую связь с их сокращением или аббревиатурой, элемент, используя title атрибут, может помочь сделать эти сокращения более понятными для некоторых пользователей. Например, введите термин, используя его в полном объеме, со ссылкой на стенографию:
|
1 2 3 |
<p> The World Wide Web Consortium (W3C)... </p> |
Затем, когда этот термин используется снова, оберните его abbr элементом и установите полное значение title.
|
1 2 3 |
<p> Again, the <abbr title="World Wide Web Consortium">W3C</abbr>... </p> |
Поскольку abbrэлемент не является и не должен быть неотъемлемо ориентируемым, всплывающая подсказка title не будет доступна через стандартную навигацию по клавиатуре. Но люди, использующие определенные программы чтения экрана и браузеры, будут объявлены им title, вместо видимой стенографии.
Если вы попробуете это сделать и не слышите объявленные title, вам может потребоваться изменить настройки экрана. Например, чтобы включить эту функцию с JAWS, откройте Центр настроек и разверните группу Web / HTML / PDFs . Затем разверните группу чтения и включите аббревиатуру Blamo. Вместо аббревиатуры объявляется title.
Очевидно, что не доступное для всех пользователей, использование title с abbr будет считаться улучшением доступности для тех, у кого есть правильные настройки чтения экрана, и пользователям мыши. Несмотря на это, по — прежнему будут пользователи, как увидели клавиатуры пользователи, кто не в состоянии получить доступ к abbr title, использование которых не будет иметь пагубные последствия для их пользователей. Это до тех пор, пока полный термин используется полностью и последовательно до его сокращения.
Использование title на iframe
В отличие от усиления символа title на abbr, использование title на iframe действительно важно для соответствия критериям успеха WCAG , так как это рекомендуемый способ предоставить доступное имя для фреймов, используя только собственный язык HTML. Например:
|
1 |
<iframe src="//scottohara.me" title="Scott's website"></iframe> |
title служит для того, чтобы предоставить пользователям программы чтения экрана понимание содержимого iframe. Понимание title iframe даст им контекст для контента, с которым они собираются взаимодействовать, и поставит любой контент, который пользователь встретит в нем в перспективе.
Например: «Почему тон автора изменяется так сильно? О, подождите, это потому, что это совсем другой сайт. Фантастика. Вытащи меня отсюда…»
Использование title на link и style
В последнем примере использования title атрибута документы, которые предоставляют альтернативные темы (разные таблицы стилей или style в head), title могут использоваться для обозначения каждой из таблиц стилей для выбора пользователя в браузере Chrome. Например:
|
1 2 3 4 5 6 |
<link rel="stylesheet" href="normalize.css"> <link rel="stylesheet" href="app.css" title="Default Theme"> <link rel="alternate stylesheet" href="app.dark.css" title="Dark Theme"> <style title="Dark Theme"> /* dark styles go here */ </style> |
В фрагменте кода стандартная таблица normalize.css и app.css будут загружаться по умолчанию, так как normalize.css не имеет title атрибута, а таблица стилей app.css не имеет rel=»alternate».
CSS в app.dark.css и <style title=»Dark Theme»> не должен отображаться в браузерах, которые уважают использование title атрибута для style элементов. Если вы соберётесь пробовать, я настоятельно рекомендую проверить все браузеры, просто чтобы быть в безопасности.
Если вы используете Firefox, перейдите в меню «View menu», выберите «Page Style», а затем выберите «No Style», «Default Theme» или «Dark Theme».
Поскольку это использование title атрибута не имеет широкой поддержки от других браузеров, это хороший пример атрибута, надевающего одежду в спортзал, который делает растяжку, а затем смотрит Netflix с выпивкой.
Это позор, потому что предлагая альтернативные таблицы стилей должен быть идеальный способ, обеспечивающий пользователям выбор наилучшего способа просмотра веб-сайта или приложения. Например, хотите поддерживать браузеры, которые не поддерживают запрос с уменьшенным движением ? Что ж, слишком жаль, что они также, вероятно, не поддерживают альтернативную таблицу стилей, которая могла бы пересмотреть дизайн, без необходимости полагаться на режим чтения или собственную таблицу стилей.
Для получения дополнительной информации и рабочей демо (с Firefox!), Смотрите MDN’s документацию по Alternate Style Sheets.
Заключение
Атрибут title предоставил проблески его потенциальной полезности. Но из-за некоторых плохих практик и непоследовательной поддержки многие случаи использования атрибутов заголовков вредны в лучшем случае для тех, кто имеет к ним доступ.
Постоянное отсутствие поддержки со стороны всех поставщиков браузеров для выявления пользователей title, не являющихся пользователями мыши, а также тот факт, что всплывающие подсказки в целом вызывают неадекватность пользовательских интерфейсов, должны сдерживать их использование для более простого и всегда доступного контента.
Автор: Scott O’Hara
Источник: //www.24a11y.com/
Редакция: Команда webformyself.
