Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

13

Від автора: Мобільність змінила докорінно метод нашого користування Вебом. Особливо це стосується користувачів-інвалідів, яким мобільні пристрої відкривають двері до зовсім нового взаємодії.

І вони з задоволенням користуються цією можливістю. Опитування в липні 2013р дорослих користувачів з інвалідністю, проведене Дослідницьким інженерним центром бездротовий реабілітації (Wireless Rehabilitation Engineering Research Center), виявив, що 91% людей з фізичними вадами користуються «бездротовим пристроєм, таких як мобільний телефон або планшет». Серед таких користувачів саме звична справа – використання скринридеров навіть на мобільних пристроях.

Дослідження серед 1782 користувачів екранних читців, проведене Web Accessibility in Mind (WebAIM) в 2012р., показало, що 71,8% з них користувалися ними на своїх мобільних пристроях. І ми говоримо не про якомусь маленькому кількості людей. За підсумками перепису в США в 2010р. виявлено, що майже кожен п’ятий – людина з фізичними вадами!

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Результати дослідження WebAIM з використання екранних читців (джерело: WebAIM)

Незважаючи на це, на мобільних веб-сайтах забуті багато кращі практики доступності. Розробники застосовують складні рішення, такі як адаптивний дизайн і адаптивні зображення, забуваючи при цьому про таких основних техніках, як заміна зображень. Тому користувачам-інвалідам, яким досить складно користуватися настільним комп’ютером, часто представляються інтерфейси, які в кращому випадку розчаровують, а в гіршому ними просто неможливо користуватися.

Хоча проблема доступності здається досить складною, дотримання кращим практикам значно сприяє побудові доступних сайтів і додатків. У цій статті ми обговоримо деякі практичні заходи, спрямовані на вирішення найбільш поширених проблем, з якими стикаються користувачі-інваліди. Особливо розглянемо, як важливо наступне:

Переконатися, що все працює з клавіатури,

Створити форми семантичним шляхом,

Забезпечити високу контрастність,

Гарантувати, що екранні читці розуміють команди елементів управління,

Протестувати свій веб-сайт на цій скринридере.

Ви побачите, що слідування цим практикам призведе до поліпшення взаємодії всіх користувачів, не тільки володіють фізичним вадами. Давайте почнемо з того предмета апаратного забезпечення, який рідко розглядається в мобільному просторі – клавіатури.

1. Переконаємося, що все працює з клавіатури

Хоча клавіатуру зазвичай ми асоціюємо з традиційними настільними комп’ютерами і ноутбуками, ситуація вже не так проста. Вбудована в обкладинку клавіатура є в планшеті Microsoft Surface, клавіатури Bluetooth зроблені для бездоганної роботи в iOS і Android, а деякі клавіатури навіть можна складати при подорожі.

Навігація з клавіатури по мобільних веб-сайтів стала дуже важливою ще й тому, що багато сайтів побудовано адаптивно. З-за того, що такі веб-сайти поставляють на всі пристрої однакову розмітку, клавіатура зобов’язана функціонувати правильно, навіть якщо переважна більшість користувачів використовують сенсорний екран.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Підтримка клавіатури важлива навіть на мобільних пристроях.

Відкладіть в сторону миша і спробуйте відвідати свій веб-сайт. Чи можна виконати всі завдання лише з клавіатури? Якщо ні, то і ваші користувачі цього не зможуть. Дві основні проблеми перешкоджають навігації по Мережі з клавіатури. Давайте обговоримо кожну з них.

ЗАСТОСУВАННЯ НЕПРАВИЛЬНОГО ЕЛЕМЕНТА ДЛЯ ЗАВДАННЯ

Веб-браузери дійсно добре можуть змусити працювати автоматично навігацію з клавіатури, якщо ви користуєтеся семантично відповідними елементами. Зокрема, за замовчуванням у фокус потрапляють наступні елементи: button, a (з атрибутом href), input select та textarea. З цими елементами навігація з клавіатури працює без всяких додаткових зусиль. Однак розробникам часто не вдається належним чином використати ці елементи, а конкретно button і a.

