Інклюзивний дизайн: аргументи, практики, тестування та втілення

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

Консультантка лондонського UX-агентства Webcredible Олена Булигіна провела вебінар у школі Projector Online, де розповіла про принципи, стандарти і технології зі своєї сфери та дала конкретні кроки, інструменти і методи впровадження аксессібіліті в дизайн-практиці.

Читайте також: Accessibility – термін, який ми не знаємо

Ілюстрація Жені Полосіної і Ані Іваненко для школи Projector Online

Чому ми робимо сайти для людей, які їх не бачать?

Це реальне запитання, яке ми почули від одного з наших клієнтів і це можна зрозуміти.

Приблизно 20% користувачів вебу мають певні ментальні або фізичні порушення. Тобто приблизно кожна п’ята людина відрізняється від того, що заведено називати «нормою». І це безпосередньо впливає на взаємодію з цифровими продуктами й сервісами.

Вступ до інклюзивного дизайну

Для початку визначимось із термінами:

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

Accessibility (або доступність) — мета цього процесу, коли різним людям однаково зручно користуватись продуктом.

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

Аргументи на користь інклюзивного дизайну:

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

Що спільного в цих зображеннях?

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

Законодавче регулювання

Ось перелік законів, які визначають доступність, описують вимоги й наслідки за їх недотримання.

Медична і соціальна модель інвалідності

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

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

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

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

Класифікація користувачів

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

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

Види порушень:

Сенсорні: зір, слух. Серед них — гостра втрата зору (сліпота), порушення зорового поля (глаукома), дальтонізм двох типів. Слух може втратитись чи погіршитись з віком або через травму.
Фізичні: моторика. Це може бути повна втрата функціонування (наприклад, відсутність ноги, параліч), втрата рухомості, сили, швидкості, координації м’язів, точності, мобільності.
Когнітивні: увага, опрацювання мови. Вони стосуються втрати пам’яті, координації (наприклад, рук і очей), нейрорізноманіття (аутизм, дислексія, диспраксія).

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

Ще один спосіб класифікації людей з інвалідністю — орієнтуватись на тип порушення: постійне воно, тимчасове чи ситуативне. Ось класифікація Microsoft:

Люди, які повністю втратили слух, і ті, в кого це тимчасово, і ті, хто просто стоїть у шумному барі, — всі вони опиняються на якусь мить приблизно в тій самій ситуації. Це, знову ж таки, про те, що доступний дизайн може бути корисним для дуже багатьох різних людей. Microsoft, коли розробляла accessibility-контролери для XBox, повторювала цю думку у своєму слогані: «Коли граємо ми всі, то виграє́ кожен з нас».

Подивіться на це зображення і подумайте, хто виграє від такої конструкції:

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

Практика вебдоступності

Стандарти

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

Є стандарти, присвячені фізичним девайсам і обладнанню, програмному забезпеченню і вебконтенту. Ми зосередимось на останньому. Ось три абревіатури, які потрібно запам’ятати:

Web Accessibility Initiative (WAI) — це організація, що пише та видає гайдлайни про доступність, котрі вже стали стандартами.
WAI-ARIA — набір стандартів, запущений у 2014 році у відповідь на те, що сайти стали масово використовувати складні інтерактивні елементи, які не є доступними для всіх. Це стосується, наприклад, технології Drag-and-drop або таймерів зворотного відліку.
WCAG — це основа всієї галузі вебдоступності, набір стандартів, які описують і визначають поведінку контенту. Стосується зображень, звуків, мультимедіа, тексту, структури, коду, візуального дизайну.

Перші вебстандарти з’явились ще у 1999 році, тож ця тема не нова і багато аргументів на захист вебдоступності вже прозвучали 20 років тому. На сайті Nielsen Norman Group перші статті про це з’явилися теж в 1999, а перше масштабне дослідження та репорт вони зробили в 2001.

Чотири принципи WCAG:

Perceivable — інтерфейси мають бути розроблені так, щоб люди могли їх сприймати. Вони не можуть бути невидимими, не читатись екранними дикторами, бути винятково звуковими тощо.
Operable — всі взаємодії мають бути доступними. Якщо на сайті певна дія прописана тільки для мишки, то люди, які користуються лише клавіатурою, не зможуть її виконати. Так бути не повинно.
Understandable — інформація й елементи інтерфейсу мають бути зрозумілими та не перевищувати можливостей людини. Це стосується і банального поділу тексту на блоки й заголовки, і абстрактних формулювань, які не всі можуть зрозуміти.
Robust — сайт має підтримувати якомога більше адаптивних технологій (екранних дикторів, різних налаштувань браузера тощо) і при цьому бути зручним (usability).

Аудит

Це перевірка того, наскільки продукт доступний для людей з інвалідністю. Для цього використовуються гайдлайни й спеціальні методи.Також можна застосувати автоматичну чи ручну перевірки.

Корисні плагіни для аудиту:

Tota11y Plugin, розроблений Khan Academy;
WAVE Evaluation Tool;
Lighthouse від Google;
Spark contrast checker для Sketch.

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

Методологія проведення аудиту WCAG

