Інструкції для забезпечення доступності веб-контенту — для тих, хто їх ще не читав
Оригінал: Алан Далтон
Перекладено Лінгвістичним Центром
Я став великим шанувальником Інструкцій щодо забезпечення доступності веб-контенту (WCAG)2.0 відтоді, як Всесвітній Веб-консорціум (W3C) опублікував їх дев’ять років тому. Я побачив, що ці інструкції практичні та стануть в пригоді в майбутньому, і що вони можуть заощадити величезну кількість часу для дизайнерів і розробників. Ви можете застосувати їх до всього, що можна відкрити в браузері. Мій улюблений момент це коли я керуюся цими інструкціями, щоб зробити веб-сайт доступним, а потім тестую сайт на доступність і бачу, що користувачі з особливими потребами легко ним користуються.
Наразі Міжнародний день людей з особливими потребами Організації Об’єднаних Націй може бути чудовою нагодою, щоб перечитати пояснення Лори Калбаг, чому ми повинні турбуватися про доступність. Саме це має мотивувати вас просто-таки поглинути цю статтю.
Якщо ви ще не читали Інструкції щодо забезпечення доступності веб-контенту 2.0, спершу вони можуть здатися дещо складними для сприйняття. Редакторам потрібно було створити єдиний стандарт, на який могло би посилатися законодавство різних країн світу, і тому частково стиль написання інструкцій містить дещо юридичний характер. Редакторам також потрібні були правила, які були б актуальні в майбутньому, і тому деякі терміни, такі як «часові медіа» та «програмно визначені», можуть звучати неоднозначно. Інструкції також можуть здаватися дуже великими за обсягом: друк інструкцій, документу Розуміння WCAG 2.0, а також документу Методи WCAG 2.0 займе 1200 друкованих сторінок.
Цієї святкової пори зірвімо ту юридичну та неоднозначну термінологію, як пакувальний папір, і розгляньмо все в одній-єдиній статті, що нам подарували редактори Інструкцій щодо забезпечення доступності веб-контенту 2.0.
Чи можуть користувачі вашого веб-сайту сприймати на ньому інформацію?
Перше правило має критерії, які допоможуть уникнути запитання від користувачів: «Що в **** це має означати?»
1.1.1 Текст — найбільш доступний формат подання інформації. Програми зчитування тексту з екрана, такі як функція «VoiceOver» на вашому iPhone або додаток «TalkBack» на телефоні з операційною системою Android, краще розуміють текст, ніж будь-який інший формат. Те саме стосується й інших допоміжних технологій, таких як програми для перекладу та дисплеї зі шрифтом Брайля. Отже, якщо на вашій веб-сторінці є будь-що інше, окрім тексту, потрібно додати текст, який даватиме користувачеві таку ж інформацію. Ви, напевно, вже знаєте, як це зробити. Наприклад:
○ щодо зображень на веб-сторінці, додайте альтернативний текст (Alt-текст) в атрибуті alt , щоб донести користувачеві те, що несе зображення;
○ щодо фотографій у твітах, додайте опис, щоб зробити зображення доступними;
○ щодо постів у Instagram, напишіть заголовок, який передасть інформацію про фото.
Alt-текст повинен дозволити користувачеві отримати ту саму інформацію, яку отримає той, хто може бачити зображення. Для веб-сайтів, які містять надто багато зображень, щоб додавати Alt-текст, розгляньте, як машинне навчання та Динамічно створений Alt -текст можуть — точніше могли би — допомогти.
Можливо, ви згадали декілька винятків, коли додавання тексту для опису зображень не має сенсу. Пам’ятаєте, я писав, що ці інструкції «практичні»? Вони охоплюють всі ці винятки:
○ Керування інтерфейсом користувача , наприклад, кнопки та введення тексту повинні мати назви або мітки, щоб повідомити користувача, які функції вони виконують.
○ Якщо ваша веб-сторінка містить відео або аудіо (пізніше ми докладніше це розглянемо!), потрібно, принаймні, мати текст, щоб сказати користувачеві, про що йдеться у цих матеріалах.
○ Можливо, ваша веб-сторінка містить тест, де користувач має відповісти на питання про зображення чи звук, тож Alt-текст видасть відповіді. У цьому випадку просто опишіть тест у текстовому форматі, щоб користувач розумів, про що у ньому йде мова.
○ Якщо ваша веб-сторінка містить зображення витворів мистецтва, опишіть користувачеві, які емоції вони викликають.
○ Якщо ви хочете додати тест Captcha (повністю автоматизований публічний тест Тюринга для розрізнення комп’ютерів і людей) на вашу веб-сторінку, — все ж, будь ласка, уникайте Captcha, якщо це можливо, оскільки деякі користувачі не можуть пройти їх — потрібно додати текст, щоб повідомити користувача що таке Captcha і переконатися, що ця перевірка не полягає в застосуванні лише одного чуття, наприклад, зору.
○ Якщо ви додали щось схоже на декорації, слід переконатися, що допоміжні технології користувача зможуть їх пропускати. Знову ж таки, ви, напевно, знаєте, як це зробити. Наприклад, ви можете використовувати CSS замість HTML, щоб додати декоративні зображення, або можна додати порожній атрибут alt до елемента img . (Будь ласка, уникайте останньої тенденції додавати порожні атрибути alt до всіх зображень на веб-сторінці просто, щоб перевірити структуру HTML коду. Ви можете зробити краще.)
(Зверніть увагу, що інструкції додають багато варіантів того, як їх дотримуватись відповідно до технології, яку ви обираєте. Щоб збудувати ваш веб-сайт відповідно до інструкцій, можна вибрати один з методів WCAG 2.0 до цих інструкцій або ж придумати власні методи. Зазвичай вибір перевіреної техніки заощаджує час!)
1.2.1 Якщо ваш веб-сайт містить епізод подкасту, промову, лекцію чи будь-який інший аудіозапис без відео, потрібно додати транскрипцію або інший текст, щоб забезпечити користувачів аналогічною інформацією. У багатьох випадках це може виявитись простіше, ніж ви очікуєте: професійні послуги з транскрипції можуть бути відносно недорогими та швидкими, а іноді спікер чи лектор можуть надати текст промови чи лекції, які вони дослівно читали. Просто переконайтеся, що всі ваші користувачі зможуть отримати однакову інформацію та ті самі результати, незалежно від того, чи вони чують звук. Наприклад, Девід Сміт і Марко Армент завжди публікують транскрипції епізодів їхнього подкасту Під радаром.
Аналогічно, якщо ваш веб-сайт містить записане відео без звуку, наприклад, анімацію чи рекламне відео, потрібно або використовувати текст, щоб в деталях подати, що відбувається у відео, або додати аудіо-версію. Знову ж таки, це може бути легше, ніж ви думаєте: наприклад, можна перевірити, чи анімація подає список інструкцій, чи рекламний відеоролик передає таку ж інформацію, що й веб-сторінка «Про нас». Вам потрібно переконатися, що всі ваші користувачі можуть отримати таку ж інформацію та ті самі результати, незалежно від того, чи зможуть вони переглянути це відео чи ні.
1.2.2 Якщо ваш веб-сайт містить записані відео з
аудіо, слід додати підписи до цих відео для користувачів з порушеннями слуху. Професійні послуги з транскрипції можуть надати вам текст із проміжками часу у форматі субтитрів, які підтримує YouTube, наприклад, у форматах .srt і .sbv. Ці формати можна завантажити на YouTube, і субтитри з’являться на ваших відео. YouTube може автоматично генерувати субтитри, однак якість вражає або неймовірною точністю, або ж комічною неточністю. Якщо у вас є текстова версія того, що розповідається у відео, наприклад, політична промова чи казка на ніч, яку читає актор, можна створити транскрипцію запису у .txt форматі без позначень відрізків часу. Тоді YouTube створить титри для вашого відео, синхронізуючи цей текст із звуком у відео. Якщо ви розміщуєте відео, то можете замовити послугу професійного транскрибування у форматі .vtt, ці файли можна додати до окремих рядків відео, або ж створити власні.
(Коротке пояснення: якщо на вашому веб-сайті є більше відео, ніж ви можете транскрибувати впродовж відведеного проміжку часу, визначте найпопулярніші і найважливіші відео, а також відео, які найбільш потрібні людям з інвалідністю. Тоді переконайтеся, що ваші користувачі знають, як попросити вас транскрибувати інші відео, коли стикаються з ними.)
1.2.3 Якщо на вашому веб-сайті записано відео з аудіо, ви повинні додати розповідь під назвою «аудіоопис» до відео, щоб описати важливі візуальні деталі або додати текст до веб-сторінки, щоб деталізувати, що відбувається у відео для користувачів, які не можуть його бачити. (Мені подобається додавати аудіофайли з відеокліпів у свій обліковий запис Huffduffer, завдяки чому я можу їх слухати під час поїздок.) Можливо, ваша домашня сторінка містить відео, де хтось каже: «Я хотів би пояснити наші нові звіти TPS (вимоги до процедур проведення тестування)», а в нижній частині екрана з’явиться Білл Лумберг, віце-президент відділу Initech. У такому випадку ви повинні додати аудіоопис до відео, з поясненням: «Білл Лумберг, віце-президент відділу Initech», перед тим як Білл почне говорити. Як завжди, ви можете полегшити собі життя, взявши до уваги всіх користувачів перед початком події. Наприклад, ви можете попросити спікера почати зі слів: «Я Білл Лумберг, віце-президент відділу Initech, і я хотів би пояснити наші нові звіти TPS», щоб вам пізніше не потрібно було витрачати час на додавання звукового опису.
1.2.4 Якщо на вашому веб-сайті є відео у реальному часі зі звуком, ви повинні скористатися послугами стенографіста, який створюватиме субтитри у реальному часі і які ви можете включити разом з відео. Буду чесним: сьогодні це зробити досить складно. Інструкції щодо забезпечення доступності веб-контенту 2.0 попередньо використовувалися у програмах YouTube Live, Instagram live Stories, Periscope та інших подібних сервісах. Якщо ваша організація створює багато відео у реальному часі, можливо, вам не вистачає ресурсів для синхронного відтворення субтитрів для кожного з них. У такому разі, якщо ви вже знаєте вміст аудіо, опублікуйте його під час відтворення відео або, якщо це не вдається, якомога швидше опублікуйте транскрибцію до нього.
1.2.5 Пам’ятаєте, що я сказав про записані відео зі звуком?
Якщо ви можете вибрати між додаванням аудіоопису або додаванням тексту на веб-сторінку, щоб надати деталі про те, що відбувається у відео, слід зробити вибір на користь аудіоопису.
1.2.6 Якщо ваш веб-сайт містить відео зі звуком, ви також можете використовувати мову жестів для передачі змісту аудіо, адже деякі люди розуміють мову жестів краще за текст. (Вам не потрібно створювати субтитри для відеоверсії мови жестів з аудіоінформацією.)
1.2.7 Якщо на вашому веб-сайті записано відео з аудіо, і вам потрібно додати аудіоопис, але в аудіоверсії не вистачає пауз, щоб додати його, то можна надати окрему версію цього відео, у якому додано паузи, щоб відео відповідало аудіоопису.
1.2.8 Повернімось знову до записаних відеозаписів зі звуком. Ви можете додати текст на веб-сторінку, щоб деталізувати, що відбувається у відео, щоб люди, які не можуть прочитати субтитри і чути звук та аудіоопис, могли використовувати дисплеї зі шрифтом Брайля для розуміння відео.
1.2.9 Якщо ваш веб-сайт містить відтворення аудіо у реальному часі, ви можете скористатися стенографом, щоб створювати синхронізовані субтитри. Знову ж таки, якщо ви заздалегідь знаєте вміст аудіо, якомога швидше опублікуйте його вміст або надайте транскрипцію.
(Вітаю! Ви вже далеко зайшли! Я знаю, що здається, ніби потрібно багато всього пам’ятати, але не забувайте, що ми працюємо зі складною сферою: ми допомагаємо розуміти мультимедійну інформацію людям з порушеннями зору та/чи слуху. Тепер можете порадіти та похвалити себе за свої старання та продовжити роботу.)
1.3.1 Ви повинні давати характеристику вмісту вашого веб-сайту, щоб браузер користувача та будь-які допоміжні технології, які вони використовують, допомагали зрозуміти структуру інформації та те, як кожен фрагмент інформації пов’язаний з іншим. Знову ж таки, ви, мабуть, знаєте, як це зробити: використовуйте найбільш відповідний елемент HTML для кожного фрагмента інформації. Позначте заголовки, списки, кнопки, радіокнопки, прапорці і посилання найбільш відповідним елементом HTML. Якщо вам нема чим зайнятися на Різдво, прокрутіть список елементів HTML. Ви помічаєте елементи, які вам незнайомі або якими ви ніколи не користувалися? Ви помічаєте елементи, які ви могли б використати у своїх поточних проектах, щоб точніше охарактеризувати вміст відео? Також перегляньте таблицю передових ознак і доступності, інформацію про те, як структурувати форму HTMLі як використовувати віджети нативної форми. Повірте, ви можете здивуватись, як багато всього можна зробити з одним тільки HTML! Після того, як освоїте цю інформацію, ви зможете зробити свій сайт набагато зручнішим для всіх користувачів вашого веб-сайту.
1.3.2 Якщо ваша веб-сторінка містить інформацію, яку ваш користувач має прочитати у певному порядку, ви повинні переконатися, що браузер та допоміжні технології користувача відображають її у цьому ж порядку. Не покладайтеся на CSS або клавішу пробілу, щоб візуально виконати це завдання. Переконайтеся, що інформація подається у правильному порядку, коли CSS та пробіли не форматують її. Крім того, спробуйте скористатись клавішею Tab, щоб перемістити фокус через посилання та cформувати віджети на своїй веб-сторінці. Чи переміщується фокус туди, куди повинен? Звертайте на це увагу, коли формуєте порядок у CSS Grid або Flexbox.
1.3.3 Ви не повинні думати, що ваші користувачі можуть ідентифікувати сенсорні особливості записів на веб-сторінці. Деякі користувачі не можуть сказати, де і що ви розмістили на екрані. Наприклад, замість того, щоб просити своїх користувачів натиснути «Вибрати один із варіантів ліворуч», ви можете попросити їх «Вибрати один з наших нових продуктів» і помістити посилання на цей розділ веб-сторінки.
1.4.1 Ви не повинні покладатися на колір як на єдиний спосіб передавати щось своїм користувачам. Деякі ваші користувачі не бачать, а деякі не розрізняють кольорів. Наприклад, якщо ви на вашій веб-сторінці використовуєте зелений, щоб виділити продукти, які є у наявності у вашому магазині, можете додати текст, щоб охарактеризувати ці продукти, або ж розмістити їх в окремих групах з відповідними підзаголовками.
1.4.2 Якщо ваша веб-сторінка автоматично відтворює звук більше 3 секунд, ви повинні переконатися, що ваші користувачі можуть зупинити звук або змінити його гучність. Не сподівайтесь, що користувач вимкне гучність на своєму комп’ютері, адже деякі користувачі повинні чути програму зчитування з екрана, а інші просто хотіли продовжувати щось слухати на комп’ютері, яке слухали до того, як зайти на вашу веб-сторінку.
1.4.3 Ви повинні переконатися, що текст достатньо контрастний щодо фону для того, щоб користувачі могли без проблем його прочитати. Варто прямо зараз додати у закладки Калькулятор коефіцієнта контрастності, що розробила Лія Веру. У цій програмі можна зазначити колір тексту та фоновий колір відповідно до назви або значення RGB, RGBa, HSL чи HSLa. Обов’язково переконайтеся, що:
○ звичайний текст встановлений на 24 пікселів або більше та має співвідношення мінімум 3:1;
○ напівжирний текст, встановлений на 18,75 пікселів або більше та має співвідношення як мінімум 3:1;
○ весь інший текст має співвідношення мінімум 4,5:1.
Не обов’язково проте можливо робити перевірку для елементів керування індивідуальними формами, декоративними матеріалами або логотипами.
1.4.4 Переконайтеся, що ваші користувачі можуть вдвічі збільшити розмір тексту на веб-сайті, не використовуючи допоміжну технологію, і без перешкод мати доступ до всього вмісту та функцій на сайті. Не обов’язково це все використовувати для субтитрів або зображень тексту.
1.4.5 Уникайте використання зображень тексту і просто використовуйте замість цього текст. У 1998 році Джефрі Вейн зазначив у першії зі своїх Трендових порад з дизайну: «Текст — це текст. Картинка — це картинка. Не плутайте їх.» Тепер, коли ви можете застосовувати потужні стилістичні властивості CSS, використовуйте CSS Grid для налаштування положення тексту та обирайте один із тисячі веб-шрифтів (Джефрі є співзасновником онлайн бібліотеки шрифтів Typekit, яка може вам у цьому допомогти). Використовуючи їх, вам майже ніколи не здадобляться зображення тексту. Згідно з інструкції, використовувати зображення тексту можна за умови, якщо користувачі мають змогу самі визначити шрифт, розмір, колір та фон тексту в зображенні тексту. Однак мені ніколи не доводилось зустрічати такі веб-сайти. Крім того, це все не стосується логотипів.
1.4.6 Повернімося на хвильку до контрастності кольорів. Ви можете налаштувати контраст тексту відповідно до фону, щоб зробити процес читання більш доступним для користувачів. Для цього спробуйте Калькулятор коефіцієнта контрастності Лії Веру і перевірте наступне:
○ звичайний текст, встановлений на 24 пікселів або більше, має співвідношення мінімум 4,5:1;
○ напівжирний текст, встановлений на 18,75 пікселів або більше, має співвідношення як мінімум 4,5:1;
○ весь інший текст має співвідношення мінімум 7:1.
1.4.7 Якщо ваш веб-сайт має аудіозапис, переконайтеся, що в ньому немає фонових звуків, або що ваші користувачі можуть вимкнути будь-які фонові звуки. Якщо це неможливо, бажано переконатися, що будь-які фонові звуки, які тривають довше, ніж кілька секунд, мають щонайменше в чотири рази меншу гучність, ніж основна промова спікера. Усе це не стосується звукових файлів Captchas, звукових логотипів, співу чи читання репу. (Так-так, у цих рекомендаціях згадується реп!)
1.4.8 Ви можете також переконатися, що ваші користувачі спроможні переформатувати блоки тексту на вашому веб-сайті для більш зручного читання. Для цього необхідно переконатись, що користувачі можуть:
○ вказати кольори тексту та фону, а також
○ зробити блоки тексту ширше, ніж 80 символів, і
○ вирівняти текст по лівому краю (або правому для мов з напрямком тексту справа-наліво) та
○ встановити висоту ліній до 150%, а також
○ встановити вертикальну відстань між абзацами у 1,5 рази вищою від висоти рядка тексту, а також
○ удвічі збільшити розмір тексту (без використання допоміжної технології) без необхідності прокручувати горизонтально, щоб прочитати його.
До речі, коли вказуєте колір тексту, завжди уточнюйте колір його фону. Не покладайтеся на стандартні фони!
1.4.9 Повернімося на хвильку до зображень тексту. Тут важливо переконатися, що вони використовуються лише для оформлення та логотипів.
Чи можуть користувачі управляти елементами керування та посиланнями на вашому веб-сайті?
У другій інструкції представлені критерії, які позбавлять вас від типових питань користувача: «Яким чином ця **** річ працює?»
2.1.1 Ви повинні переконатися, що користувачі спроможні виконувати всі дії вашого веб-сайту маючи лише клавіатуру, без встановлення обмеження часу для натискання клавіш. (Це не стосується малюнка чи будь-чого іншого, що вимагає вказівного пристрою, наприклад, мишки.) Знову ж таки, все це легко зробити на практиці, якщо ви використовуєте найбільш відповідний елемент HTML для кожного фрагменту інформації та для кожного елемента форми.
2.1.2 Ви повинні переконатися, що коли користувач використовує клавіатуру для фокусування на певній частині веб-сайту, він в подальшій роботі зможе перемістити фокус в якусь іншу частину веб-сторінки, без використання мишки та сенсорного екрану. Якщо ваш веб-сайт потребує складних дій під час використання функції переміщення фокусу в інше місце, повідомте про це користувачів. Ці «клавіатурні пастки» стали рідкісними, але будьте обережні з формами, які рухають фокус з одного текстового поля до іншого, за умови отримання правильної кількості символів.
2.1.3 Переконаймося, що користувачі зможуть виконувати всі дії вашого веб-сайту лише за допомогою клавіатури, без обмеження часу на натискання клавіш. Ви можете переконатися, що ваш користувач може робити абсолютно все на веб-сайті за допомогою клавіатури.
2.2.1 Іноді людям для виконання завдання на певному веб-сайті потрібно більше часу, ніж ви думаєте. Якщо будь-яка частина веб-сайту встановлює обмеження на час виконання завдання, потрібно виконати принаймні одну з таких дій:
○ дозвольте користувачам вимкнути опцію ліміту часу, перш ніж у них виникнуть з цим проблеми; або
○ дозвольте користувачам збільшувати часові обмеження щонайменше в 10 разів більше встановленого за замовчуванням часу, перш ніж в них виникнуть труднощі; або
○ попереджайте своїх користувачів про закінчення терміну дії, дайте їм принаймні 20 секунд, щоб продовжити, а також дозвольте їм збільшити цей термін щонайменше в 10 разів.
Пам’ятайте: ці вказівки є практичними. Вони дозволяють встановлювати часові обмеження для подій в режимі реального часу, таких як аукціони та продаж квитків, де збільшення або розширення часового ліміту не буде мати сенсу. Також рекомендації дозволяють збільшити максимальний ліміт часу до 20-ти годин. Редактори зійшлись на 20 годинах тому, що людина має право на сон. Тепер зрозуміло? Практичність!
2.2.2 Власний досвід показує, що цей критерій залишається найменш прийнятим, хоча деякі користувачі можуть використовувати лише веб-сайти, які йому відповідають. Якщо на вашому веб-сайті представлений один контент разом з іншим контентом, який може відволікати користувачів шляхом автоматичного переміщення, блимання, прокручування чи оновлення, обов’язково переконайтеся, що користувачі можуть таке:
○ поставити на паузу, зупинити або сховати інший контент, якщо це не є суттєвим і триває більше 5 секунд; і
○ ставити на паузу, зупиняти, приховувати або контролювати частоту іншого контенту, якщо він автоматично оновлюється.
Нічого страшного, якщо користувачі не побачать живу інформацію, наприклад, сповіщення про оновлення цін акцій або футбольні рахунки. Тут уже нічого не вдієш! Також, це не стосується анімацій, таких як індикатор виконання, які ви розміщуєте на веб-сайті, щоб усі користувачі знали, що веб-сторінка є доступною.
(Якщо це звучить складно, просто додайте кнопку паузи до всього, що може відволікати ваших користувачів.)
2.2.3 Повернімося до часових обмежень на завдання на вашому веб-сайті. Ви могли б зробити ваш веб-сайт ще простішим для використання, знявши усі часові обмеження за винятком випадків, пов’язаних із подіями в реальному часі, такими як аукціони та продажі квитків. Це означало б, що користувачу взагалі не потрібно взаємодіяти з таймером.
2.2.4 Ви могли б дозволити своїм користувачам вимкнути переривання — оновлення сервера, рекламу та інше, крім будь-якої інформації про аварійні ситуації.
2.2.5 Це, мабуть, мій найулюбленіший критерій! Після того, як користувач покинув веб-сайт, переконайтеся, що, коли він знову авторизується, зможе продовжити роботу з місця на якому зупинився, не втрачаючи жодної інформації. Зробіть це, і ви попадете у список слухняних діток цього Різдва.
2.3.1 Переконайтеся, що на веб-сайті нічого не спалахує більше трьох разів за секунду, поки не будете впевнені, що спалахи залишаються нижче порогової величини загального спалаху та червоного спалаху зокрема…
2.3.2 … або просто переконайтесь, що нічого не спалахуватиме на вашому веб-сайті більше трьох разів за секунду. Як правило, це простіше.
2.4.1 Переконайтеся, що ваші користувачі можуть пропустити будь-які блоки контенту, наприклад навігаційні меню, які повторюються на вашому веб-сайті. Принцип дії такий: використання секційних елементів HTML, як-от header, nav, main, aside, і footerдозволяє користувачам допоміжних технологій перейти безпосередньо до потрібного їм контенту та додавання посилання “Пропустити навігацію” дозволяє кожному швидше зайти на ваш основний контент.
2.4.2 Ви повинні додати заголовок, щоб описати кожну тему веб-сторінки. На вашу веб-сторінку навіть не заходитимуть без заголовку, тож зробіть його корисним.
2.4.3 Якщо користувач може фокусуватись на посиланнях та нативних фомах віджетів, ви маєте впевнитись, що вони можуть сфокусуватись на елементах в правильному порядку.
2.4.4 Ви повинні переконатися, що ваші користувачі можуть зрозуміти ціль посилання коли вони читають:
○ текст посилання; або
○ текст абзацу, елемент списку, комірку таблиці або заголовок таблиці для комірки, яка містить посилання; або
○ заголовок над посиланням.
Вам не потрібно робити це для ігор та вікторин.
2.4.5 Ви повинні надати користувачам кілька способів пошуку будь-якої веб-сторінки в межах групи веб-сторінок. Додайте пошук по сайту та карту сайту, і все, ви закінчили!
Це не стосується веб-сторінки, яка є частиною ряду дій (як-от кошик для покупок в Інтернеті та потік замовлення), або веб-сторінки, яка є результатом ряду дій (наприклад, веб-сторінка, яка підтверджує, що користувач купив те, що було у кошику для покупок).
2.4.6 Ви повинні допомогти користувачам зрозуміти ваш контент, надаючи:
○ заголовки, які описують теми контенту;
○ мітки, які описують ціль нативних віджетів на веб-сторінці.
2.4.7 Переконайтеся, що користувачі бачать елемент, на якому вони сфокусувались. Наступного разу, коли ви використовуватиме свій веб-сайт, спробуйте кілька разів натискати клавішу Tab. Чи виділяється візуально кожен елемент, якщо навести фокус на нього? Якщо це не так, загляньте в CSS, щоб побачити, чи застосували ви outline: 0; до всіх елементів — як правило, саме у цьому проблема. Використовуйте псевдоелемент :focus, щоб визначити, як повинні з’являтися елементи, коли на них перемістити фокус.
2.4.8 Ви можете допомогти користувачу зрозуміти, де розташована поточна веб-сторінка на вашому веб-сайті. Додайте «навігаційні стежки» та / або карту сайту, і ви закінчили.
2.4.9 Щоб краще зрозуміти посилання, переконайтесь, що ваші користувачі розуміють ціль, коли з ними стикаються. І знову, вам не потрібно робити це для ігор та вікторин.
2.4.10 Використовуйте заголовки, щоб організувати контентвідповідно до теми.
Чи розуміють користувачі ваш контент?
Третя інструкція містить критерії, які допоможуть користувачам уникнути питання: “Що **** це означає?”
3.1.1 Почнімо цей розділ із критерію, який займає найменше часу для виконання; ви повинні переконатися, що браузер користувача може визначити основну мову, якою написано контент вашої веб-сторінки. Для веб-сторінки, яка містить переважно контент англійською мовою, використовуйте <html lang = “en”>.
3.1.2 Ви маєте вказувати, якщо на вашій веб-сторінці з’являється контент іншою мовою, як наприклад: <q>I wish you a <span lang=”fr”>Joyeux No?l</span>.</q>. Але це не потрібно робити для власних імен, технічних термінів або слів, до яких ви не можете визначити мову. Ви також не повинні вказувати тег для слів іншої мови, які вже, на думку людей, стали частиною їхньої мови; наприклад, <q>Come to our Christmas rendezvous!</ q>все ОK
3.1.3 Переконайтеся, що ваші користувачі можуть з’ясувати значення будь-яких незвичайних слів або фраз, включаючи ідіоми, такі як «stocking filler» чи «Bah! Humbug!” і жаргони, як “VoiceOver” і “TalkBack”. Надайте глосарій або посилання на словник.
3.1.4 Переконайтеся, що ваші користувачі можуть з’ясувати значення будь-якої абревіатури. Наприклад, VoiceOver вимовляє «Xmas» як «Smas» замість «Christmas». Використання елементу abbr та посилання на глосарій може допомогти. (Цікаво, VoiceOver вимовляє «abbr» як «abbreviation»!)
3.1.5 Для того, щоб читати ваш контент (окрім власних імен та назв), чи потрібно вашим користувачам читати краще, ніж звичайні освічені дев’ятирічні діти? Якщо так, то ви могли б надати версію, яка не вимагає спеціального рівня навиків читання, або ви можете надати зображення, відео або аудіо-файли, щоб пояснити ваш контент. (Ви не повинні додавати підписи чи аудіоопис до цих відео.)
3.1.6 Переконайтеся, що ваші користувачі матимуть доступ до вимови будь-якого слова у вашому контенті, якщо значення цього слова залежить від його вимови. Наприклад, слово “close”(закрити) може мати одне з двох значень, залежно від вимови, у такій фразі, як «Ready for Christmas?» Close now!» воно означатиме «Готові до Різдва? Вже зовсім скоро»
3.2.1 Деяким користувачам потрібно перемістити фокус на елементи, щоб отримати доступ до інформації про них. Переконайтесь, чи переміщення фокуса на елемент не викликає серйозних змін, наприклад, відкриття нового вікна, фокусування на іншому елементі або подання форми.
3.2.2 Користувачам легше використовувати веб-сторінки, коли елементи керування роблять те, що вони повинні робити. Якщо ви не попередили своїх користувачів, то переконайтеся, чи зміна значення елемента керування наприклад, елемент текстове поле, прапорець або випадаючий список не викликає серйозних змін, як от відкриття нового вікна, фокусування на іншому елементі або подання форми.
3.2.3 Щоб допомогти вашим користувачам знаходити потрібний їм контент на кожній веб-сторінці, вам слід розмістити елементи навігації в одному і тому ж місці на кожній веб-сторінці. (Але це не застосовується в тих ситуаціях, коли користувач змінює свої налаштування або використовує допоміжні технології, щоб змінити зовнішній вигляд вашого контенту.)
3.2.4 Коли ряд веб-сторінок містять елементи, які виконують одну і ту ж функцію на різних веб-сторінках, вам слід постійно вказувати ці елементи.. Наприклад, не використовуйте слово “Пошук” для вікна пошуку на одній веб-сторінці та “Знайти” для вікна пошуку на іншій веб-сторінці в межах одного набору веб-сторінок.
3.2.5 Повернімося до серйозніших змін, таких, як відкриття нового вікна, переміщення фокусу на інший елемент або заповнення форми. Переконайтеся, що такі речі трапляються лише тоді, коли користувачі роблять це самостійно, або за умови, що ви спершу сповістили їх про це. Наприклад, ви можете додати кнопку для оновлення певного контенту, щоб уникнути автоматичного оновлення. Крім того, якщо посилання відкривається в новому вікні, ви можете додати слова”відкривається в новому вікні” до тексту посилання.
3.3.1 Користувачі роблять помилки під час заповнення форм. Ваш веб-сайт повинен вказувати користувачеві на кожну помилку а також описувати цю помилку у текстовій формі, щоб користувач міг її виправити. Одним із способів, який допоможе чітко вказати користувачеві на помилку, є застосування атрибуту aria-invalid true в елементі, який містить помилку. Це гарантуватиме, що користувачі, які працюють з допоміжними технологіями будуть попереджені про помилку. Звичайно, ви можете використовувати [aria-invalid = “true”] селектор атрибутів у вашому CSS, який таким чином візуально виділить будь-які подібні помилки. Крім того, зверніть увагу на те, як певні атрибутиinput елемент такі як вимагаються,тип, ісписокможуть допомогти запобігти помилок та виділити їх.
3.3.2 Вам слід також включати мітки або інструкції(і, можливо, приклади) у формах вашого веб-сайту, щоб допомогти користувачам уникати помилок.
3.3.3 Коли користувач робить помилку під час заповнення форми, ваша веб-сторінка повинна запропонувати способи виправити її, якщо це можливо. Це не стосується тих випадків, коли запропоновані варіанти можуть вплинути на безпеку контенту.
3.3.4 Кожного разу, коли ваш користувач надає інформацію, яка:
○ призводить до юридичних чи фінансових наслідків; або
○ впливає на їхню інформацію, що раніше була збережена на вашому веб-сайті; або
○ є частиною тесту
… ви повинні переконатися, що користувачі зможуть:
○ скасувати її; або
○ виправити будь-які помилки, після того як ваша веб-сторінка перевірить інформацію; або
○ переглянути, підтвердити та виправити інформацію, перш ніж остаточно подати її.
3.3.5 Ви можете допомогти вашим користувачам запобігти помилок, надаючи очевидну та конкретну допомогу, наприклад, забезпечити їх зразком, анімацією, перевіркою орфографії або додатковими вказівками.
3.3.6 Кожного разу, коли ваш користувач подає будь-яку інформацію, вам слід переконатися, що він зможе:
○ скасувати її; або
○ виправити будь-які помилки, після того як ваша веб-сторінка перевірить інформацію; або
○ переглянути, підтвердити та виправити інформацію, перш ніж остаточно подати її.
А ваш веб-сайт достатньо надійний, щоб працювати у браузерах ваших клієнтів чи з різними допоміжними технологіями, якими вони користуються?
Четверта та остаточна інструкція містить критерії, які допоможуть користувачам уникнути питання: “Чому це **** не працює на моєму пристрої?”
4.1.1 Вам слід впевнитись, що ваш веб-сайт працює добре з сучасними та майбутніми браузерами, а також з допоміжними технологіями. Зробіть так, щоб ваш веб-сайт відповідав веб-стандартам замість того, щоб покладатися на можливості сучасних популярних пристроїв та браузерів. Веб-розробники не могли й подумати, що їх користувачі згадають про Wii U браузер 5-літньої давності, — тож хто знає, які браузери та допоміжні технології наші користувачі згадають через п’ять років? Остерігайтесь хакерів і використовуйте W3C Markup Validation Service, щоб переконатися, що ваш HTML не містить помилок.
4.1.2 Якщо ви розробляєте свої власні компоненти інтерфейсу користувача, ви повинні зробити ім’я, роль, стан, властивості та значення доступними для браузерів вашого користувача та допоміжних технологій. Таким чином, це зробить їх майже такими ж доступними, як і стандартні елементи HTML такі, як посилання, кнопки та прапорці.
«.. і куріпка на грушевій гілці!»
… як в тій довгій різдвяній пісні. У цій статті ми багато чого розглянули, оскільки у ваших користувачів різні рівні можливостей. Сподіваємося, що уся ця інформація дозволить вам легше зрозуміти Інструкції щодо забезпечення доступності веб-контенту 2.0. Сподіваємось, ви зрозуміли які ситуації можуть виникнути у користувачів під час роботи на вашому веб-сайті і тепер знаєте, як їх вирішити.
Щоб почати застосовувати розглянуту інформацію, ви можете ознайомитися з поглядами Сари Хортон і Уїтні Кесенбері, що працюють в сфері достуного UX (користувацького досвіду). Обговоріть ці особистості, спробуйте потрапити в їхні голови і подумайте, які аспекти вашого веб-сайту можуть спричинити для них проблеми. Подумайте, чи можете ви застосувати те, що ми розглянули сьогодні, для того, щоб допомогти користувачам, на кшталт Сари та Уїтні, зробити те, що їм потрібно на вашому веб-сайті.
Як зрозуміти, коли саме ваш веб-сайт є повністю доступним для всіх
LOL! Ніколи не буде такого моменту, коли ваш сайт стане абсолютно доступним для кожного. І не прагніть цього. Натомість, намагайтеся регулярно перевіряти та робити ваш веб-сайт доступнішим.
Інструкції щодо забезпечення доступності веб-контенту (WCAG) 2.1
W3C сподівається випустити Інструкції щодо забезпечення доступності веб-контенту (WCAG) 2.1 як “рекомендацію” (W3C називає це тим, що нам слід почати використовувати) до середини наступного року. Десять років можуть здатися досить тривалим часом для переходу від версії 2.0 до версії 2.1, але задумайтесь над масштабом завдання: редактори повинні оновлювати інструкції для того, щоб охопити всі нові способи, за допомогою яких люди взаємодіють з новими технологіями, одночасно зберігаючи попередні інструкції. Слідкуйте за версією 2.1!
І ви увійдете в історію
І ще одне: я зустрів неймовірну кількість веб-дизайнерів і розробників, які дуже багато працюють над тим, щоб зробити свої веб-сайти доступнішими, навіть не повідомляючи про це своїх користувачів. Деякі ваші потенційні клієнти, можливо, раніше вже намагались, але не змогли користуватись вашим веб-сайтом. Швидше за все, вони навіть не намагатимуться скористатись ним знову, якщо ви не повідомите їх про позитивні зміни. Ввівши назву вашого веб-сайту поряд з фразами “допоміжна технологія”, “не працює” або “#fail” у швидкому пошуку у Twitter, дозволить вам знайти розчарованих користувачів і таким чином, ви зможете повідомити їх, що зробили свій веб-сайт доступнішим. Почніть покращувати роботу ваших веб-сайтів, і, будь ласка, повідомте про це всіх.