Кнопки потрібно застосовувати для елементів управління, які виконують дії, тоді як посилання слід використовувати для тих елементів управління, з допомогою яких користувачі переходять до інших документів. Однак розробники часто неправильно застосовують родові елементи, такі як span й div, для виконують ці дії елементів управління. Розгляньте цільову сторінку iPhone від Fidelity, банківської організації.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Ці кнопки знаходяться на цільовій сторінці Fidelity для iPhone чи ні?

Два елементи керування цієї сторінки, безсумнівно, виглядають як кнопки, але в дійсності генеруються наступній розміткою.

Download the Fidelity App
No thanks

З цієї причини клавіатури не стануть підтримувати навігацію цих елементів управління. А могли б, якби ті були розмічені як справжні елементи button.

Download the Fidelity App
No thanks

Хоча найчастіше таке трапляється з кнопками, посилання теж нерідко використовуються неправильно. Розглянемо спливаюче вікно, яке з’являється при відвідуванні домашньої сторінки American Express на ipad е:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

American Express показує користувачам iPad на своїй домашній сторінці ось таке виринаюче вікно.

Незважаючи на те, що посилання «Click here to download the American Express app» зовсім звичайна, American Express застосовує наступний HTML:

Click here to download the American Express® App

Посилання зроблена в JavaScript’е з допомогою обробника клацання, який змінює window.location. Через використання div клавіатури не здатні дістатися до елемента керування, але могли б, якби застосовувався елемент a.

Click here to download the American Express® App

(Зазначимо, що кнопка «закрити» на спливаючому вікні American Express’а також є div, так що користувачі з клавіатури не в силах ні виконати дію на спливаючому вікні, ні закрити його.)

Також American Express міг би скористатися схваленим Apple методом інформування користувачів про наявність додатка за допомогою meta-тега apple itunes app.

Взагалі-то браузери автоматично гарантують семантичним елементів доступ з клавіатури. А що, якщо ви застосуєте більш складні елементи, ніж прості button або a?

НАПИСАННЯ ВЛАСНИХ СКЛАДНИХ ВІДЖЕТІВ

Як веб-розробники, для складного взаємодії у своїх інтерфейсах ми часто користуємося віджетами. Іноді це робиться для того, щоб обійти недоліки платформи (наприклад, щоб вбудувати більш користувальницький елемент select), а іноді для того, щоб вбудувати потужний елемент користувацького інтерфейсу (наприклад, сітку, закладку або графік). Давайте розглянемо заміщення елемента select. На перший погляд здається, що такий віджет легко написати:

Створіть div.

Створіть ul з елементом li для кожної заміни option.

При клацанні по div відкрийте меню.

Якщо клацнути по елементу li знову переведіть значення у div.

Легко. Однак розгляньте всі елементи управління клавіатури, які є в елементі select:

Клавіша пробілу відкриває меню опцій.

Стрілки вгору-вниз відкривають меню і циклічно переміщують по опціях.

Кнопки page up і page-down циклічно переміщають по цілим сторінок опцій у довгих списках.

Клавіша Escape закриває меню.

Друк значень запускає опції автозаповнення при знаходженні елемента в фокусі.

Несподівано скопіювати «рідний» елемент select стало значно складніше. Не кажучи вже про те, що нам потрібно гарантувати доступ екранним читцям до опцій і можливість прочитати їх в потрібний час.

Щоб ці складні взаємодії стали можливі, є спеціальний набір атрибутів HTML, який забезпечує скринридеры необхідним контекстом. Вони відомі як Accessible Rich Internet Applications, або атрибути ARIA.

Основний атрибут ARIA, role, повідомляє браузерам і допоміжних пристроїв загальний тип об’єкта — наприклад, діалогове вікно, слайдер або попередження. Звідси застосування деякої кількості атрибутів aria-* для більш детального інформування про стан елемента. Нижче наведено шаблон розробки доступного заміщення select.

Екранні читці користуються такими атрибутами ARIA для того, щоб допомогти користувачам з клавіатури оперувати цими елементами управління. Наприклад, так як у span з цього прикладу role має значення «combobox», VoiceOver в OS X читає «Зараз ви знаходитесь в комбінованому вікні, впишіть текст або натисніть Control-Option-Space для відображення списку меню. VoiceOver знає про доступне переліку альтернатив, тому що у span є атрибут aria-owns, встановлений на «menu» — id містить опції ul’а.

