Дякую, дякую. Бачите, сьогодні у мене презентація на тему веб-доступності, і поруч зі мною є цілих два ноутбуки, один макбук і телефон. І як тільки за 10 хвилин до початку я почав підключатися вдруге, інтернет заблокували на обох лініях. І сьогодні ми саме будемо говорити про таку доступність. Доступність для всіх, або доступність – це не про мене. Чому це не про мене, а про когось? Тому що кожен з нас може опинитися в ситуації з обмеженою доступністю, так само як я тільки що це відчув. Перед стрімом я втратив зв'язок. Ще й те, що на одному ноутбуці може працювати звук, а на іншому – відео. Ось, тепер про мене немає сенсу говорити, Христина вже розповіла більше, чи не так?

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

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

Чому це важливо? У світі 15% людей мають обмежені можливості, що становить 1 мільярд 176 тисяч осіб (статистика на 2022 рік, і зараз цих людей ще більше). І треба також враховувати Україну, де більшість з нас проживає. Навіть якщо говорити не про соціальну веб-доступність, а просто про доступність, то у нас є 2 мільйони 450 тисяч людей з інвалідністю. З них 162 тисячі – це діти з інвалідністю. Це значна кількість. І доступність важлива, коли потрапляєш в ситуацію, яку неможливо передбачити, як це сталося із мною. І коли говоримо саме про безбар'єрність, ми можемо розрізняти 4 типи обмежень.

Це слухові обмеження, коли людина обмежена слухом або мовленням і не може повністю сприймати сказане. Наприклад, зараз я вас не чую. Я у Житомирі, і тут у мене проблеми з онлайн-зв'язком. Якщо ви голосно кричите, можливо, я почую, але в середньому я не чую вас. Також маємо зорові обмеження, пов'язані із зором, наприклад, дальтонізм. Обмеження, пов'язані з треморами – коли є труднощі з утриманням стабільності. Також опорно-рухові обмеження, пов'язані із фізичними можливостями. І когнітивні обмеження – найскладніша категорія. В новій версії WCAG 3.0 когнітивні обмеження розділені на дві підкатегорії: когнітивні і нейробіологічні, пов'язані з неможливістю сприймати інформацію.

Що таке ситуативні веб-обмеження? Наприклад, одна компанія випустила цікавий застосунок для бігу. Все в ньому було чудово, але виникла проблема – застосунок мав тільки темну тему, і на сонячному світлі його було неможливо використовувати. Таким чином, людина опинялася в обмеженні доступу під час користування застосунком. Інший приклад – програма для навчання. Вона була чудовою, але тут виникла проблема: можна було вводити формули лише за допомогою пензлика для лівші, а не клавіатури.

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

До речі, важливо розуміти, як аналізувати веб-доступність та працювати з нею. Важливо розглядати фактори, такі як місце запуску вашого веб-ресурсу, оскільки є країни, де немає жодного документу, що обмежує або визначає доступність. Наприклад, в Японії відсутні норми, тому що там велике підтримуюче ставлення до старших людей та осіб із обмеженими можливостями. В інших країнах, навпаки, необхідно мати законодавчий акт, як у США, де є закон про інвалідів з 2006 року, або в Європейському Союзі, де діє рекомендаційний акт про доступність з 2019 року та обов'язковий акт, що набуває чинності з 2025 року.

При цьому важливо зазначити, що з 2025 року всі веб-ресурси, що використовуються в Європейському Союзі (а до 25 року Україна також буде в цій зоні), повинні мати як мінімум другий рівень доступності згідно із Загальним актом про доступність Європейського Союзу. В противному випадку передбачаються штрафні санкції, а процедура дуже схожа на ту, що існує для захисту персональних даних користувачів Європейського Союзу, відому як GDPR. У Канаді існує рекомендаційний лист, обмеження форми A11y тарифів із законом про інвалідність, також відомий як A11y form tariff with disability act. Це обмеження має схожість до американського стандарту і є рекомендаційного характеру. В інших країнах також існують окремі документи, наприклад, в Австралії та інших.

