Извадката е 50 Figma файла от 28 продуктови екипа в областите SaaS, търговия на дребно, финтех, обществен сектор и edtech. Договорихме достъп само за преглед на принципа на неприписване: нищо в тази статия не идентифицира марка, екип или дизайнер. Файловете бяха избрани да отразяват какво инженерът реално би получил при предаване — не излъскано казусно проучване от портфолио сайт — затова помолихме всеки екип да сподели файла, от който е реализирана най-новата функция, а не файла, с който се гордее най-много. Дванадесет от файловете бяха от екипи с отделена практика за дизайн система; останалите 38 бяха файлове на продуктово ниво, които внасяха системна библиотека или си правеха собствени компоненти на място.

Обходихме всеки файл, търсейки пет свойства за достъпност: дизайн на състоянието на фокус на всеки интерактивен компонент, анотации с алтернативен текст на всяко изображение или недекоративна икона, документация на реда на четене в целия оформление, обработка на предпочитанието за движение за всеки анимиран или преходен елемент и спецификация на контраста в тъмен режим за всеки компонент, доставен и за светла, и за тъмна тема. За всяко свойство файлът получаваше „документиран“ само ако компетентен инженер можеше да реализира дизайна, без сам да измисля отговора. „Споменато в лепкава бележка“ не се броеше. „Шестнадесетичен код, посочен в едно-единствено състояние на задържане“ не се броеше. Летвата беше: решението в ли е във файла във форма, по която инженерът може да действа, без да пита?

Водещата констатация е, че предаването, по тази летва, изпуска решенията за достъпност далеч по-често, отколкото ги включва. Дизайнът на състоянието на фокус се появи на прибл. 40% от интерактивните компоненти в целия корпус. Анотации с алтернативен текст се появиха на приблизително 22% от изображенията, които се нуждаеха от тях. Редът на четене беше изрично документиран в 16% от файловете. Предпочитанията за движение бяха адресирани в 10%. Контрастът в тъмен режим — за 31-те файла, които доставиха и двете теми — беше специфициран за 30% от компонентите. Разликата не е в едно отделно свойство. Тя е и в петте, а инженерът е оставен да я затваря по едно субективно решение наведнъж.

От приблизително 1800-те интерактивни компонента, разгледани в целия корпус — бутони, връзки, полета за въвеждане, отметки, превключватели, табове, комбобоксове, елементи от менюта, картички-като-бутон, всичко, до което потребител на клавиатура може да достигне — приблизително 40% доставиха проектирано състояние на фокус. Останалите 60% доставиха състояние по подразбиране, активно и при задържане, и спряха дотам. Инженерът, който изгражда компонента, избира контур на фокуса в момента на реализацията, обикновено като копира браузърния default, обикновено без да провери дали default-ът има контраст 3:1 спрямо повърхността на компонента и в светлата, и в тъмната тема, които файлът доставя.

Как изглежда „липса на дизайн на състоянието на фокус“ на практика? Изглежда като компонент-бутон с три варианта на платното — покой, задържане, натиснат — и без четвърти вариант. Изглежда като поле за въвеждане със стилизирана рамка и без втори стил на рамката за фокусираното състояние. Изглежда като примитив за отметка с пръстен на фокуса само на варианта в покой, като инженерът е оставен да гадае дали същият пръстен трябва да се появи на варианта „отметнат“ или „неопределен“. Моделът се повтаря през компонентите, през екипите, през секторите. Това е единичната най-голяма разлика в достъпността в корпуса и единичната най-лесна за вграждане в дизайна.

Екипите, които проектираха състоянията на фокус добре, имаха едно от две неща в своя полза. Първото беше изрично правило на дизайн системата: всеки интерактивен компонент трябва да достави вариант, чието име започва с focus-, и компонентът не се пуска в библиотеката, докато този вариант не съществува. Второто беше свойство на компонент в Figma на име state с focus, focus-visible и focus-within като изброени стойности, така че браузърът на компоненти на файла извежда липсващите варианти визуално. Екипите без едно от тези две скелета оставяха състоянието на фокус на инженера приблизително девет пъти от десет.