Але, як видно, існує величезна безліч атрибутів ARIA, з якими доводиться рахуватися; так що з-за складності розуміння цього моменту багато розробники для отримання таких елементів керування частіше вдаються до застосування бібліотеки користувальницьких інтерфейсів JavaScript, а не роблять їх самі. Багато великі бібліотеки гарантують автоматичну доступність таких засобів управління шляхом застосування відповідних ролей ARIA і клавіш швидкого виклику клавіатури. Наприклад, елемент інтерфейсу jQuery selectmenu і елемент інтерфейсу Kendo DropDownList – обидва генерують доступні заміщення select.

На цьому закінчимо розглядати підтримку навігації з клавіатури. Хоча цей набір принципів, звичайно, не є всеосяжним, він зобов’язаний допомогти вам змусити працювати належним чином найважливіші частини вашого веб-сайту. Для отримання більш вичерпного списку доступних з клавіатури можливостей прочитайте повний посібник W3C. Далі ми розглянемо ще одну часто забываемую кращу практику: побудова семантичних форм.

2. Семантична розмітка форм

Поряд з поширенням односторінкових додатків — особливо мобільних — все меншу кількість веб-сайтів використовує «рідне» подання форм HTML. Замість цього дані надсилаються на сервер з допомогою ініційованих JavaScript’ом XMLHttpRequest’ів. Хоча по суті в цьому немає нічого поганого, але залишається важливим використання тієї ж семантичної розмітки, якою ви користувалися, якщо б доводилося відправляти дані з допомогою споконвічних форм HTML.

У більшості екранних читців є цілі режими, присвячені взаємодії форм, для чого потрібна правильна розмітка форм. Розглянемо цю форму входу у систему:

Username:
Password:
Submit
document.querySelector( «button» )
.addEventListener. ( «click», function() {
// Пошліть запит AJAX для входу користувача
});

Хоча вона дає користувачеві можливість увійти, у неї є деякі проблеми, що ускладнюють вхід для дієздатних користувачів і роблять його неможливим для користувачів з обмеженими можливостями. Давайте розглянемо ці проблеми по черзі.

АСОЦІЮВАННЯ МІТОК З INPUT-АМИ

Більшості скринридеров потрібно, щоб елементи форми — input select та textarea — асоціювалися з описують їх мітками label. У кожного елемента label повинен бути атрибут for, відповідний відповідного атрибуту елемента форми id, як показано тут:

Field:

Наша форма входу сама по собі не володіє такою асоціацією, і це змусило б допоміжні пристрої зробити помилку. Нижче показаний введення імені користувача input, яким ми зараз користуємося. Зверніть увагу, що в ньому немає мітки label.

Username:

Коли введення імені користувача input потрапляє у фокус, екранний читець NVDA читає просто «Редагувати текст. Порожнє поле» («Edit text, blank»). На жаль, досить поширена ситуація. Приміром, у Amazon є полегшений веб-сайт, amazon.com/access, оптимізований до скринридерам і мобільних пристроїв».

Веб-сайт, відповідно, простий, з єдиним полем пошуку і коротким списком посилань. Іронія ситуації полягає в тому, що незважаючи на перенаправлення користувачів екранних читців на цю сторінку, Amazon не додав до введення пошуку input мітку label; таким чином, багато користувачів скринридеров поняття не мають про те, що для пошуку можна скористатися введенням input.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Доступний веб-сайт Amazon’а не асоціює мітку «Пошук» («Search») з текстовим полем.

(Замітка: Як у браузерів, у скринридеров варіюється підтримка шаблонів розмітки. У вищенаведеному прикладі VoiceOver читає текст «Пошук» («Search»), а NVDA – ні. Пізніше в цій статті ми обговоримо тестування сумісності.)

Можна легко вирішити цю проблему в нашому зразку форми з елементами label:

Username:
Password:
Submit
document.querySelector( «button» )
.addEventListener. ( «click», function() {
// Send AJAX request to log in user
});

Тепер всі екранні читці стануть асоціювати кожен елемент форми з описує його міткою. Ця практика вигода не тільки для користувачів допоміжних пристроїв. Будь-який браузер досить розумний, щоб перетворити клацання по елементу label в асоційовані елементи input select або textarea.

