Новини

Активни проекти

Последна актуализация: 31 октомври 2026 г.

В процес на работа

v3: Пълен пакет за гарантиране на качеството

27 септември 2026 г.

Представяне на DrupalCon Europe 2026

Основни нови функции

• Обединено тестово ядро със Sa11y. Новият, съвместно разработен набор от правила добавя тестове за разработчици, проверка на контраста и оценка на четимостта към основния набор от тестове за съдържание.
• Поддръжка на множество езици
• Конструктор за персонализирани проверки
• Инструменти за поддръжка на таблото
• Инструмент за обхождане на сайта, който добавя нови резултати.
• За определени тестове (достъпен ли е този PDF?) позволява на определени роли да скриват сигнали за целия сайт.
• Разделена конфигурация: тестване и изгледи на отчети според ролята – за разработчици и за автори на съдържание.

И може би най-важното за бъдещето на проекта:

• Получена субсидия за създаването на тази спонсорираща организация, която да подпомага настоящите потребители и да финансира работата по идеи за бъдещето на проекта.

v2: Скриване на сигнали и отчети

2 март 2023 г.

Преди две години представихме инструмента за проверка на достъпността Editoria11y като готов за употреба плъгин за сайтове с Drupal, който дава на авторите автоматична и незабавна обратна връзка с полезни съвети за подобряване на съдържанието.

Смятахме, че така ще запълним празнина. Всички съществуващи варианти изискваха обучение и прилежна употреба, за да са полезни, а опитът ни беше показал, че да обучаваш и наблюдаваш хиляди автори на съдържание в голяма организация не е ефективен начин за справяне с проблема. Бяхме убедени, че за да успее, една програма трябва да е силно автоматизирана и да предлага учтиво „обучение точно навреме“ на авторите, когато открие често срещани грешки.

И се получи.

В Princeton това до голяма степен обърна посоката на комуникацията ми. На платформите, където беше инсталиран, преминахме от изпращане на еднообразни имейли до авторите на съдържание с молби за alt текст и по-добри връзки или заглавия към получаване на въпроси от авторите как да подобрят текстовете си, за да не бъдат маркирани толкова често.

Извън университета реакцията беше ликуване:

Писане на самостоятелни подсказки

При подсказките във v1 следвахме подхода „резюме и подробности“: кратко обяснение на проблема и връзка за повече подробности.

Това беше подобрение спрямо инструментите, писани за разработчици: подсказките бяха кратки и ясни. Но решението към какво да сочи връзката винаги беше проблем. Няколко потребители от държавната администрация и висшето образование изпитваха нужда да променят подсказките, за да премахнат връзките към документацията на Princeton, а това им създаваше допълнителна работа. Затова пренаписахме подсказките по подразбиране така, че да са самостоятелни, с вградени примери.

Разликата между червените сигнали (безспорни проблеми) и жълтите предупреждения (възможни проблеми) се оказа объркваща, а понякога и дразнеща.

Затова превърнахме жълтите предупреждения в „ръчни проверки“, за да стане ясно какво означават, и добавихме бутони, с които авторите да скриват сигнали. „Игнорираните“ сигнали се скриват само за човека, който е щракнал бутона, а сигналите, „маркирани като OK“, се скриват за всички редактори на сайта. Администраторите на сайта могат да решат кой има право да прави всяко от двете.

Създаване на табло

Собствениците на сайтове често се оплакваха, че инструментът се справя отлично с откриването на проблеми из целия сайт, но няма как да се види обобщен отчет.

Пренаписаната версия добавя възможност резултатите да се синхронизират обратно в базата данни на сайта. Собствениците на сайтове вече могат да разглеждат резултатите по страница или по проблем, да виждат кои проблеми са били игнорирани или маркирани като OK – и да ги възстановяват, ако не са съгласни!

Преглед на кода на V2 за разработчици

V2 беше почти изцяло пренаписана. Сред новите функции са:

• Премахването на зависимостта от jQuery позволява инсталиране на повече платформи и удвоява производителността.
• Инструментът вече може да се конфигурира да проверява няколко независими части на страницата (например съдържанието на статията и долния колонтитул на страницата).
• Инструментът вече може да тества елементи в shadow DOM, който се използва от различни уеб компоненти и JavaScript библиотеки.
• Многобройни нови параметри улесняват интеграцията с платформи – например автоматично игнориране на всички проблеми на определени страници за определени потребители, ако те не отговарят за съдържанието на тази страница, но все пак искат да виждат резултатите при поискване.
• Инструментът вече се предлага с няколко базови теми и параметри за персонализиране на цветовете.
• Автоматизираното тестване помага да се предотвратят регресии в кода.

A11yTalks 2024

11 юни 2024 г.

Drupal GovCon 2023

27 октомври 2023 г.