До речі, в Україні наразі відсутній активний документ або рекомендаційний посібник, який б містив обмеження. Тому наша увага повинна бути зосереджена на міжнародно визнаних стандартах. Один з таких стандартів - це стандарт W3C, який існує в двох, а навіть трьох версіях. Є Web Content Accessibility Guidelines версії 2.1, яка є затвердженим стандартом, і є стандарт версії Web Content Accessibility Guidelines 2.2, який наразі є у стані чернетки, але вже вважається завершеним стандартом з точки зору de jure, тобто юридично, його вважають завершеним стандартом. До речі, компанія чи спільнота ProOn, яка діє в Україні, буквально два тижні тому переклала цю версію стандарту на українську мову. Таким чином, ми маємо офіційно існуючу версію стандарту на українській мові, яку можна знайти як на сторінці ProOn, так і на сторінці W3C.

Планується випуск концептуально нової версії, а саме стандарту 3.0, яку планують завершити до кінця цього року. Ця версія додає можливості діджиталізації, такі як робота з іконками і блютуз-гарнітурами для людей з обмеженими можливостями. Також передбачено можливості роботи з API веб-браузерів. Проте, важливо враховувати, що ймовірно, цього року ми не отримаємо цю версію стандарту, оскільки, як правило, випуск нових версій може затримуватися на рік, два чи навіть три. Згідно з прогнозами розробників веб-доступності, ймовірно, стандарт третьої версії вийде під документом Європейського Союзу у 2025 році.

Ще одним стандартом, який застосовується, є Y-Aria, який складається з трьох окремих агентів та розділів. FAC, або User Agent, описує доступність з точки зору агентів, таких як скрінрідери, читалки та системи дотику. Звертаючись до стандарту 3.0, його скорочена назва буде AG, або Аргент. Чому саме Аргент? Це пов'язано зі змінами в рівнях доступності, і тепер рівень A, який ми загалом реалізуємо, буде відкинутий. Тобто, найнижчий рівень доступності, такий як, наприклад, додавання підказок до зображень, з точки зору стандарту 3.0 вже не вважатиметься частиною доступності. Частиною доступності вважатиметься контент, який має рівень AA. Наприклад, в мультимедіа буде автоматична генерація субтитрів.

Таким чином, якщо можливо автоматично генерувати субтитри, це вже буде вважатися покращенням доступності. З точки зору 3.0 версії, документ буде поділений на кілька розділів. Перший розділ стосується сприйняття, тобто як людина може сприймати наш контент. Другий розділ пов'язаний з управлінням, тобто як людина може взаємодіяти з нашим сайтом за допомогою клавіатури, тачпада та інших засобів. Цей розділ залишається досить стійким у порівнянні з поточною версією. Третій розділ стосується зрозумілості, і тут практично нічого не змінюється, оскільки рішення, що були раніше, залишаються актуальними. Щодо аудиту веб-ресурсів, існує методологія з п'ятьма рівнями дослідження доступності, кожен з яких включає 10 критеріїв. Проте важливо враховувати, що чіткість інструкцій для деяких ознак може ускладнювати проведення аудиту.

Відповідно, аудити розділяють на кілька типів. Level of effort – це поверхневий аудит, який дозволяє зрозуміти, скільки потрібно вкласти ресурсів для того, щоб наш ресурс став доступний для будь-кого. Ризико-аудит – це дуже схожа ситуація, коли ми оцінюємо запуск ресурсу в якійсь країні, де є законодавчі обмеження. Наприклад, деякі компанії в Європейському Союзі заробляють просто шалені кошти, роблячи ось цей ризико-аудит. Його доволі важко і складно зробити самостійно. У третьому випадку – validation audit – аудит валідації, так званий. Це найбільш розповсюджений аудит, коли ми робимо якусь частину, покриваємо тестуванням за допомогою деяких інструментів. Ми подивимося далі – це або Axe Tool, або Wave Tool. І частину, можливо, це робить якийсь тестувальник руками. Це такий аудит.

Ну і деталізований аудит – це коли ми розбираємо повністю наш веб-сайт відповідно до однієї або двох версій стандарту, а також законодавчих актів країни, де буде запуск. Результатом з цього деталізованого аудиту буде такий величезний документ, і після того, як цей документ імплементовано, просто робиться регрес-аудит, який перевіряє, чи ми все зробили. Щоб було легше робити ці аудити, існує Accessibility Checkpoint. Я його виніс на окремий екран, ми подивимося на нього в подробицях. За допомогою цього Accessibility Checkpoint можна зробити Validation Audit. Ось, на сайті W3C є вбудований сайт останньої версії. Є окремий чекпоінт з пріоритетністю, і відповідно можна виставляти є основ по кожному з важливих пунктів. Ну і, до речі, є посилання, ви можете перейти на відповідний пункт і перевірити, чи відповідає ця історія вам, чи ні.