У вас виникали коли-небудь проблеми при клацанні по чекбоксу розміром 10 × 10 пікселів, де потрібно прийняти умови користування сервісом? На веб-сайтах з семантичної розміткою замість цього можна клацнути по мітці чекбокса набагато більшого розміру. На мобільних пристроях великими пальцями можна доторкнутися до збільшеного об’єкта:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Клацанням по мітці наводиться фокус на відповідний елемент управління.

Так вирішується одна з проблем форми входу. Але потрібно обговорити ще одне питання.

УПРАВЛІННЯ КЛАВІШЕЮ «ENTER» («ENTER»)

Ви помічали, що деякі форми входу в Вебі можна відправити, натиснувши на кнопку «Enter» («Enter»), в текстовому полі, а деякі не можна? Що змушує кнопку «Enter» працювати на відправку?

Відправка форми за допомогою кнопки «Enter» («Enter») відома як подразумеваемая відправлення і підтримується всіма браузерами — навіть мобільними. Для роботи неявної відправки потрібно дотримати всього дві вимоги.

Всі елементи input повинні бути в form.

Якщо форма містить більш одного елемента input select або textarea у form повинна бути кнопка «Надіслати» («Submit»).

У нашій форми-зразка вже є кнопка відправки «Submit» (за замовчуванням вид type кнопки button — це submit). Отже, нам потрібно всього лише додати форму form.

Username:
Password:
Submit
document.querySelector( «button» )
.addEventListener. ( «click», function( event ) {
// Prevent the default submission form
event.preventDefault();
// Пошліть запит AJAX
});

Вам варто запам’ятати кілька моментів:

При неявної відправки браузер виконує клацання по кнопці «Відправити» («Submit») form’и. Отже, для виконання дії відправки можна спокійно слухати події клацання click кнопки «Submit». Як альтернативу, можна прослуховувати подія submit елемента form.

Хоча JavaScript перехопить відправку форми, все одно недвозначно заявляється method=»POST». У разі відмови JavaScript (за неподдерживающих браузерів, проблем з мережею і т. д.) нам не потрібно, щоб браузер відправив запит GET, який помістить надане користувачем ім’я і пароль у рядок запиту.

Можливість неявної відправки економить на клацанні мобільних користувачів. На зображенні нижче показані два елемента input, один елемент form, а другий – ні. Зауважте, що в прикладі з form можна робити відправку під час знаходження вводу input у фокусі — не потрібно додаткових торкань і пошуку кнопки відправки «Submit».

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Припущене відправка форми працює тільки з дійсними елементами форми.

На цьому ми завершуємо розглядати побудову доступних форм. Що стосується доступу з клавіатури, то ці принципи далекі від вичерпних, але вирішують деякі найбільш часто виникають проблеми з формами. Для одержання повного списку найкращих практик прочитайте керівництва по збору даних вводу від користувачів W3C.

Далі ми розглянемо проблему, з якою не раз стикалося більшість користувачів смартфонів: низька контрастність.

3. Забезпечте потужну контрастність

Якщо ви коли-небудь користувалися своїм телефоном на вулиці, особливо при сильному сонячному світлі, то дуже намагалися розглянути, що ж відбувається на екрані. Це дуже схоже на те, що постійно відчувають користувачі з порушеннями зору.

При створенні дизайну будь-якого веб-сайту пам’ятайте про те, що велика частина користувачів буде розглядати його з дому з сучасного монітора на зразок вашої. Особливо це важливо для мобільних сайтів з-за безлічі видів середовища, у якій відвідувачі користуються своїм телефоном.

Як адаптувати свій веб-сайт до різного оточення? На відміну від безлічі суб’єктивних аспектів, ступінь контрастності можна розрахувати, і у W3C є безліч керівництв з цього питання в «Принципах доступності веб-контенту» (Web Content Accessibility Guidelines) (WCAG) – серії рекомендацій щодо створення більш доступного Інтернету для людей з фізичними вадами.

Керівництво WCAG визначає три рівня відповідності: Рівень A, Рівень AA і Рівень AAA. Згідно специфікації, щоб веб-сайт відповідав, вимоги Рівня A повинні виконуватися, вимогам Рівня AA слід відповідати, а вимоги Рівня AAA можуть виконуватися.

