Від автора: атрибут title завжди оточений галасом. І зрозуміло, чому презирство до атрибуту в значній мірі виправдано. В червні 1993 року, двадцять чотири з половиною роки тому, title був запропонований в рамках проекту HTML 1.2. В основному він відображається як підказка в настільних браузерах, або, коли користувацька миша наводиться на елементи розмітки, де встановлений цей атрибут. З-за цього з моменту його створення він став універсальною задачею забезпечення зручності використання, так як не всі користувачі могли постійно взаємодіяти з ним.
Помилкові і застарілі методи SEO поряд із загальними непорозуміннями в правильному використанні перетворили title в парію для багатьох розробників і зміцнили його слабку репутацію.
Якби цього було недостатньо, керівництво по специфікації W3C HTML досить складне: В даний час покладатися на 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 призначені для опису дескриптивного тексту. І в основному тільки в ситуаціях, коли немає доступного імені зображення, поля форми або елемента прив’язки, заголовок буде підвищений до доступного імені. Наприклад:
В значній мірі по всьому екрану зчитувачі екрану оголосять title як доступне ім’я елемента в прикладі коду. (перевірте, будь ласка, з цією демонстрацією CodePen).
Але підтримка з боку, це ще не самий кращий вибір, як послідовне засіб для передачі доступної інформації. Тому що, хоча title забезпечує доступне ім’я елементів у відсутність інших джерел, він все ж вважається резервним. За винятком деяких помітних винятків (докладніше про це пізніше), інші механізми завжди будуть кращі.
Зображення
При використанні title замість зображення alt, як вже згадувалося, title буде використовуватися як доступне ім’я для зображення. Але, трохи відступлю, з цим є деякі проблеми. По-перше, валідатори все одно будуть видавати помилку, якщо alt відсутня в зображенні.
Валідатор Nu HTML раніше буде повертати помилку, оскільки відсутня alt, навіть якщо був встановлений title.
Крім того, якщо зображення має зламатися або бути цілеспрямовано придушене, більшість браузерів не будуть друкувати значення title на своєму місці.
Хром розбиває прес-форму так, як ніби немає alt і title відображається на екрані. Однак, оскільки ми повинні шукати надійність узгодженості, підтримка браузера раніше неадекватна.
Якщо хтось хоче надати зображення з додатковим контекстом, то title це поганий вибір з-за всіх тих речей, які ми вже розглянули, а також того факту, що цінність title повинна бути строго написана, щоб не викликати непотрібних многословности користувачів екранного читання. Наприклад:
Вищенаведене img має alt і title з тим же значенням, за винятком того, що alt починається з великої «А».
Ця, здавалося б, незначна різниця змушує VoiceOver + Safari читати обидва значення. Якщо зображення зламано, JAWS18 + Firefox також прочитають обидва значення. У сценаріях, де відображається зображення, title ігнорується на користь alt, навіть коли значення alt і title дуже різні. NVDA також ніколи не читає title, якщо існує alt.
Маючи відповідність alt і title можуть здатися дурницями для більшості, але це, на жаль, набагато більш поширено, ніж можна подумати. Як зазначалося раніше, здавалося б, незначні деталі, такі як капіталізація, можуть викликати повторювані оголошення, які, на жаль, також не унікальні для анонсів зображень.
Замість цього використовуються шаблони figure і figcaption, якщо додатковий контекст повинен бути переданий всім користувачам:
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.
Якірні посилання і поля форми
Давайте подивимося, title тарифи з посиланнями та полями форми (зокрема, текстові входи в цьому прикладі):
Щоб швидко узагальнити деякі висновки:
В залежності від взаємодії браузера і екрану, результати можуть бути не такими, як очікувалося. Результати залежать від методу навігації по документу.
Наприклад, при використанні клавіш arrow для навігації по контенту зазвичай ігнорує атрибут title.
Однак при використанні клавіш tab (або швидких клавіш читання з екрану) зазвичай оголошуються як доступне ім’я, так і значення.
Як згадувалося в зображеннях, різні комбінації браузерів і скрінсейверів будуть мати надлишкові оголошення, якщо title і доступні значення імені мають незначні відмінності у капіталізації. У деяких випадках однакові значення можуть видавати індивідуальні оголошення залежно від режиму читання з екрану + браузера.
Це поширене зловживання title атрибутом:
Home
Там, де розробники можуть подумати, що вони «допомагають» в доступності посилань, це фактично робить посилання дратівної для розбору, оскільки «home» оголошується двічі.
У контексті inputs title можна вважати корисним, щоб допомогти передати контекстуальну допомогу для введення даних. Тобто, якби не той факт, що за межами браузерів Microsoft спостережувані користувачі клавіатури не будуть мати доступ до підказці при початковому фокусі введення.
Крім того, атрибути title і aria-describedby погано працюють разом. Що має сенс: title це aria-describedby, як label є aria-label.
Візьміть до уваги наступне:
Set Username
У наведеному вище прикладі показано, що 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, який застосовується лише для невеликої кількості невідомих користувачів. Наприклад:
Use at least one special character, so as to better
ensure you’ll consistently forget your password and
throw your keyboard out a window.
Використання кутового випадку Title із входами
Незважаючи на те, що рекомендація повинна полягати в тому, щоб просто триматися подалі від title атрибута для введення даних, насправді існує пара прикладів, коли використання title як доступного імені буде правильному рішенням.
Пошук inputs або inputs в таблицях
Ви, мабуть, зустрічали ці шаблони багато разів. Пошук в заголовку документа, де немає видимого ярлика. Або як inputs (прапорці або текстові входи) в таблицях, де прапорець може використовуватися для маркування рядків для редагування або видалення. Або текстовий enter, тому окремі дані клітинок можуть бути змінені.
У разі введення пошуку зазвичай є збільшувальне скло у вигляді значка на вході. Шаблон настільки поширений, що місце розташування і значок зазвичай є єдиними посиланнями, цілі введення яких користувач повинен розуміти. Замість того, щоб створювати візуально приховану мітку або використовувати aria-label, щоб оголосити доступне ім’я input, використовуйте title=»Search site/app». Ви отримаєте безкоштовну підказку для користувачів і доступне ім’я, яке вам потрібно для читання екрану.
Що стосується inputs в таблицях, часто недостатньо місця, щоб виділити видиму мітку для введення. Однак, якщо таблиця налаштована відповідним чином з чітко визначеними заголовками стовпців і/або рядків, то потенційні користувачі можуть, ймовірно, об’єднати мета цих входів. Знову ж таки, замість використання прихованого тексту або ARIA, спробуйте використовувати власний атрибут title, щоб дати цим входів доступні унікальні імена.
Інші варіанти використання title
Поза потенційних можливостей використання елементів input присутні помітні випадки, коли рекомендований атрибут для доступу користувачів з точки зору доступності це title.
Використання abbr title на елементах
Скорочення, абревіатури та числонимы (наприклад, «a11y» ) вельми корисні для ущільнення довгого слова або слів у єдиний скорочений об’єкт. Але вони можуть бути неприємними для тих, хто не знайомий з стенографією.
Хоча завжди краще написати повну версію слова (ів) і зробити прямий зв’язок з їх скороченням або абревіатурою, елемент, використовуючи атрибут title, може допомогти зробити ці скорочення більш зрозумілими для деяких користувачів. Наприклад, введіть термін, використовуючи його в повному обсязі, з посиланням на стенографію:
The World Wide Web Consortium (W3C)…
Потім, коли цей термін використовується знову, оберніть його abbr елементом і встановіть повне значення title.
Again, the W3C…
Оскільки abbrэлемент не є і не повинен бути невід’ємно ориентируемого, підказка title не буде доступна через стандартну навігацію по клавіатурі. Але люди, що використовують певні програми читання екрану і браузери, будуть оголошені ним title, замість видимої стенографії.
Якщо ви спробуєте це зробити і не чуєте оголошені title, вам може знадобитися змінити налаштування екрану. Наприклад, щоб включити цю функцію з JAWS, відкрийте вікно налаштувань і розгорніть групу Web / HTML / PDFs . Потім розгорніть групу читання і включіть абревіатуру Blamo. Замість абревіатури оголошується title.
Очевидно, що не доступне для всіх користувачів, використання title з abbr буде вважатися поліпшенням доступності для тих, у кого є правильні налаштування читання екрану, і користувачам миші. Незважаючи на це, як і раніше будуть користувачі, як побачили клавіатури користувачі, хто не в змозі отримати доступ до abbr title, використання яких не буде мати згубні наслідки для їх користувачів. Це до тих пір, поки повний термін використовується повністю і послідовно до його скорочення.
Використання title на iframe
На відміну від посилення символу abbr title на використання title на iframe дійсно важливо для відповідності критеріям успіху WCAG , так як це рекомендований спосіб надати доступне ім’я для фреймів, використовуючи тільки власний HTML. Наприклад:
title служить для того, щоб надати користувачам програми читання екрану розуміння вмісту iframe. Розуміння iframe title дасть їм контекст для контенту, з яким вони збираються взаємодіяти, і поставить будь-який контент, який користувач зустріне в ньому в перспективі.
Наприклад: «Чому тон автора змінюється так сильно? О, почекайте, це тому, що це зовсім інший сайт. Фантастика. Витягни мене звідси…»
Використання title на link і style
В останньому прикладі використання атрибута title документи, які надають альтернативні теми (різні таблиці стилів або style в head), title можуть використовуватися для позначення кожної з таблиць стилів для вибору користувача в браузері Chrome. Наприклад:
/* dark styles go here */
У фрагменті коду стандартна таблиця normalize.css і app.css будуть завантажуватися за замовчуванням, так як normalize.css не має атрибута title, а таблиця стилів app.css не має rel=»alternate».
CSS в app.dark.css і не повинна відображатися в браузерах, які поважають використання title атрибут style елементів. Якщо ви зберетеся пробувати, я настійно рекомендую перевірити всі браузери, просто щоб бути в безпеці.
Якщо ви використовуєте Firefox, перейдіть в меню «View menu», вибрати «Page Style», а потім виберіть «No Style», «Default Theme» або «Dark Theme».
Оскільки це використання title атрибута не має широкої підтримки від інших браузерів, це хороший приклад атрибута, надягають одяг в спортзал, який робить розтяжку, а потім дивиться Netflix з випивкою.
Це ганьба, тому що пропонуючи альтернативні таблиці стилів повинен бути ідеальний спосіб, що забезпечує користувачам вибір найкращого способу перегляду веб-сайту або програми. Наприклад, хочете підтримувати браузери, які не підтримують запит із зменшеним рухом ? Що ж, дуже шкода, що вони також, ймовірно, не підтримують альтернативну таблицю стилів, яка могла б переглянути дизайн, без необхідності покладатися на режим читання або власну таблицю стилів.
Для отримання додаткової інформації та робочої демо (з Firefox!), Дивіться MDN’s документацію по Alternate Style Sheets.
Висновок
Атрибут title надав проблиски його потенційної корисності. Але із-за деяких поганих практик і непослідовною підтримки багато випадків використання атрибутів заголовків шкідливі в кращому випадку для тих, хто має до них доступ.
Постійна відсутність підтримки з боку всіх постачальників браузерів для виявлення користувачів title, які не є користувачами миші, а також той факт, що спливаючі підказки в цілому викликають неадекватність користувальницьких інтерфейсів, повинні стримувати їх використання для більш простого і завжди доступного контенту.