От файловете в корпуса, които включваха съдържателни изображения — продуктова фотография, hero илюстрации, бутони само с икони, инфографични фигури — 78% нямаха анотации с алтернативен текст на слоевете с изображения. Изображението беше поставено, оразмерено и стилизирано; текстовият еквивалент, който инженерът трябваше да постави върху изобразения <img>, не беше във файла. Осем от 50-те файла имаха алтернативен текст на някои изображения, но не на всички, обикновено с анотирана hero илюстрация и празни съдържателни изображения в тялото. Три файла имаха алтернативен текст на всяко изображение. Инженерът, в 47 от 50 файла, трябваше да измисли алтернативния текст — а на практика често го наследяваше от името на файла, от подписа на фигурата или от какъвто низ пасваше на визуалния ритъм.

Разликата е структурна за примитива за изображения на Figma. Няма родно свойство „alt“ на запълване с изображение или слой с изображение; алтернативният текст трябва да се носи като име на слой, коментар, лепкава бележка, отделен спецификационен документ или поле, добавено от плъгин. Нито едно от тях не преминава през inspect панела по подразбиране, така че инженерът, който чете файла в изгледа inspect, не вижда алтернативния текст, дори ако дизайнерът го е написал другаде. Екипите, които затвориха разликата последователно, използваха един от три заобиколни подхода: полета за алтернативен текст, управлявани от плъгин, на всеки вариант на изображение, документирана конвенция, че името на слоя е алтернативният текст, или отделна електронна таблица с алтернативен текст, обвързана с имената на файловете на изображенията, доставяна заедно с файла.

Бутоните само с икони бяха под-провал в рамките на този режим на провал. В 41 от 50 файла бутоните-икони — лупата за търсене, хамбургер менюто, X за затваряне, стрелката за споделяне — нямаха анотация с достъпно име, оставяйки инженера да напише aria-label=“Search” от визуалния контекст без потвърждение, че „Search“ е правилната дума в гласа на марката (беше ли „Find“? беше ли „Lookup“? беше ли нищо, защото бутонът отваря панел, означен другаде?). Именуването на иконите е точно онзи вид микрокопирайтинг решение, което печели от писалката на дизайнера, и точно онзи вид, който предаването губи.

Останалите три свойства имаха отчетливи форми на провал. Редът на четене — редът, в който екранен четец ще разказва страницата, който в съвременните адаптивни оформления вече не е гарантирано да съвпада с визуалния ред отгоре надолу — беше документиран в 16% от файловете. Документацията, където съществуваше, обикновено беше номериран наслагващ слой на платното (1, 2, 3 …), добавен с плъгин. Останалите 84% оставяха инженера да съпостави реда на четене от DOM реда, който той случайно е написал, който при CSS Grid оформление с изрично разполагане по редове и колони може да се разминава с визуалното оформление с цяла колона.

Предпочитанията за движение се справиха най-зле. Десет процента от файловете изобщо споменаваха prefers-reduced-motion. Останалите 90% специфицираха анимации и преходи — влизания на модални прозорци, разгъвания на акордеони, плъзгания на snackbar-и, преходи между страници — без да специфицират какво трябва да прави същият компонент, когато потребителят е активирал намалено движение. Инженерът или изграждаше случая с намалено движение в момента на реализацията (често без визуална референция), или доставяше същата анимация на всички, което е по подразбиране и което нарушава 2.3.3 Animation from Interactions за потребители, които задават предпочитанието.