Ступінь контрастності Рівня A встановлена на 3:1; Рівня AA – на 4.5:1, а Рівня AAA – на 7:1. В якості контрольної точки специфікацією рекомендована ступінь контрастності 4.5:1 для користувачів із зором 20/40, яке зазвичай буває у літніх людей.

Це означає, що слід зробити рівень контрастності щонайменше 3:1, а в ідеалі – 4.5:1 або більше. Але як точно це порахувати?

ПІДРАХУНОК СТУПЕНЯ КОНТРАСТНОСТІ

До частиною, Леа Віру (Lea Verou) створила інструмент простого підрахунку ступеня контрастності.

Їм легко користуватися. Введіть фоновий колір і колір тексту, а інструмент підрахує контрастність:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Інструмент Леа Віру визначає ступінь контрастності тексту і його фону.

Потрібно запам’ятати, що:

Інструмент підтримує будь-який колір CSS, який підтримує браузер. Тому приймаються будь-які ключові слова (наприклад, white), HEX, RGB, RGBa, HSL і # hsla-color hsla.

По мірі введення валідних значень інструмент генерує унікальні ДО и. Це властивість ідеально для розробника: можна заявити дизайнеру, що сірий колір на світло-сірому фоні – це погана ідея.

Хоча висока контрастність – це звичайний здоровий глузд, на ділі знайдеться достатньо поганого контрасту навіть у важливих веб-сайтів. Нижній колонтитул сайту Square’s не відповідає Рівню A:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

У нижнього колонтитула Square дуже низька контрастність.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Нижній колонтитул Square не відповідає Рівню A.

Звинуватити можна навіть Facebook. Посилання в його верхньому колонтитулі на настільному комп’ютері теж не відповідають Рівню A:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Текст заголовка facebook’а має дуже низьку контрастність.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Верхній колонтитул facebook’а не відповідає Рівню A.

Таким чином, призначивши свого тексту ступінь контрастності щонайменше 3:1 (а в ідеалі – 4.5:1 або вище), ви зробите його доступним для слабозорих, а також зробите більш читабельним для інших користувачів. Інструмент Леа Віру ідеально підходить для підрахунку ступенів контрастності та обговорення результатів з іншими людьми.

Щоб дізнатися більше про ступені відповідності, зверніть увагу на форматований перелік критеріїв WCAG для кожного рівня.

Далі ми повернемося до обговорення екранних читців — особливо до того, як переконатися, що вони розуміють ваші веб-сайти.

4. Переконайтеся, що скринридеры розуміють те, що роблять ваші елементи управління

До цього ми розглядали дослідження WebAIM, яке показує, що 71,8% користувачів екранних читців також застосовують їх на мобільних пристроях. У тому ж дослідженні користувачів опитали про найпоширеніші проблеми, з якими ті стикаються в Мережі. Третьої і четвертої проблемами в цьому списку йдуть:

Безглузді посилання і кнопки,

Зображення з відсутнім або неправильним описом (текст alt).

(На першому і другому місці в цьому списку – Flash і CAPTCHA. Будь ласка, не застосовуйте їх.)

У наступному фрагменті коду показані обидві ці проблеми.

button {
background: url(‘search.png’) no-repeat;
}
Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Кнопка button для користувача з скринридером не має ніякого сенсу – не буде прочитано нічого. З img екранні читці прочитають буквально content-1/images/ABC123.jpg, що не надто допоможе користувачеві.

Методи виправлення цих проблем дуже добре задокументовані. Для вирішення проблеми з button можна додати в свій елемент керування текст і застосувати одну з багатьох технік заміщення зображення для того, щоб цей текст не був видний користувачам з нормальним зором. У наведеному нижче фрагменті коду показана одна з таких технік: застосування правила великого негативного відступу тексту text-indent.

button {
background: url(‘search.png’) no-repeat;
text-indent: -9999px;
}
Search

Рішення проблеми img дуже просте – додавання атрибута alt, що описує зображення.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Незважаючи на те, що ці проблеми широко відомі і їх можна легко вирішити, вони все ще часто зустрічаються. Як доказ давайте розглянемо декілька реально існуючих веб-сайтів. Я живу у великому американському штаті Мічиган, відомому своєю «великою трійкою» автопрому: Ford, GM і Chrysler. Природно, у цих великих компаній є доступні мобільні веб-сайти, де вимоги кращих практик не порушуються … правда?