Так само проводиться аудит, і саме на цьому документі, ось у WebContent. Якщо ми говоримо про WebContent Accessibility Guidelines, базується робота майже всіх автономних інструментів перевірки, починаючи від Lighthouse, закінчуючи Axe Corridors. Повернемось до основного екрана. До того ж, існує кілька Accessibility API. Якщо ви хочете створити самостійний застосунок, який буде перевіряти доступність веб-сайту, або ви хочете автоматизувати бота для вашого ресурсу, є літерально 4-5 різних API. Важливо звернути увагу на перші два.

Один із них – Microsoft Active Accessibility. Він надає відкритий доступ до програмного коду. На клієнтській стороні можна абсолютно чітко і легко використовувати. Є вбудована інтеграція з Web Accessibility Guidelines API, тобто дослідження без бар'єрів. Єдиний момент, як завжди в Microsoft, все добре працює на продуктах Microsoft. Тому є iAccessible та iAccessible 2. Ці два стандарти фактично народилися від Apple, але потім їх було викинуто в Open Source Community і зараз їх підтримують Open Source, першої і другої версії. Вони дозволяють вам автоматизувати інтеграцію, поєднати автоматичні тести з вашим кодом і так далі.

Є декілька інших, я на них не буду зупинятися. Хоча iAccessible я імплементував за стосунком до того, що в мене на цьому ноутбуці, але якщо буде все нормально з інтернетом, я в Discord переконектуюся з сусідньої машини і покажу вам. Ну і є NX Accessibility протокол, NS Accessibility протокол, який є дуже цікавим, тому що він підтримується в Android, але, на жаль, він також відкритого коду, тобто це Open Source, але, на жаль, ним ніхто не займається. Тому він постійно застаріває і я його залишив на п'ятому місці.

UI Accessibility та ж історія, тобто це ще один із варіантів. Підемо ще подивимося ресурс WebAIM. Що таке WebAIM? Це ресурс, який розшифровується як Web Accessibility in Mind, тобто врахування доступності в мережі. Тут зібрані основні вимоги, тези, статті і роздуми щодо Web доступності. Якщо ви взагалі ніколи не працювали з доступністю, вам буде цікаво спробувати наш ресурс. Також WebAIM щороку перевіряє мільйони різних сайтів на Web доступність і складає загальний звіт. Тобто ви можете зайти на сайт, подивитися на певні тренінги, сертифікації і таке інше, і ось WebAIM Million Report.

Якщо перейти на цей репорт, то можна подивитись розкладку абсолютно по цим сайтам. Там вся конфірмація, майже під столом, бачите? Low Contrast, які помилки найбільше складаються, в якій пропорції відбувається. Доволі чітко можна подивитись на всі-всі проблеми, як вони розвиваються, що відбувається, в яких сферах. Government, тому що вони перші отримують по шапці, якщо немає Web доступності. Тому тут це йде в плюс, наприклад, кому Adult Content або Real Estate, найменш доступні контенти наразі. А також на v3.org є список всіх тулів, яких офіційно не можна назвати сертифікованими, це буде абсолютно не вірно сказати, що сертифіковані, але які рекомендує консорціум.

Ось величезний список, і до кінця я не буду доскролюватись, з посиланнями на кожен. І є насправді цілий фільтр, ви можете подивитись, що відповідає за Web Accessibility Guidelines, що відповідає за Screen Readers. Є окремі, ті, які підтримують Section 508 США, є які підтримують, є формат для читалок, тобто стандарт не Screen Readers, а стандарт фізичних, бук-рідерів, читалок. Аксес-веб, тобто по доступності з точки зору авторизації, і так далі, тобто мільйон-мільйон всього. Одним з рішень, яке варто подивитись, якщо ви вже зацікавилися з доступністю, якщо ви хочете перевірити свій ресурс, або зробити вибірку по доступним ресурсах, вам потрібно подивитись на AXCore або AXCore Tools. Декілька тулів, які у нас є для Web доступності. Чому ми кажемо AXCore Tools? Тому що це цілий інструментарій. AXCore – це API, AXCore Guidelines – це певний механізм, за допомогою якого ви можете конфігурувати свої кейдлайни. І якщо вам потрібно щось кастомне-кастомне, перевірити якусь вузько-нішову категорію, наприклад, це саме Web. Тобто ось, наприклад, є один із сайтів, який продавав спортивний одяг та спортивне взуття, і вони, це сайт США, один з найбільших сайтів, які займаються саме продажем спортивного одягу та взуття.

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