DrupalCamp NJ 2023

28 март 2023 г.

v1: Вградена помощ

11 март 2021 г.

Създаването на силно достъпно уеб съдържание е сложно и обикновено започва с много обучения.

Трябва да отучваме хората от познати практики:

• Таблиците не бива да се използват за създаване на фалшиви колони
• Основният текст не бива да се центрира или подравнява двустранно
• Не бива да се разчита само на визуално форматиране (дебелина и размер на шрифта), за да се предава смисъл на потребителите, които може да слушат съдържанието или да го разглеждат в „режим за четене“

Трябва да насърчаваме нови практики:

• Изображенията се нуждаят от алтернативен текст, смислен в контекста
• Страниците се нуждаят от истинска структура
• Връзките трябва да имат смислен текст

Разбира се, част от обученията ни се провеждат, защото преподаваме нови понятия, но в даден момент трябва да се запитаме: каква част от нуждата от нови умения идва от това, че понятията са нови, и каква идва от това, че въвеждаме нови очаквания, без да обновяваме инструментите си? Това, че нещо е ново, не означава, че не може да бъде интуитивно.

Уроци от историята на правописа

Фаза 1: Обвинявай автора

От зората на писаната история до началото на 80-те години на XX век обвинявахме автора, когато сбърка дума. Отговорността беше на автора да се научи да пише правилно.

Как човек подобряваше правописа си? Това ще ви прозвучи познато:

1. Ходеше на обучения – при частни учители или в класна стая
2. Получаваше списъци, насоки и речници за изучаване – традиция, започнала още с древните клинописни лексикони, издълбани в глина.

Фаза 2: Обвинявай речника

Но през 80-те нещо се промени: да го наречем „правопис, фаза 2“. Най-популярните програми за текстообработка въведоха проверка на правописа.

А какво стана с търсенето на виновен? Почти за една нощ вината се прехвърли върху инструмента:

• Не знаете как се пише дадена дума? Опитайте наслуки и се надявайте да се намери съвпадение. Ако не се намери, обвинете речника.
• Използвате истинска дума, която речникът подчертава, защото не я познава? Помърморете си и решете дали да пренебрегнете подчертаването, или да щракнете с десния бутон и да добавите думата в речника.

Оправи ли проверката на правописа целия ни правопис? Разбира се, че не. Но помогна. И прехвърли голяма част от тежестта и отговорността от автора върху машината.

Това обаче не беше краят…

Фаза 3: Обвинявай инструмента за писане

Последните години донесоха още една стъпка напред: компютрите започнаха да пишат вместо нас:

• Предсказващите алгоритми се опитват да отгатнат следващата дума, следващата фраза, а може би и цял отговор на текстово съобщение.
• Инструментите за автоматично форматиране се опитват да превръщат звездички, цифри и букви в списъци, кратките кодове – в специални символи и емоджи и т.н.
• Инструментите за диктовка се опитват да разпознават смисъла, за да избират между омоними.

А кой е виновен, когато всичко това се разпадне? Инструментът!

Агрегаторите в социалните мрежи обожават излагащите екранни снимки от типа „Нямах това предвид!“.

Editoria11y е стъпка към фаза 2

В обученията си говорим много за тестване и представяме няколко доста добри инструмента за тестване. Никой от тях не може да улови всичко: неща като „да не се обясняват понятия чрез препратки към цвят или разположение в пространството“ трябва да се проверяват от човек; обикновено инструментите улавят малко под половината от реалните проблеми, които може да има един сайт. Но те се справят много добре с улавянето на много чести грешки в редакционното съдържание.

Има обаче три проблема:

1. Повечето са ръчни инструменти. Създателят на съдържание трябва да е бил научен да ги използва, да помни, че съществуват, докато пише, и да не забрави да ги стартира, когато приключи. Тези три слаби звена се съюзяват и оставят голяма част (по-голямата?) от съдържанието непроверена.
2. Маркират твърде много. Отбелязват не само грешките, които авторът току-що е направил, но и проблемите с цветовете, допуснати от дизайнера, техническите проблеми, допуснати от разработчика, структурни елементи с информационна цел и т.н. Това вдига летвата за обученията: авторите трябва не само да разбират инструмента, но и да бъдат научени да пренебрегват цял списък с фалшиви положителни резултати или съвсем реални проблеми, които не са тяхна отговорност да оправят днес, докато пишат точно тази статия.
3. Автоматизираните инструменти обикновено следват модела „обходи сайта, посети таблото“. Отново: това предполага, че авторът е обучен да посещава таблото и ще се сети да го направи.

Затова Princeton се зае да създаде нещо ново: интегриран в сайта, автоматичен инструмент за проверка, който да следи само за чести редакционни грешки.

С автоматичното е… трудно.