ПРАКТИЧНИЙ ВИПАДОК: «ВЕЛИКА ТРІЙКА» АВТОПРОМИСЛОВЦІВ

Почнемо з GM. Її мобільний веб-сайт показаний нижче. Текст в лапках показує те, що насправді читає VoiceOver в OS X при виборі відповідного елемента.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

У мобільного сайту GM проблеми з доступністю. В лапках показано, що насправді читає VoiceOver в OS X.

Як бачите, веб-сайт GM сильно залежить від великих зображень, що служать в якості посилань на додатковий контент. На жаль, GM не забезпечує ці посилання текстом, тому у скринридеров обмежена інформація, яку можна відшукати в цих зображеннях.

GM дійсно забезпечує ці зображення атрибутами alt, але, що дивно, вони встановлені на імена файлів зображень. Наприклад, ось джерело зображення cadillac’у:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Таким чином, при виборі цього зображення VoiceOver читає буквально «Homepagebrand underscore Cadillac underscore two nine zero x one seven zero dot jpeg».

Значить, GM з тріском провалив наше тестування. Далі, давайте випробуємо Ford, чий мобільний веб-сайт показаний нижче.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Мобільний веб-сайт ford’а також страждає від проблем з доступністю. В лапках написано, що читає VoiceOver в OS X.

Деякі проблеми ford’а збігаються з хворими точками GM. Його банер – це посилання без тексту та зображення без атрибуту alt, тому VoiceOver читає «index.html image».

Нижче у ford’а показаний химерний 3-D куб з зображеннями автомобілів. На жаль, він виконаний за допомогою безлічі div ів, з background-image і JavaScript’ом, який при натисканні вводить користувача в бік. Тому скринридеры абсолютно не розуміють, що відбувається в цьому великому сегменті екрану. Якщо доторкнутися до цього займає половину екрану «куба», VoiceOver в iOS видає лише писк.

І нарешті, «посилання» внизу екрану насправді посиланнями не є; це div и з атрибутами onclick, що змінюють window.location для користувача навігації. Загалом, ці елементи управління недоступні з клавіатури і тільки збивають екранних читців з пантелику.

Ви подумали, що гірше бути вже не може, але давайте розглянемо останнього з «великої трійки» автопромисловців, Chrysler. Його мобільний веб-сайт показаний нижче.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Мобільний сайт Chrysler’а також страждає від проблем доступності. В лапках показано, що читає VoiceOver в OS X.

Бачите, на сайті Chrysler’а майже нічого не забезпечує скринридеры контентом. Так нам ще раз нагадують про важливість значущих атрибутів alt. Один з атрибутів alt, який дійсно є — «This Is the Hero Carousal» — не менш безпорадний. Навіть гірше – всі зображення каруселі мають однакові атрибути alt; так що користувачі скринридеров не зметикують, що представлені різні посилання. І ще нова образа – слово «carousel» неправильно написано («carousal») і невірно вимовляється.

Карусель зображень займає більше половини простору на екрані iphone’а і напевно є самим активно використовуваним елементом управління. Атрибут alt повинен говорити користувачеві хоч щось про видимому їм зображенні, а також про те, куди він потрапить після клацання по посиланню.

Наприклад:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Тут користувачам екранних читців зрозуміло, для чого служить посилання і що вони побачать, якщо оберуть її.

На жаль, подібні приклади дуже часто зустрічаються. Хоча є безліч відмінно задокументованих кращих практик доступності, про них-то й справа забувають навіть на великих веб-сайтах і особливо в їх мобільних версіях.

Чому?

Одна з причин полягає в тому, що наслідки порушення таких практик неочевидні. Для зрячих користувачів сенсорних екранів всі ці веб-сайти нормально працюють. По-друге, не існує хорошого способу автоматизувати доступність веб-сайту. Валідатор W3C попередить вас про відсутність атрибутів alt, але не зможе протестувати більш складні сценарії, такі як кнопки, іконки і відсутність функціональності клавіатури. Він також не зможе перевірити, значимі чи атрибути alt насправді.

Отже, ми повинні довіряти веб-розробникам у тому, що вони вивчили і пам’ятають про необхідність застосування методів доступності, у яких відсутні явні переваги. Як видно з цього практичного прикладу, часто вони цього не роблять.