І Wave. Wave Tool. Ви можете або веб-мордашки прямо сюди зайти і там написати JS Framework Days, або FW Days, JavaScript Conference, відкрити пейджу і відразу подивитись, що відбувається з вашою сторінкою. Або ж ви можете використати їхній API. Єдиний момент, їхній API, воно платне, тобто у них, якщо просто подивитись, Validation – це один токен, якщо подивитись Detailed Report – це два токени, якщо Detailed Report з всіма селекторами, прямо скажу, в яких в основах, невірні проблеми у вашому сайті – це чотири токени. Коли ви реєструєтесь, вам дають 100 токенів, а далі вам потрібно їх купувати. Це не безкоштовно. В AXE є безкоштовні версії, які ви можете конфігурувати. Подивились трошки на інструменти, давайте подивимось трошки на рекомендації.

Перш за все, це, як не дивно звучить, на JavaScript Front-End конференції, це семантика. І ось ми будемо спиратись на поточний кейтлайн, це 2.1 або 2.2 версії, і з точки зору семантики, що ми маємо в 2.1 версії. Те, про що ми говорили. Є в нас рекомендації типу А, тобто додавання alt тексту для картини. Причому, зверніть увагу, що деякі тули знають і вміють перевіряти картинки на відповідність назві. Тобто якщо ви вкліпаєте в alt текст назву картинки, як мінімум отримаєте там попередження, що ви тим не сильно допомогли, тому що у вас картинка пік ще один, з alt текстом пік ще один. Тобто ось ці моменти. Але з 3.0 це вже не так актуально.

Дуже цікаво розібратися насправді з аудіо-відео, тому що дуже велика кількість рекомендацій саме для цих компонентів. Коли ми говоримо про найнижчий рівень, A, в ньому сказано, що наше аудіо і відео ні в якому разі не може бути самовідтворювальним. Тому що якщо є самовідтворювальне, і якщо воно ще, не дай Боже, відкривається з плейком, відповідно ми обмежуємо людей, і ми в деяких людей можемо викликати просто епілепсію. Ось, обов'язково в аудіо і відео повинні бути контролери, якими можна рухатись ліво-вправо, якими можна переключати, ставити на паузу. Ось, але якщо ми говоримо про AA, тобто ось цей рівень другий, який є золотою серединою, то тут в нас повинна бути можливість генерування субтитрів, а також зміни якості відображення. Ну і рівень AAA – це коли у вас є можливість додати мульти-жести, або взаємодіяти з вашим аудіо і відео за допомогою шрифту Брайля. Тобто це найвищий рівень. Ось це все про семантику. Тому коли ми з вами спілкуємось на певних конференціях, чи ми десь запиваємо і говоримо з вами про семантику, давайте не думайте, що це просто гівка замінить на те. Тобто це трошки більше.

Та ж історія з взаємодією, з навігацією. Тобто навігація – це не просто використання табі-індекса. Взагалі, якщо є можливість користуватись клавіатурою, це стрілки Escape, Enter і Backspace. Тобто ось ці п'ять клавіш. Це у нас найнижчий рівень. І до найнижчого рівня відноситься Focus Blue. До рівня AA в навігації, в рекомендаціях, ми маємо, наприклад, гарячі клавіші. Щоб за допомогою будь-якого із плагінів, їх є мільйони, ми тут не будемо, напевне, деталізовувати, щоб не робити рекламу будь-кому, ви могли дуже швидко гуляти по вашому контенту. Ну і AAA – це є доволі строгий гайдлайн щодо анімації миготіння.

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

Лейбли. Наступний наш такий кусочок – це лейбли. На лейблах або WAI-ARIA стандарт, частина його стандартів. Якщо у вас немає розмітки, ви можете за допомогою ролей, розказати нашим читачам і нашим допоміжним засобам, як взаємодіяти з вашим контентом. Для найнижчого рівня вам потрібно мати, звичайно, вірну ієрархію заголовків, мати один заголовок найвищого рівня, відповідну коректну структуру даних, ну і також усі коректні лейбли, щоб у вас не було невідомих елементів, у яких є контент.

