Новини

Активні проєкти

Оновлено 31 жовтня 2026 р.

У роботі

v3: Повний набір інструментів контролю якості

27 вересня 2026 р.

Презентація на DrupalCon Europe 2026

Основні нові функції

• Ядро тестів об'єднано із Sa11y. Новий спільно розроблений набір правил доповнює базові тести вмісту тестами для розробників, перевіркою контрасту та оцінкою читабельності.
• Підтримка багатьох мов
• Конструктор власних правил
• Інструменти обслуговування панелі керування
• Інструмент обходу сайту для додавання нових результатів.
• Дозволяє певним ролям закривати попередження по всьому сайту в окремих тестах (чи доступний цей PDF?).
• Розділена конфігурація: тестування та перегляд звітів за ролями — окремо для розробників і для авторів контенту.

І, мабуть, найважливіше для майбутнього проєкту:

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

v2: Закриття попереджень і звіти

2 березня 2023 р.

Два роки тому ми представили засіб перевірки доступності Editoria11y — готовий до використання плагін для Drupal, який миттєво й автоматично надавав авторам зворотний зв'язок і корисні поради щодо покращення вмісту.

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

Це спрацювало.

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

За межами університету реакцією стало справжнє захоплення:

Написання самодостатніх підказок

У підказках v1 ми застосували підхід «резюме та подробиці»: коротке пояснення проблеми та посилання на докладнішу інформацію.

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

Різниця між червоними попередженнями (безсумнівні проблеми) та жовтими попередженнями (можливі проблеми) виявилася незрозумілою, а часом і дратівливою.

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

Створення панелі керування

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

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

Огляд коду v2 для розробників

V2 — майже повністю переписана версія. Ось деякі з нових функцій:

• Відмова від залежності від jQuery дає змогу встановлювати інструмент на більшій кількості платформ і вдвічі підвищує продуктивність.
• Тепер засіб перевірки можна налаштувати так, щоб він аналізував кілька незалежних частин сторінки (наприклад, вміст статті та нижній колонтитул сторінки).
• Тепер засіб перевірки може тестувати елементи всередині тіньового DOM (shadow DOM), який використовують різні вебкомпоненти та бібліотеки JavaScript.
• Численні нові параметри спрощують інтеграцію з платформами, наприклад автоматичне ігнорування всіх проблем на певних сторінках для певних користувачів, якщо ті не відповідають за вміст цієї сторінки, але можуть захотіти переглядати результати на вимогу.
• Тепер засіб перевірки постачається з кількома базовими темами оформлення та параметрами для налаштування кольорів.
• Автоматизоване тестування допомагає запобігати регресіям у коді.

A11yTalks 2024

11 червня 2024 р.

Drupal GovCon 2023

27 жовтня 2023 р.

DrupalCamp NJ 2023

28 березня 2023 р.

v1: Вбудована довідка

11 березня 2021 р.

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

Звичні практики потрібно викорінювати:

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

Нові практики потрібно заохочувати:

• Зображенням потрібен альтернативний текст, змістовний у контексті
• Сторінкам потрібна справжня структура
• Посилання повинні мати змістовні назви

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

Уроки з історії правопису

Фаза 1: Звинувачуй автора

Від зорі писемної історії і до початку 1980-х за неправильно написане слово ми звинувачували автора. Саме автор мав навчитися писати без помилок.

Як можна було покращити свій правопис? Зараз це прозвучить знайомо:

1. Люди ходили на заняття — до наставників або в клас
2. Їм видавали для вивчення списки, настанови й словники, історія яких сягає давніх клинописних лексиконів, викарбуваних на глині.

Фаза 2: Звинувачуй словник

Але в 1980-х дещо змінилося — назвімо це «фазою 2 правопису». У найпопулярніших текстових редакторах з'явилася перевірка орфографії.

А що сталося з пошуком винних? Майже за одну ніч провина перейшла на інструмент:

• Не знаєте, як пишеться слово? Спробуйте вгадати й сподівайтеся, що збіг знайдеться. Якщо ні — звинувачуйте словник.
• Вжили справжнє слово, а словник його підкреслює, бо не знає? Побурчіть і вирішіть, ігнорувати підкреслення чи клацнути правою кнопкою й додати слово до словника.

Чи виправила перевірка орфографії всі наші помилки? Звісно, ні. Але вона допомогла. І перенесла значну частину тягаря та відповідальності з автора на машину.

Проте це ще був не кінець…

Фаза 3: Звинувачуй інструмент створення вмісту

Останні роки принесли ще один крок уперед: комп'ютери почали писати за нас:

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

І кого звинувачують, коли все йде шкереберть? Інструмент!

Агрегатори соцмереж просто обожнюють конфузні скриншоти в дусі «Я зовсім не це мав на увазі!».

Editoria11y — крок до фази 2

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

Однак є три проблеми:

1. Більшість із них — ручні інструменти. Автора контенту потрібно навчити ними користуватися, він має пам'ятати про їхнє існування під час написання й не забути запустити їх наприкінці. Ці три точки відмови разом залишають значну частину (більшість?) вмісту неперевіреною.
2. Вони позначають забагато. Вони вказують не лише на помилки, яких щойно припустився автор, а й на проблеми з кольором, спричинені дизайнером, технічні проблеми, спричинені розробником, структурні елементи з інформаційною метою тощо. Це підвищує вимоги до навчання: автори мають не лише розуміти інструмент, а й навчитися ігнорувати перелік хибнопозитивних результатів або цілком реальних проблем, за виправлення яких вони не відповідають сьогодні, під час написання саме цієї статті.
3. Автоматизовані інструменти зазвичай працюють за схемою «обійди сайт — зайди на панель керування». Знову ж таки, це припускає, що автора навчили заходити на панель керування і що він про це пам'ятатиме.

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

Автоматичність — це… непросто.

1. Автоматичні засоби перевірки мають бути ненав'язливими: якщо вони надто наполегливі, то переривають автора й дратують його. Якщо надто ввічливі — легко перетворюються на фоновий шум, який усі ігнорують.
2. Автоматичні засоби перевірки мають бути дуже продуктивними: якщо під час їхньої роботи сторінка смикається чи пригальмовує, автори незлюблять їх і вимкнуть.
3. Автоматичним засобам перевірки потрібні підказки, зрозумілі новачкам. Для багатьох авторів це буде перша зустріч із розміткою, структурою та мовою, які роблять вміст доступнішим. Попередження мають бути написані простою, нетехнічною мовою й містити практичні поради щодо покращення вмісту.

Тож ми почали з інструмента, найближчого до цих цілей: Sa11y від Toronto Metropolitan University. Ми взяли його архітектуру тестів і зручний для користувача підхід з інформаційною панеллю та підказками, а потім пів року адаптували інструмент: зробили так, щоб тести завжди запускалися автоматично, оптимізували продуктивність, удосконалили підказки й створили довгий перелік параметрів конфігурації, за допомогою яких розробник може швидко пристосувати його до будь-якої платформи.

Ось який вигляд він має сьогодні:

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

Станом на березень 2021 року це означає, що понад 400 вебсайтів Princeton автоматично перевіряють:

• Добру структуру документа
  • Пропущені рівні заголовків
  • Порожні заголовки
  • Дуже довгі заголовки
  • Підозріло короткі блоки цитат, які насправді можуть бути заголовками.
• Текстові альтернативи
  • Зображення без альтернативного тексту
  • Зображення, де альтернативним текстом є назва файлу
  • Зображення з дуже довгим альтернативним текстом
  • Альтернативний текст із зайвими словами на кшталт «зображення» або «фото»
  • Зображення в посиланнях, альтернативний текст яких, схоже, описує зображення, а не місце призначення посилання
  • Вбудовані візуалізації, яким зазвичай потрібна текстова альтернатива
• Змістовні посилання
  • Посилання без тексту
  • Посилання, назвою яких є назва файлу
  • Посилання лише із загальним текстом: «клацніть тут», «докладніше», «завантажити» тощо.
  • Посилання, що відкриваються в новому вікні без значка зовнішнього посилання
• Загальний контроль якості
  • Використання форматування списків замість зірочок, цифр і літер
  • ВЕЛИКА КІЛЬКІСТЬ ТЕКСТУ ВЕЛИКИМИ ЛІТЕРАМИ
  • Таблиці без заголовків і таблиці із заголовками документа («Заголовок 3») замість заголовків таблиці (<th>)
  • Посилання на PDF та інші документи з нагадуванням перевірити доступність завантажуваного файлу або надати альтернативний доступний формат
  • Вбудовані відео з нагадуванням додати приховані субтитри
  • Вбудоване аудіо з нагадуванням надати текстову розшифровку
  • Вбудовані дописи із соцмереж з нагадуванням надати елементи alt

Ми випустили бібліотеку JavaScript для спільноти, створили готову інтеграцію з Drupal і розпочали роботу над готовою інтеграцією з WordPress.

На шляху до фази 3: доступність за замовчуванням

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

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

• Переосмислення доступних варіантів. Наприклад: якщо ми постійно просимо користувачів не вирівнювати текст по ширині у вебі, чи не час прибрати кнопку «Вирівняти по ширині»?
• Переосмислення стандартних параметрів. Наприклад: стандартна таблиця в більшості систем керування вмістом не має заголовків. Саме користувач має знати, що треба клацнути «Властивості» й додати функції доступності; можливо, час змінити це на протилежне?
• Роздуми про предиктивне форматування та «підказки під час роботи». Якщо користувач робить жирним цілий рядок, чи можемо ми запропонувати перетворити його на заголовок? Якщо користувач вибирає заголовок, чи можемо ми вгадати, які рівні заголовків йому потрібні, а не давати шість варіантів? Чи можемо ми надавати навчання саме вчасно для складних понять?