Але не все так сумно. Нами доведено, що кілька легких застосування кращих практик здатні радикально поліпшити доступність сайту і відкрити його для нової, дивно великій аудиторії. Такі доступні сайти надають набагато краще враження на всіх користувачів.

Але якщо валідатор W3C здатний вловити проблеми з доступністю, то як впевнитися, що ми вірно застосовуємо ці кращі практики? Як виявляється, кращий спосіб тестування доступності – а також чудовий спосіб отримати відомості про те, як користувачі-інваліди взаємодіють з ним — це застосування екранного читця.

5. Випробуйте свій веб-сайт на цій екранному читці

У більшості веб-розробників є маса браузерів і пристроїв для тестування веб-сайтів, проте мало хто знає, як користуватися скринридером. На жаль, це призвело до того, що багато розробники відносяться до посібникам з доступності як у деякому роді до чаклунство вуду. Думка про те, що краще всього підходить користувачам з фізичними вадами, вони складають без реального тестування своїх теорій.

Це сором і ганьба, тому що кращий спосіб зрозуміти, доступний ваш сайт – це випробувати його так, як це зробив би користувач-інвалід. Особисто я не розумію, чому скринридеры покриті такою завісою таємниці; насправді ними досить легко користуватися.

Якщо у вас Mac, для активації VoiceOver напишіть Command + F5 . Пройдіться по сторінці за допомогою клавіші Tab і подивіться, що тут читаемо. Також можна натиснути Ctrl + Option плюс ліва або права кнопка-стрілка для того, щоб дістатися до вмісту, відсутнього в порядку переходу клавішу табуляції. Є і більш просунуті види управління, але отримати загальне уявлення можна і за допомогою цих базових елементів.

Якщо у вас Windows, можна завантажити та користуватися безкоштовним NVDA. Найпопулярніший платний читець – це JAWS; у нього можна випробувати безкоштовно режим демонстрації.

Мобільні пристрої трішки відрізняються з-за того, що у них відсутня клавіатура за замовчуванням. Отже, застосування екранного читця змусить вас продумати взаємодію зі своїм пристроєм. Давайте з’ясуємо це, розглянувши скринридеры, вбудовані в iOS та Android —відповідно VoiceOver і TalkBack.

ЗАСТОСУВАННЯ VOICEOVER В IOS

VoiceOver – це основний помічник доступності в iOS для будь-яких додатків, а не тільки для Мережі. Так як більшість користувачів не застосовують, за замовчуванням VoiceOver деактивовано. Щоб його включити, перейдіть до Установки → General → Accessibility → VoiceOver. Ви побачите такий екран:

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Екран установок VoiceOver в iOS

Попереджаю — будучи включеним одного разу, VoiceOver докорінно змінить спосіб взаємодії з телефоном. Отже, ви зобов’язані вивчити основи; інакше не зможете відключити VoiceOver.

Коли VoiceOver включений, одне торкання екрана вибере елемент, але не активує його. Наприклад, якщо торкнутися іконки Safari, VoiceOver прочитає «Safari», але не запустить додаток. Після вибору потрібно подвійне торкання для запуску програми. Це має сенс, якщо ви в перспективі уявляєте собі того, хто не може бачити іконку. Такій людині перед активацією елемента потрібно підтвердження, що він вибрав його правильно.

Інша важлива відмінність VoiceOver’а полягає в тому, що при прокрутці вам доведеться користуватися трьома пальцями. Чому? Тому, що в режимі VoiceOver iOS слухає однопальцевые жести «змахування» у всіх чотирьох напрямках:

«Вгору» («Up») — переміститися до попереднього елементу згідно роторної установці

«Вниз» («Down») — переміститися до наступного елементу згідно роторної установці «Вправо» («Right»)
переміститися до попереднього елемента

«Вліво» («Left») — переміститися до наступного елемента

Що таке цей «ротор»? Через мить ми до нього доберемося. По-перше, для переміщення по доступним елементів спробуйте «посмахивать» вліво і вправо по екрану. Такі жести допомагають користувачам з ослабленим зором зрозуміти, що де знаходиться, без необхідності всюди торкатися екрану.