А для АА у вас повинна бути наявність рекомендаційних лейблів, тобто є перелік рекомендаційних лейблів. Їх є 14 штук, за допомогою яких ви можете давати пояснення. Коли у вас людина зайшла всередину вашого елемента і вона використала клавішу, як правило, клавіша S (англійська), вона отримує додатковий матеріал. Можливо, це буде, наприклад, дуже часто, і потрібно це використовувати на кнопках, з якими ви взаємодієте, наприклад, купівля і оплата. Ви можете сказати, що ви тут купуєте і оплачуєте. Є можливість вибору оплати на наступній сторінці. Ви будете редіректувати. Ну і окремий біль, насправді, який є, це іконки.

Іконки як контент. Тобто це просто біда. Більшість розробників, які використовують ті чи інші гайдлайни, вони використовують іконки як картинки. В найкращому випадку там є підсвітка з текстом. Дивіться, тут розмір тексту, розмір іконок, використання іконок і заміна іконок на текст - це оцей рівень А. Текст в картинках, це коли у вас є, якщо це все є однією картинкою, то ось цей текст обов'язково має дублюватись в альтернативному тексті або в ролі зображення. Інакше ви не пройдете за AA. Ну і відповідно адаптивність також є частиною контенту за AA. Рекомендую вам додати можливість на вашому сайті заміни іконки на текст. Таким чином в нас працює, наприклад, у Gmail, ви можете в налаштуваннях замінити іконки на текст. Тоді ваші кнопки будуть називатись там "прочитані", "непрочитані". Насправді я так і зробив, тому що це набагато зручніше, ніж розпізнавати іконки.

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

Ми, як правило, вже споживаємо кольори, і ми вже кажемо, блін, тут UX-дизайнер їх не зробив так, як треба. І є Accessibility Cheat List. Що таке Accessibility Cheat List? Accessibility Cheat List – це також такий список параметрів, але, на жаль, у вайфреймі він не підтягнувся, але нічого. Але це постійно оновлюваний список рекомендацій і актуального стану без бар'єрності в вебі. Такий собі аналог УАЗП з точки зору безпеки. УАЗП 10. Та ж історія тут. Те, що повинно бути, required, має бути зараз, якщо ви хочете, щоб ваш ресурс був доступний, feel free. Ну, і ось, наприклад, веб. Давайте глянемо, в кінці, як Wave використовує наш сайт.

Ось наш сайт, всім знайомий JavaScript Framework Days. І ви можете, я загнав його сюди, прямо JS Conferences. Все доволі таки класно, насправді. 48 помилок, 24 на контрасті – це абсолютно нормальна ситуація. Тому що деякі з них попадають, бачите, Google Календар, наприклад, стріляє. Посилання лише на Telegram Chat, Discord Chat йому не подобаються. Адванси – це таке, жовтеньке виділення. Це, насправді, не є текстовою інформацією. І також він має 9 алертів. Може, ти нам їх покажеш? Бо я зараз у фреймі, так? Ви можете перейти і подивитися, що тут відбувається. Наприклад, MT-Link. Ну, тобто, нічого страшного не сталося. Чому MT-Link, якщо лінк там на картинці? Бачите, тут саме цікаво. Він парсить заголовки, і він показує, в якому режимі він буде по них йти. Що там зверху ось.

Ось він знайшов аж один. Далі він знайшов чотири елементи заголовочних. І далі ось аж два. І, насправді, що ми тут бачимо? Ми бачимо наступну ситуацію, що іти у програму наш рідер не буде. Він обійде, і він піде ось саме по цих посиланнях. Давайте ще глянемо. Ордеринг. В якому порядку ми будемо читати? Один. Події, вакансії, партнери, сторінки. Дев'ять. Вибір мови. Все чудово. Отримати квиток 11. Я вважаю, це взагалі успіх. Відразу можна купити квиток. Додати подію в календарі. Перейти на медіум. Зайти в телеграм, в діскорд-чат. І ось тут упасти в програму. Швиденько можна прийти в програму. Єдине, що він не прочитає заголовок програми. Ось цей заголовок. Потірялися. Але швидко знайде. Десь не зрозуміло, звідки з клоузінга прийде. Так само ви можете доволі швидко подивитися на будь-який сайт. Як він прийде. Так і я закінчив.