Визначаєте обсяг і призначення: ви перевірятимете 5 сторінок з user journey чи це будуть основні частини однотипних сторінок з центру підтримки?
Відкриваєте файл і методично проходитесь кожним гайдлайном, відповідно до потрібного вам рівня доступності.
Робите звіт і вказуєте, що мають змінити чи зробити розробники та дизайнери.

Як зробити це швидше

Відкрийте сайт, вимкніть зображення, подивіться, яка інформація втратилась (наприклад, номери телефонів подавалися як картинка, а не текст абощо).
Якщо є аудіосупровід — вимкніть звук.
Протестуйте сайт без кольору і без контрасту — якщо десь втратилась інформація або сенс, це порушення доступності.
Покористуйтесь сайтом лише за допомогою клавіатури — чи зі всіма елементами так можна взаємодіяти?
Збільшіть і зменште текст з 25% до 300% — чи не пікселить він, чи не вилазить за межі сторінки?
Перегляньте код: чи використані таблиці для форматування, чи позначені заголовки h1, h2 тощо?
Якщо на сайті є мультимедійні файли, перевірте, чи є в них альтернатива — та ж інформація, але в доступній формі.

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

Усі групи користувачів, на які вплинуть зміни, і те, наскільки суттєвим буде вплив (йдеться про невеликі незручності чи про повну неможливість користування).
Скільки сторінок з вашого аудиту і скільки сторінок сайту потрібно змінювати. Дізнайтесь у девелопера, наскільки складно це буде зробити. Якщо сайт побудований на темплейтах, впливові зміни в основних елементах можуть значно покращити доступність.
Як вплине все це на User Journey. Подивіться, які ключові задачі порушуються найбільше і налагодьте це найпершим.

Accessibility-тестування

Коли це робити? В ідеалі — коли на руках уже є результати аудиту, де точно вказані всі недоліки й те, як їх виправити. Для тестування потрібні люди з різних груп (з когнітивними, слуховими, зоровими порушеннями), будь-яка їх кількість буде корисною, ми зазвичай формуємо групу з мінімум 6 осіб (по 2 людини на кожен тип порушень). Це звучить грубо і цинічно, та в такій роботі все ж доводиться мати справу з цифрами.

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

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

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

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

Найкращі практики, або що ви можете зробити вже зараз

Використовуйте семантичний HTML

Кнопка має бути кнопкою, а не div-ом, оформленим як кнопка. Тоді люді, які користуються екранним диктором, зрозуміють структуру сайту.

Дублюйте весь контент текстом

Уся непродубльована текстом інформація буде невидимою для екранних дикторів. Alt-атрибути мають бути прописані для всього осмисленого контенту. Те ж стосується і капчі.

Перевірте логіку і порядок заголовків

H1 має бути один і він повинен містко та чітко передавати зміст і призначення сторінки.

Не пропускайте рівень заголовку лише для візуального ефекту. Використовуйте інші засоби форматування тексту.

Супроводжуйте мультимедійний контент текстом

Додавайте субтитри і для записів, і для live-контенту. В аудіо- і відеофайлів мають бути текстові альтернативи.

Форми

поле label має бути осмисленим, перевірте, чи всі обов’язкові поля правильно марковані (не зірочкою, тому що її екранні диктори не читають);
плейсхолдери у формах — це погана практика для доступного дизайну;
використовуйте HTML усюди, де це можливо.

Продемонструйте :focus

Це потрібно для користувачів, які користуються сайтом лише за допомогою клавіатури. Елемент у фокусі має підсвічуватись.

Контраст

Переконайтесь, що всі компоненти достатньо контрастують з тлом і самі по собі. Оптимальний мінімальний контраст 4.5:1 для шрифтів в 14px і менше.

Не використовуйте тільки колір*

*для передавання інформації

Додайте хоча б іконку.

Оформлюйте посилання правильно:

Як втілювати це в команді

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

Зробіть це гарячою темою:

Постери (є безкоштовні і легальні від британської GDS, їх можна роздрукувати й повісити в офісі).
Слак-канал, щоб обговорювати цю тему з колегами за межами своєї команди, тут дизайнери та девелопери швидко знаходять порозуміння.
Воркшоп з емпатичного моделювання (наприклад, спробувати надягнути маску для сну та прокласти маршрут на Google Maps і обговорити це).
Тренінги, курси — велика частина забезпечення веб-аксесибіліті полягає в навичках та розумінні стандартів, технологій та інтердисциплінарних практик.

Як говорити про це з іншими людьми, зокрема з клієнтами або колегами:

Не звинувачуйте і не присоромлюйте, сприйміть наявний стан речей як стартову точку. Те, де ви зараз — зазвичай результат великої кількості бізнес-рішень, legacy-систем та інших приоритетів, а зараз є можливість змінити це і почати робити краще.
Наполягайте на перевагах (якщо ми зробимо сайт доступним, то збільшимо прибуток на 10%). Якщо ваш сайт буде справді доступним і зручним для людей з інвалідністю, вони будуть вашою найлояльнішою аудиторією.
Впевнено і суворо пріоритезуйте. Найперше робіть речі, які вирішальні для аудиторії, Не обов’язково витрачати на це всі сили й кошти. Часто буває так, що наче мінімальними змінами можна вирішувати великі проблеми на весь продукт. Якщо ви можете полагодити клавіатурну навігацію, перевірити заголовки — це вже значний крок вперед.

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