Ще цікавіше справа йде з ротором VoiceOver’а, засобом конфігурування методів навігації за елементами екрану.
Для активації ротора пообертайте двома пальцями по дисплею, неначе ви набираєте номер на дисковому телефоні. Ротор і його опції за умовчанням показано нижче.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Роторне засіб управління в VoiceOver для iOS

Встановивши ротор, можна змінювати спосіб навігації по сторінці. «смахиваниями» вгору і вниз. Наприклад, якщо ротор встановлений на посилання (Links»), то рухи вгору і вниз будуть циклічно переміщати вас по посиланнях на сторінці і нічого більше. В даному випадку ротор діє як фільтр, даючи користувачеві можливість відсіяти той контент, який йому цікавий.

Ротор доводить важливість семантичної розмітки. Якщо ваші посилання в дійсності не є тегами a, то вони не здадуться в установці ротора для посилань («Links»). Якщо елементи керування формою не є справжніми елементами форми, то не будуть показані в установці ротора для елементів керування формою («Form Controls»).

Як бачите, застосування екранного читця змусить вас фундаментально змінити метод використання мобільного пристрою і отримання на ньому доступу до мережі. Спробуйте пограти з будь-якими з ваших веб-сайтів і подивіться, наскільки легко можна переміщатися по них і виконувати будь-які завдання. Додаткове випробування для вас, коли ви освоїте VoiceOver: спробуйте закрити очі і подивіться, чого зможете досягти.

ЗАСТОСУВАННЯ TALKBACK В ANDROID

Подібно VoiceOver, TalkBack – це служба доступності для людей з ослабленим зором, яка є «рідною» для пристроїв Android. Так як більшості людей ця служба не потрібна, вона також відключена за замовчуванням. Щоб увімкнути функцію, перейдіть до Установки → Accessibility → TalkBack і доторкніться до показаного нижче перемикача.

Мобільні пристрої та доступність: навіщо їй стільки уваги і що з нею робити

Сторінка налаштувань для TalkBack в На е

Знову повинен вас попередити. При активації TalkBack вам щонайменше потрібно знати основні елементи управління, щоб виключити її потім.

Елементи управління TalkBack дуже схожі на елементи VoiceOver’а. Один дотик вибирає елемент, а подвійне – активує його. Прокрутка у TalkBack вимагає двох пальців (пам’ятаєте, що для VoiceOver потрібні три), і TalkBack слухає ті ж самі дії змахування для переходу до елементів сторінки.

Хоча у TalkBack’а немає нічого схожого на ротор VoiceOver’а, для налаштування навігації він підтримує безліч додаткових жестів.

Короткий висновок

У цій статті ми обговорили кілька кращих практик поліпшення доступності ваших веб-сайтів. Як застосувати цю інформацію до ваших існуючих або нових сайтів? Ось кілька елементів оперування:

Клавіатура

Переконайтеся, що будь-які завдання можна виконувати, використовуючи лише клавіатуру.

Використовуйте семантичні елементи — button для кнопок і a для посилань.

Якщо вам складно зробити складні віджети зручними для клавіатури, подумайте про використання каркасів.

Форми

Користуйтеся цим елементом form.

Асоціюйте всі елементи форми (input select та textarea) з міткою label.

Переконайтеся, що для відправки форми може використовуватися клавіша введення «Enter».

Контрастність

Забезпечте весь текст ступенем контрастності не менше 3.0 за допомогою інструменту Леа Віру Contrast Ratio. В ідеалі, відповідати цьому критерію мають будь-які тексти, але спочатку зверніть увагу на основний вміст.

Зображення

Увімкніть атрибути alt, описують зображення.

Посилання і кнопки

Завжди призначайте цим елементам управління читається контент. Якщо контент не слід показувати зрячим користувачам, то застосуйте техніку заміщення зображення приховати його.

Хоча цей список далеко не повний, тим не менш він описує певну кількість легко застосовних практик, які вирішують найбільш часті проблеми, що зачіпають користувачів з фізичними вадами. Більше того, ми вже бачили, що користь від дотримання цих принципів отримують всі користувачі, а не лише їх певна категорія.

Нарешті, самий кращий метод перевірити свій веб-сайт – скористатися цим скринридером. Витративши декілька хвилин на те, щоб вивчити команди, ви дізнаєтеся в подробицях, як взаємодіє в Вебі значна частина населення.