1. Автоматичните инструменти за проверка трябва да са ненатрапчиви: ако са твърде настойчиви, прекъсват и дразнят автора. Ако са твърде учтиви, лесно се превръщат във фонов шум, който никой не забелязва.
2. Автоматичните инструменти за проверка трябва да са изключително бързи: ако страницата потрепва или се забавя, докато работят, авторите ще ги намразят и ще ги изключат.
3. Автоматичните инструменти за проверка се нуждаят от подсказки, разбираеми за начинаещи. За много автори това ще е първият път, в който чуват за таговете, структурата и езика, които правят съдържанието им по-достъпно. Сигналите трябва да са написани на прост, нетехнически език и да дават практични съвети за подобряване на съдържанието.

Затова започнахме с най-близкия до тези цели инструмент, който успяхме да намерим: Sa11y от Toronto Metropolitan University. Взехме неговата архитектура на тестовете и удобния за потребителя подход с информационен панел и подсказки и посветихме половин година на адаптирането му: направихме така, че тестовете винаги да се изпълняват автоматично, оптимизирахме производителността му, шлифовахме подсказките и създадохме дълъг списък с опции за конфигуриране, с които разработчик може бързо да го пригоди към всяка платформа.

Ето как изглежда днес:

Когато авторът е влязъл в сайта си, превключвателят на Editoria11y показва броя и вида на проблемите (без проблеми, нужни са ръчни проверки, открити са вероятни проблеми) на всяка страница. С едно щракване той може да покаже вграденото маркиране и подсказките. Ако грешката е нова, защото гледа страница, която току-що е редактирал, панелът се отваря автоматично.

Към март 2021 г. това означава, че над 400 сайта на Princeton автоматично проверяват за:

• Добра структура на документа
  • Пропуснати нива на заглавия
  • Празни заглавия
  • Много дълги заглавия
  • Подозрително кратки цитатни блокове, които всъщност може да са заглавия.
• Текстови алтернативи
  • Изображения без alt текст
  • Изображения с файлово име като alt текст
  • Изображения с много дълъг alt текст
  • Alt текст с излишни думи като „изображение на“ или „снимка на“
  • Изображения във връзки с alt текст, който изглежда описва изображението, а не целта на връзката
  • Вградени визуализации, които обикновено изискват текстова алтернатива
• Смислени връзки
  • Връзки без текст
  • Връзки, чийто текст е файлово име
  • Връзки, чийто текст е само общ: „щракнете тук“, „научете повече“, „изтеглете“ и др.
  • Връзки, които се отварят в нов прозорец без икона за външна връзка
• Общ контрол на качеството
  • Проверка дали се използва форматиране на списъци, а не звездички, цифри и букви
  • ГОЛЕМИ КОЛИЧЕСТВА ТЕКСТ, НАПИСАН С CAPS LOCK
  • Таблици без заглавни клетки и таблици със заглавия на документа („Заглавие 3“) вместо заглавни клетки на таблицата (<th>)
  • Връзки към PDF и други документи с напомняне на потребителя да провери достъпността на изтегляния файл или да предостави алтернативен, достъпен формат
  • Вградени видеа с напомняне на потребителя да добави субтитри
  • Вградено аудио с напомняне на потребителя да предостави транскрипция
  • Вградено съдържание от социални мрежи с напомняне на потребителя да добави alt елементи

Пуснахме JavaScript библиотеката за общността, създадохме готова за употреба интеграция с Drupal и започнахме работа по такава за WordPress.

Към фаза 3: Достъпност по подразбиране

В много отношения Editoria11y е временно решение. Повечето грешки, които улавя, са допуснати, защото поставихме нови очаквания пред авторите на съдържание („структурирайте съдържанието си с подходящи тагове“), но им дадохме инструменти, които насърчаваха обратното.

Пътят напред е създаването на достъпно съдържание да стане по-лесно и възможно най-автоматично. Как ще изглежда това, още не е ясно, но вероятно ще включва неща като:

• Преосмисляне на наличните възможности. Например: ако непрекъснато казваме на потребителите да не подравняват текста двустранно в уеб, не е ли време да пенсионираме бутона „двустранно подравняване“?
• Преосмисляне на настройките по подразбиране. Например: таблицата по подразбиране в повечето системи за управление на съдържание няма заглавни клетки. От потребителя се очаква да знае, че трябва да щракне върху „свойства“ и да добави функциите за достъпност; може би е време това да се обърне?
• Обмисляне на предсказващо форматиране и „подсказки в хода на работата“. Ако потребител направи цял ред получер, можем ли да му предложим да го превърне в заглавие? Ако потребител отиде да избере заглавие, можем ли да отгатнем какви нива на заглавия би искал, вместо да му даваме шест възможности? Можем ли да предложим обучение точно навреме за трудните понятия?