Чому вебдоступність — це не примха і як про неї подбати

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

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

Про яку кількість людей взагалі йдеться? Наприклад, за даними ВООЗ, щонайменше 2,2 мільярда людей мають певні порушення зору або є незрячими. 430 мільйонів людей у всьому світі мають вади слуху. Очікується що до 2050 року певний ступінь втрати слуху матимуть 2,5 мільярда людей. Якщо ж звернутись до даних W3C, загалом 15–20% від усього населення планети має певні фізичні або ментальні порушення.

Щоб сайти й застосунки були доступні для різних користувачів, у багатьох країнах існують обов'язкові стандарти та закони. Зазвичай вони базуються на технологічних стандартах і рекомендаціях, які розробляє міжнародна організація World Wide Web Consortium (W3C).

За ними, вебдоступність (Web Accessibility) має враховувати всі аспекти, які впливають на користування інтернетом. Зокрема йдеться про порушення:

зорові (це може бути колірна сліпота, часткова або повна втрата зору);
слухові;
когнітивні (наприклад, порушення пам'яті, логіки, проблеми з концентрацією уваги тощо);
неврологічні та фізичні (як от проблеми з координацією, моторикою, дислексія);
мовленнєві.

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

Чому універсальний дизайн — це добре для всіх

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

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

Існує чимало технологій, які допомагають людям з порушеннями користуватись інтернетом та обладнанням. Наприклад: екранні диктори, які озвучують текст, спеціальне чутливе обладнання (клавіатури, скажімо) для користувачів з порушеннями моторики, є екранні лупи та інструменти, що адаптують інформацію до системи Брайля. Також існують програми на кшталт TalkBack, Live Transcribe (перетворює мовлення на текст), Sound Amplifier (допомагає фільтрувати та посилювати звуки) або набір Dragon NaturallySpeaking для голосового управління.

На британському сайті gov.uk (який вважається одним зі взірців доступності) є серія інтерв'ю з людьми, які використовують адаптивні технології та розповідають про них — чим і як зручно користуватись у різних випадках.

Раніше ми публікували статтю про те, як програмують люди з порушеннями зору. Там згадуються спеціальні середовища розробки й редактори коду та адаптовані операційні системи. За даними Stack Overflow, порушення зору мають кожні 3 розробники з 200 (1350 з 90 000 опитаних).

Стандарти доступності

Коли взагалі правила доступності почали регулюватись на законодавчому рівні? 1986 року у закон США про реабілітацію (Rehabilitation Act, 1973) додали Розділ 508 про доступність електронних та інформаційних технологій. Але у ньому не було рекомендацій та механізмів втілення цієї ідеї, тож у 1998 році його доробили.

Втім, цей закон стосується федерального уряду США, а не приватних компаній та їхніх сайтів або продуктів. Набагато поширенішими є добровільні стандарти Консорціуму W3C.

Перший з них, WCAG, опублікували у 1999 році. Друга версія (WCAG 2.0) вийшла у 2008, це один з основних стандартів, якими розробники послуговуються зараз. Стандарт дещо доповнили у версії WCAG 2.1, вона відповідає основній версії та враховує зміни в мережі за останні роки. Також робоча група працює над створенням наступного варіанту — WCAG 2.2.

До речі, дизайн-система державних сайтів України теж розробила рекомендації доступності, які спираються якраз на стандарт WCAG (рівня АА).

POUR: 4 принципи WCAG, або яким має бути контент

Доступним для сприйняття (Perceivable): наприклад, інформація на сайті має сприйматись не лише візуально, а й нормально зчитуватись екранним диктором. Скажімо, HTML-код дозволяє зробити описи зображень, щоб люди, які не бачать їх, могли зрозуміти зміст картинки.
Доступним для взаємодії (Operable): наприклад, щоб користувачі могли взаємодіяти з інтерфейсом та вводити дані за допомогою клавіатури або голосу.
Зрозумілим (Understandable): йдеться про суцільні текстові блоки, складні формулювання, неочевидні взаємодії чи структуру — тобто контент, який складно сприймати.
Надійним і стійким (Robust), тобто сумісним з новими й старими технологіями та допоміжними засобами, аби ними можна було послуговуватись під час взаємодії з сайтом чи застосунком.

Окрім стандартів WCAG, Консорціум також розробив Посібник з доступності інструментів (Authoring Tool Accessibility Guidelines) — ATAG, тут перелічені вимоги до редакторів коду, систем його управління та іншого ПЗ для створення контенту.

Ще один важливий документ — User Agent Accessibility Guidelines (UAAG), він описує, як зробити доступними браузери, розширення, медіаплеєри та інші user agents. Він також створений організацією W3C та узгоджений зі стандартами WCAG 2.0 і ATAG 2.0.

WAI-ARIA: (Accessible Rich Internet Applications) — набір вебстандартів про доступність інтернет-застосунків та контенту в мережі. Він призначений для динамічного контенту у сучасних інтерфейсах, які створили за допомогою Ajax, JavaScript, HTML тощо.

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

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

Що буває за порушення законів про доступність

Окрім стандартів W3C, деякі країни мають законодавство, що визначає обов'язкові параметри доступності. Нерідко воно базується саме на WCAG 2.0 AA.

США, як ми згадували, має Розділ 508, у якому йдеться доступність електронних та інформаційних технологій. Також тут діє Americans with Disabilities Act (ADA, 1990) що забороняє дискримінацію.

Велика Британія розробила один з найґрунтовніших документів з приводу доступності та дискримінації — це Equality Act 2010 року (якому передував Disability Discrimination Act 1995 року).

ЄС має окремий стандарт EN 301 549 — з вимогами доступності у продуктах та послугах, що стосуються інформаційно-комунікаційних технологій (ICT). Його ухвалили не так давно, у 2014 році, та оновили у 2018.

Ці стандарти не є рекомендаціями, вони обов'язкові, тож їхнє порушення карається законом. Наприклад, у 2018 році у США подали 2258 позовів, які стосувались доступності. У 2017 їх було на 177% менше — 814 справи. У 2019 році у федеральні суди США подали 2556 позовів з приводу порушення ADA. Близько 60% таких позовів стосуються онлайн-магазинів.

Один зі знакових прикладів — справа проти Netflix 2012 року (так, він вже тоді працював, компанія заснована аж у 1997 році). Національна асоціація людей з глухотою (NAD) подала до суду, адже Netflix не надав рівноцінні послуги для користувачів з вадами слуху. Суд постановив, що сервіси, які функціонують онлайн повністю чи частково, все ж зобов'язані відповідати вимогам ADA. Тому в Netflix з'явились субтитри практично до всіх відео (хоча питання до якості залишилось), і ця справа стала досить показовою.

Ще одна з найвідоміших справ з приводу вебдоступності стосувалась американської мережі магазинів Winn Dixie. Річ була в тім, що сайт магазину не адаптували для людей з порушеннями зору — туди додали безліч нових фіч, але екранними дикторами нічого не зчитувалось (а це 2017 рік, на хвилиночку). Позивач виграв справу і це створило прецедент, за яким на сайти мають дотримуватись вимог доступності.

Кілька років тому створення доступних сайтів могло здаватись надлишковим етапом розробки. Та насправді не обов'язково витрачати на це безліч часу та ресурсів. У стандартах WCAG є різні ступені адаптованості сайтів (А, АА, ААА). Мінімальний рівень можна створити досить безпроблемно і це мало вплине на загальний вигляд і дизайн сайту.

У більшості судових справ компанії припускались однакових помилок, які легко виправити. Наприклад, контент на сайтах не зчитувався екранними дикторами, сторінки не мали альтернативного тексту для зображень і графіки або ж використовували порожні посилання (Redundant links, перевірити їх можна за допомогою Dead Link Checker або розширення Chrome Check My Links). Це одні з найпоширеніших проблем доступності, які легко знайти та виправити. Перевіряти такі речі можна завдяки автоматичним інструментам тестування, детальніше про них ми поговоримо далі.

Доступність та корпорації

Доступність — це частина інтерфейсу продукту, тож корпорації часто описують її у своїх довідниках про дизайн-системи. Наприклад, такий розділ є на сайті Google accessibility та на сторінці Material, де компанія публікує свої вказівки та інструменти для розробки. Ось деякі рекомендації звідти.

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

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

Щоб екранні диктори могли зчитувати контент послідовно, розробники мають стежити за правильною структурою HTML-коду. Якщо від CSS залежить макет і вигляд сторінки, то екранні диктори покладаються суто на HTML і його порядок. Наприклад такий код буде зручним для користувачів екранного диктора:

<section class="container">
   <img class="step-1" />
   <img class="step-2" />
   <img class="step-3" />
   <img class="step-4" />
</section>

А такий ні:

<section class="container">
  <div class="col-left">
    <img class="step-1" />
    <img class="step-3" />
  </div>
  <div class="col-right">
    <img class="step-2" />
    <img class="step-4" />
  </div>
</section>

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

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

Коефіцієнт контрастності показує, наскільки один колір відрізняється від іншого. Зазвичай він позначається як 1:1 чи 21:1 (чим більша різниця між числами, тим більша різниця у яскравості кольорів). Наприклад, чорне тло з чорним текстом мають контраст 1:1, а білий текст на чорному тлі — 21:1.

Консорціум W3C радить такі показники для більшості сайтів:

Для великого тексту (це або від 14 пт напівжирним, або 18 пт звичайним накресленням) контраст з тлом має бути 3:1. Для графіки також. Якщо ж текст дрібний — контраст з тлом має бути 4,5:1.

Не варто передавати інформацію за допомогою самого лише кольору (наприклад червоної чи зеленої смужки). Передати той самий сенс можна й іншими елементами дизайну: іконками, мітками, індикаторами, додатковим текстом, який, наприклад, пояснює в чому саме помилка.

Користувачам може знадобитись збільшити розмір тексту; мобільні пристрої та браузери дозволяють змінювати масштаб шрифтів у всій системі. Щоб увімкнути системний розмір шрифту в Android-застосунку, треба позначити текст та пов'язані з ним контейнери, аби шрифти вимірювались в масштабовних пікселях. Переконайтесь, що вистачить місця для великих шрифтів або тексту іншою мовою (наприклад, тут).

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

Лише не треба зловживати оптимізацією і писати щось на кшталт: Токіо, токіо, Японія, японія, суші, суши, вежа, вечір, ніч, підвечірок, будинки, будівлі, небо, горизонт, небокрай, небосхил, обрій. Краще взяти кілька пов'язаних ключових слів, які чітко описують зображення (слово зображення теж писати не варто, екранний диктор це і так розуміє).

До речі, якщо зображення суто декоративне і ніякого змісту не несе, не обов'язково додавати альтернативний текст. Google радить залишити тег alt порожнім (alt = ""), щоб екранні диктори пропустили його. Те ж саме можна зробити, якщо зображення має підрисунковий підпис, що пояснює його зміст.

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

Окрім ґайдлайну Google, є ще дизайн-системи Microsoft, Saleforce, IBM та Atlassian. Вони також визначають, як робити інтерфейси більш доступними й містять корисні рекомендації для розробників.

Зупинимося на кожному аспекті трошки детальніше.

Вебдоступність: колір і контраст

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

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

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

Чим перевірити колір і його контраст

A11y Color Contrast Accessibility Validator: аналізує контрасти кольору і показує, які проблеми є певних колірних поєднань. Спирається на стандарт WCAG 2.1.

Accessible Colors: тут можна ввести параметри тексту (розмір та товщину та HEX-код кольору) та фоновий колір і подивитись, чи відповідає така комбінація певному стандарту WCAG 2.0.

Accessible Brand Colors: показує, чи відповідає колірна гама вимогам ADA.

Accessible Color Evaluator: пропонує кольорові схеми для елементів інтерфейсу, щоб вони були доступними.

Button Contrast Checker: перевіряє кольоровий контраст кнопок і посилань на сайті.

Colour Contrast Analyser: зручне розширення Chrome, що аналізує вебсторінки, зображення або PDF-файли та визначає, які текстові елементи не відповідають вимогам колірного контрасту. Можна обирати частини екрану або лише видимий контент.

Color Oracle: перевіряє, як показується контент для людей з дальтонізмом. Настільний інструмент, є версії Mac, Windows і Linux (для Windows та Linux потрібен Java 6). Автори проєкту також публікують поради про дизайн і доступність кольорів.

animation

Color Safe: допомагає обрати кольори, щоб вони поєднувались з, наприклад, брендовою гамою і водночас відповідали стандартам AA чи AAA. Також враховує сімейство шрифтів, кегль та насиченість тексту й колір тла.

ColorShark: інструмент, що перевіряє контраст кольорів на відповідність WCAG 2.1 AA й AAA.

Contrast Ratio: визначає контрастне співвідношення між кольорами тексту і тла.

Stark: плагін для Sketch, порівнює два кольори на контрастність.

Sim Daltonism: симулятор зорових порушень для Mac OS X (від версії 10.2.8 і далі).

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

Who Can Use: показує, кому підходить обрана кольорова схема і чи відповідає вона стандартам.

WebAIM Link: перевіряє колірний контраст у посиланнях.

Також на цю тему є докладна стаття від організації Агенти змін.

Вебдоступність: шрифти

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

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

Зверніть увагу на форму літер, аби вона була чіткою і літери I (велика і), l (маленька л латинкою) та цифра 1 достатньо відрізнялись. Те саме стосується літери O та цифри 0. Багато хто обирає шрифт Arial саме з цієї причини.

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

Літери d і b або p і q не мають бути дзеркально ідентичними, інакше їх складніше сприймати.

Уникайте рукописних, декоративних шрифтів або таких, що мають лише один регістр. Наприклад, якщо слово написане КАПІТЕЛЛЮ, скрінрідер може прочитати його як абревіатуру, це не додає зручності.

Існують спеціальні гарнітури для людей, наприклад, з дислексією (наприклад, шрифт Dyslexie, він має відкритий код). Однак вони все ж мають нетиповий вигляд і можуть відволікати інших користувачів. Те ж саме стосується гарнітур зі збільшеними інтервалами (наприклад, Lexend).

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

Оптимальною довжиною рядка вважається 50–75 символів. Найкраще — 66. Якщо в тексті велика відстань між рядками, то рядки можна робити трохи довшими.

Не підкреслюйте текстові елементи, якщо це не посилання.

В частині про контрасти ми згадували про рекомендації W3C щодо контрастності й розміру шрифту. Там зазначено, що починати варто з 18 пунктів для звичайного шрифту або з 14 пунктів для півжирного.

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

Вебдоступність: інтерфейс

Передовсім, хороший інтерфейс = масштабовний інтерфейс. Якщо користувач збільшує сторінку, щоб розібрати текст, — погано, коли вся верстка летить і доводиться гортати сторінку вбік, аби прочитати речення. WGAG рекомендує підтримувати масштабування у 200%.

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

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

Приклад форми пошуку, де немає чіткого контуру:

Приклад форми пошуку, де є чіткий та контрастний контур:

Також бажано, щоб поруч з формами були позначки-вказівки. А от текст-наповнювач для таких форм використовувати не варто.

a { outline: none; } — це зло (якщо ви не подбали про якусь альтернативу). Можливо, вам не подобається сіра або синя рамка, тоді зробіть її іншою, але зробіть. Інакше вашим сайтом буде практично неможливо користуватись лише з клавіатури.

Подбайте про :focus, він потрібний для людей, які послуговуються сайтом лише за допомогою клавіатури. Зазвичай використовується Tab, щоб рухатись по сторінці та обирати інтерактивні елементи. Коли елементи у «фокусі» клавіатури, з ним можна взаємодіяти.

Не забудьте додати атрибути tabindex. Вони мають бути логічно впорядкованими, як і структура сторінки загалом. Інколи хочеться використати tabindex, щоб компенсувати погано впорядкований код з не дуже логічною навігацією. Однак використовувати позитивні значення tabindex все ж не рекомендується. Краще виправити навігацію, змінивши структуру HTML.

Визначте критично важливі елементи, візуально підкресліть їх та подбайте про достатні відстані, аби елементи не зливались (особливо, якщо вони подібні за стилем).

Подбайте про ARIA landmarks або структурні елементи HTML5 (<main>, <nav> тощо).

Оформлюйте кнопки як <button>, а не як <div> — так користувачі екранного диктора зрозуміють, що це кнопка. До того ж кнопками <button> зручно перемикатись з клавіатури за допомогою Tab.

Зберігайте чітку ієрархію заголовків: після H2 йде H3, а H1 у тексті має бути лише один.

Поставте лінк для переходу до основного контенту, це суттєво поліпшить навігацію.

Не використовуйте лише колір для того, щоб передати інформацію (наприклад, натисніть зелену кнопку й оберіть синє коло). Краще додати графічні індикатори, мітки та додатковий текст (наприклад знаки X і V, + та - тощо).

Додайте у відео субтитри та розшифровки. Перші допоможуть користувачам з вадами слуху, а розшифровки передадуть зміст для користувачів з порушеннями зору.

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

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

Як перевірити сайт на доступність

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

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

Вимкніть CSS і подивіться, що залишилось. Користувачі скрінрідерів сприймають сам зміст сторінки, хоч який там яскравий дизайн чи бадьора анімація. До того ж люди з порушеннями зору можуть змінювати дефолтні стилі у браузері (наприклад, щоб підлаштувати кольори). То чи не втрачається контент та зміст на сайті без вашого CSS? Чи можна взаємодіяти з сайтом, чи сприймається сторінка послідовно?
Зробіть те саме із зображеннями й подивіться, чи нічого не втратилось: зміст, взаємодії, структура, чіткість. Люди з когнітивними порушеннями або ті, кому складно зосередитись, можуть вимикати зображення — як і користувачі з повільним інтернетом. Картинки мають супроводжуватись текстом або мати альтернативний опис для користувачів екранних дикторів.
Якщо на сайті є відео чи аудіо — спробуйте вимкнути його й оцінити, чи не втрачається зміст, чи є альтернативи аудіовізуальному контенту (субтитри, розшифровки тощо).
Збільште і зменште масштаб, змініть проміжки між словами та міжрядкові інтервали (так можуть робити люди з вадами зору або з дислексією). Подивіться, чи не полетіла верстка, чи не пікселять картинки, чи не з'явився боковий скролбар у масштабі до 200%.
Перегляньте сторінку у безколірному режимі та без контрасту, чи не втратилась важлива інформація?
Прослухайте вашу сторінку екранним диктором і зверніть увагу на структуру, заголовки, кнопки та інші інтерактивні елементи. Одні з найбільш поширених програм: JAWS чи NVDA для Windows, VoiceOver для MacOS, TalkBack для Android.

Чим перевірити доступність сайту

Wave — чи не найбільш поширений інструмент для перевірки вебдоступністі, розроблений WebAIM. Ви вводите посилання, Wave аналізує сайт та видає список помилок, порушень і рекомендацій. Дуже багатовекторний: оцінює колірний контраст, структуру, пусті посилання та кнопки відповідність ARIA, багато чого. Є розширення для Chrome.

Google Lighthouse. Окрім доступності, ще вміє перевіряти продуктивність, параметри SEO й окремо аналізує прогресивні вебзастосунки (PWA). За хвилину Lighthouse оцінює головні параметри та видає рекомендації, як поліпшити сайт чи застосунок — з інструкціями, поясненнями та посиланнями.

Lighthouse можна запустити через Chrome DevTools, як модуль Node, у командному рядку і як браузерне розширення, є версія для Firefox.

Tota11y — тулкіт, що показує, як ваш сайт працюватиме із допоміжними (assistive) технологіями. Використовує набір плагінів, які підкреслюють певні елементи на сторінці, вказують, що з ними не так, і пропонують виправлення. Підходить для будь-якого настільного браузера.

Додаткові ресурси:

Сайт W3C

25 інструментів для перевірки доступності сайтів

A11project

Firefox Accessibility Features

Лекції про інклюзивний дизайн від Projector

Дизайн-системи Microsoft, Google, Saleforce, IBM та Atlassian.