Контрастът в тъмен режим беше специфициран за 30% от компонентите във файлове, които доставиха и двете теми. Останалите 70% специфицираха контраста на светлата тема — обикновено с анотация от Stark или проверка на контраста във файла — и след това пускаха тъмната тема с обърната по шестнадесетичен код палитра, оставяйки инженера да провери дали обърнатата двойка все още покрива 4.5:1 на основния текст и 3:1 на елементите от UI. В около една пета от 31-те файла с две теми поне един компонент падна под прага на контраста в тъмната тема, защото тъмната повърхност и тъмният текст бяха настроени и за двете спрямо математиката на контраста на светлата тема, а не на тъмната.

Двата плъгина, които се появяват най-често в корпуса, са Stark и Able. И двата са зрели, и двата са с добра репутация, и двата доставят функции, които затварят няколко от разликите, документирани по-горе. Stark добавя проверка на контраста, наслагване на реда на фокуса, преглед с намалено движение и поле за анотация с алтернативен текст на слоевете с изображения. Able добавя инспектор на цветовия контраст, наслагване със симулация на зрението и проверка на размера на целта за докосване. Който и да е от двата плъгина, използван последователно в целия файл, би извел този файл от долната четвъртина на корпуса.

„Използван последователно“ е оперативната фраза. В 50-те файла Stark беше инсталиран и видимо използван в 18, а Able — в 11. Във файловете, където плъгинът беше използван, той обикновено беше използван на hero компонента и основния CTA — компонентите, които най-вероятно са на платното, когато дизайнерът отвори плъгина — и само спорадично другаде. Шест файла използваха Stark при глобално преминаване; един използваше Able при глобално преминаване. Моделът е: плъгините съществуват, дизайнерите знаят за тях, биват издърпвани за точкови проверки, а след това точковата проверка спира при компонентите, които дизайнерът случайно е разглеждал, когато плъгинът е бил отворен.

Двата екипа, които затвориха одита по използване на плъгини, направиха едно нещо различно: пуснаха функцията за одит на плъгина на всяка страница от файла като стъпка-гейт за пускане, преди файлът да бъде споделен с инженерството. Одитът се изпълни във файла, произведе доклад и докладът трябваше да е празен (или изключенията му — документирани), преди файлът да премине от „в дизайн“ към „готов за инженерство“. Това е плъгин-като-работен-процес, а не плъгин-като-точкова-проверка, и това е разликата между 80% и 20% покритие в нашата извадка.

Одитът произвежда чеклист и договор. Чеклистът е това, което дизайнерът трябва да може да отметне, преди файлът да бъде споделен с инженерството. Договорът е формата на дизайн токените, които пътуват заедно с файла, така че инженерът да съпостави Figma променливите с CSS custom properties, без да измисля междинни стойности. И двата са кратки нарочно: всяка точка в чеклиста е свойство, което одитът измери, а всеки токен в договора е стойност, която затвори разлика в корпуса.

Одитът на 50-те файла завършва с проста констатация. Предаването проваля достъпността не защото дизайнерите не ги е грижа и не защото инженерите не ги е грижа, а защото файлът — Figma файлът, единственият артефакт, който всяка страна чете — не носи решенията за достъпност като първокласни свойства. Състояния на фокус, алтернативен текст, ред на четене, предпочитания за движение, контраст в тъмен режим: всяко от тях е дизайнерско решение, всяко принадлежи във файла, всяко в момента е някъде другаде. В лепкава бележка, в съобщение в Slack, в отделна електронна таблица, в главата на инженера в 16 ч. в петък.

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

По-дълбоката констатация е, че екипите с дизайн система вече правят това приблизително с двойно по-висока честота от продуктовите екипи. Подемът, който осигуряват екипите с дизайн система, е точно подемът, който дисциплината на изграждането на система налага: компонентите са именувани, свойствата са изброени, вариантите са видими, токените са изрични. Внасянето на същата дисциплина във файловете на продуктово ниво — дори без пълна дизайн система отдолу — затваря по-голямата част от разликата при предаване. Това вече не е проблем на инструментите. Това е избор на работен процес.