21 липня Кабмін прийняв постанову № 757, що передбачає нові вимоги щодо доступності урядових сайтів і мобільних додатків для маломобільних користувачів. Дмитро Попов, засновник та CEO компанії Access Lab, у колонці для AIN.UA розповідає, про що йдеться у новому урядовому документі, як перевірити та адаптувати сайт чи додаток на предмет інклюзивності й навіщо це приватним бізнесам.
Про що постанова № 757
Відповідно до постанови під довгою назвою «Деякі питання доступності інформаційно-комунікаційних систем та документів в електронній формі», «усі сайти, мобільні додатки та електронні документи органів виконавчої влади, підприємств, установ та організацій, що належать до сфери їх управління, Ради міністрів Автономної Республіки Крим, обласних, Київської та Севастопольської міських державних адміністрацій повинні відповідати вимогам ДСТУ EN 301 549:2022».
Якщо коротко і простими словами — усі вони повинні бути доступними для людей з інвалідністю, зокрема для людей з порушеннями зору, слуху, руховими та когнітивними порушеннями, а також різними комбінаціями цих порушень.
Важливо, що тут не йдеться про створення окремих версій для людей з порушеннями зору чи інших категорій користувачів — вимоги стосуються основної версії сайту чи додатку. Подібні правила щодо безбар’єрності існували й раніше, до цієї постанови, однак вона апелює до нового стандарту ДСТУ, який розширює вимоги та розповсюджує їх на більшу кількість технологій.
Що нового у постанові та що таке WCAG
Згідно з Постановою № 3 від 2002 року, сайти повинні були відповідати ДСТУ ISO/IEC 40500:2015, в основі якого — Настанови з доступності вебвмісту WCAG (Web Content Accessibility Guidelines) 2.0. Стандарт охоплював лише сайти й не застосовувався до мобільних додатків.
Актуальна постанова апелює до нового стандарту ДСТУ EN 301 549:2022, який покликається на новішу версію рекомендацій WCAG 2.1 та охоплює і мобільні додатки, і електронні документи, а також містить додаткові вимоги щодо біометрії та деяких функцій зв’язку.
Рекомендації WCAG 2.1 побудовані на 4 принципах: придатність для сприйняття, керування, зрозумілість і надійність. Кожен з них має критерії успішності — за ними можна перевірити, наскільки сайт чи додаток відповідають принципам інклюзивності. Є три рівні відповідності: A — найнижчий, AA — середній і AAA — найвищий. Обов’язковим відповідно до ДСТУ є рівень AA.
Технічні вимоги до сайтів і додатків
Ось перелік основних обов’язкових вимог, що відтепер повинні бути інтегровані на сайтах та у додатках:
1. Потрібно додавати текстову альтернативу для будь-якого нетекстового контенту, щоб зробити його доступним для незрячих і людей з порушенням слуху. Тобто:
- альтернативний текст для зображень — описати, що зображено та прописати цей текст в атрибуті alt;
- текстові мітки для всіх елементів керування — кнопок, перемикачів тощо, якщо вони замість текстових назв містять іконки;
- альтернативу для графічної CAPTCHA;
- субтитри для відео;
- транскрипцію для аудіо, наприклад, для подкастів.
2. Увесь інтерфейс повинен бути доступним для керування з клавіатури, щоб це могли робити незрячі люди та люди з руховими порушеннями, котрі не можуть користуватися мишкою. Це стосується також пристроїв з сенсорними екранами. Доступність у цьому випадку означає, що:
- усі дії можна виконати на клавіатурі без мишки. Це не значить, що потрібно створювати клавіатурні команди, а достатньо лише підтримувати навігацію за допомогою клавіш tab, enter, клавіш зі стрілками тощо, які вже підтримуються на рівні операційної системи;
- індикатор фокуса клавіатури відображається, аби користувач розумів, на чому сфокусувався. Це не стосується мобільних додатків, адже там індикатор фокуса надається скрінрідером;
- усі складні компоненти, як-от модальні вікна, каруселі, панелі вкладок також доступні для керування з клавіатури.
3. Необхідно дотримуватися мінімального контрасту тексту відносно тла, щоб текст був доступним для людей з порушенням зору.
Мінімальний контраст для звичайного тексту — 4.5:1, а для великого чи жирного — 3:1. Перевірити пару кольорів можна за допомогою Deque Color Contrast Analyzer або аналогічних сервісів.
4. Збільшення тексту треба підтримувати мінімум до 200%, щоб користувачі з порушеннями зору могли легко прочитати вміст. Це не означає, що потрібно додавати віджет на сайт для збільшення тексту. Користувачі можуть це робити у браузері клавішами CTRL і «+». Розробникам потрібно переконатися, що при збільшенні не з’являється горизонтальна прокрутка і частина контенту не зникає.
5. Прописувати назви кольору — наприклад, не може бути вказано «натисніть на зелену кнопку», оскільки це недоступно для людей з дальтонізмом. На додачу до кольору потрібно використовувати текстове позначення.
6. У формах для кожного поля надавати змістовну текстову мітку та, якщо потрібно, інструкцію щодо формату введення, щоб мітки й інструкції прочитав скрінрідер, а призначення полів було зрозуміло всім користувачам.
7. Необхідно створювати правильну семантичну розмітку, щоб контент точно розпізнавався скрінрідерами. Це означає, що всі теги повинні використовуватися за призначенням — заголовки позначатися <h1>-<h6>, кнопки тегом <button> і тому подібне.
8. Біометрична авторизація чи керування не повинні залежати від однієї біологічної характеристики. Тобто якщо використовується авторизація по відбитку пальця, то слід додати авторизацію за неподібною біологічною характеристикою: сітківкою ока, голосом, обличчям, або небіометричним методом — наприклад, паролем.
Винятки для певних типів контенту
Вимоги нової постанови не застосовуються до:
- відео- та аудіозаписів, опублікованих до набрання чинності цієї постанови;
- відео- та аудіовізуальної інформації, що транслюється у прямому ефірі, крім випадків, коли відбувається інформування та оповіщення населення про воєнний і надзвичайний стан, повітряну та іншу тривогу, а також про інші випадки, від швидкості поширення інформації про які залежить життя та здоров’я населення;
- онлайн-карт і картографічних інструментів, якщо основна інформація надається доступним способом із застосуванням цифрових технологій.
Навіщо бізнесу дотримуватися вимог для урядових сайтів
Якщо ваша компанія розробляє сайти чи додатки для державних установ, що належать до сфери управління органів виконавчої влади, ви зобов’язані дотримуватися цих вимог.
Однак, навіть якщо ви не маєте жодного стосунку до держсектору, вам все одно варто їх дотримуватися, адже в ЄС, починаючи з 2025 року, подібні вимоги застосовуються і до приватного сектору. Є велика імовірність, що найближчим часом в Україні також приймуть такі норми.
Як перевірити доступність сайту
Ви можете почати з автоматичного сканування за допомогою плагінів Axe DevTools, Accessibility Insights.
Або можете скористатися ботом Access Lab для Telegram — Access Bot. Він дозволяє просканувати до 5 сторінок одночасно та увімкнути моніторинг сайту для відстеження змін доступності. А головне – всі рекомендації бот надає українською мовою.
Однак враховуйте, що автоматичне сканування виявляє лише до 30-40% помилок. Щоб переконатися, що сайт відповідає всім критеріям доступності, необхідно тестувати сайт вручну — зокрема з допомогою скрінрідерів, тобто спеціального програмного забезпечення, яке використовують незрячі люди, бажано із залученням людей з інвалідністю.
Опанування скрінрідерів і, загалом, якісне ручне тестування доступності — це непростий і кропіткий процес. Ми в Access Lab з цим допомагаємо — не лише проводимо аудити, а й вчимо тестувати самостійно. Окрім цього, зараз працюємо над розробкою зручного інструменту для ручного тестування.
Для державних установ консультації Access Lab безплатні. Отримати їх, а також відповіді на запитання можна, написавши нам на пошту: [email protected]. Якщо ж у вас приватний бізнес, і ви тільки починаєте розробляти сайт чи додаток, вам варто врахувати усі формати доступності на старті — це зекономить компанії час і кошти.
