Figma в доступный HTML: практическое руководство

Краткий ответ: доступность в процессе конвертации Figma в HTML — это не одна настройка, которую можно включить, а набор конкретных решений: настоящие семантические элементы вместо стилизованных <div>, порядок заголовков, соответствующий структуре контента (в Figma нет встроенного понятия уровней заголовков), подписанные поля форм и кнопки-иконки, видимые состояния фокуса, достаточный цветовой контраст и ARIA, используемая экономно — только там, где семантический HTML сам по себе не может выразить взаимодействие. Автоматически сгенерированный код закрывает большую часть этой работы, но короткая ручная проверка всё равно ловит то, что файл дизайна физически не может передать.

Почему доступность теряется при переводе Figma в HTML

Файл Figma описывает, как выглядит дизайн. Он не описывает, что должен объявить экранный диктор, какой элемент должен получить фокус следующим или достаточно ли читаема пара цветов для человека со слабым зрением. Именно в этом разрыве и кроется настоящая причина, почему доступность ломается при конвертации — не в небрежности, а в том, что часть информации, необходимой для доступности, файл дизайна попросту не содержит. Пиксель-в-пиксель точное визуальное соответствие всё равно может оказаться провалом с точки зрения доступности, если под ним скрывается разметка из безликих <div> без структуры, подписей и поддержки клавиатуры.

Решение — не единственный автоматический проход. Это понимание того, какие части доступности хороший конвертер уже решает правильно, генерируя настоящую структуру вместо чисто визуальной разметки, а какие части всегда требуют осознанного решения — дизайнера, разработчика или обоих — потому что файл дизайна действительно не несёт этой информации.

Решения в Figma, которые влияют на доступность

Несколько распространённых привычек в Figma создают проблемы с доступностью ещё до того, как в дело вступает какой-либо инструмент конвертации:

• Цвет как единственный сигнал. Обязательное поле формы, отмеченное красным, или отключённая кнопка, которая всего лишь чуть светлее того же цвета — оба случая невидимы для человека, не различающего эти оттенки. Различие нуждается во втором сигнале (иконке, подписи, паттерне), а не только в изменении цвета.
• Текст, запечённый в изображение. Заголовок, экспортированный как плоский PNG, может выглядеть идентично настоящему текстовому слою, но его нельзя прочитать экранным диктором, изменить в размере средствами браузера или проиндексировать поисковым роботом.
• Отсутствие визуального состояния фокуса. У большинства наборов компонентов в Figma есть состояния по умолчанию, при наведении и иногда отключённое — состояние фокуса (для пользователей, переключающихся по странице клавишей Tab) часто просто никогда не проектируется, поэтому конвертации попросту нечего перенести.
• Кнопки-иконки без доступного названия где-либо в файле. Иконка корзины, означающая «удалить», очевидна визуально. Ничто в слое Figma не сообщает конвертеру — или экранному диктору, — что означает иконка, если только сам слой не назван осмысленно.
• Непоследовательные размеры заголовков. В Figma нет элемента «Heading 2» в том смысле, в каком он есть в CMS или текстовом редакторе — текстовые слои являются просто текстом, стилизованным под определённый размер. Два визуально похожих заголовка в разных фреймах могут представлять совершенно разные уровни в реальной иерархии контента.

Ничто из этого не является багом конвертации. Это решения, которые нужно принять где-то в процессе, и об этом стоит знать заранее, а не рассчитывать, что инструмент сам их выведет.

Семантический HTML и лендмарки

Это та часть доступности, которую хороший конвертер Figma-в-код должен решать правильно по умолчанию: настоящие элементы <header>, <nav>, <main>, <article>, <section>, <aside> и <footer> вместо страницы, целиком построенной из безымянных <div>. Лендмарки важны, потому что именно с их помощью пользователь экранного диктора сразу переходит к «основному содержимому» или «навигации», вместо того чтобы линейно перебирать всю страницу клавишей Tab. О том, как структурно выглядит вывод MarkupGen, — в статье Figma в семантический HTML, а о пересечении семантической разметки и индексируемости — в Готов ли вывод Figma-в-HTML для SEO?: у этих двух проблем общая первопричина и во многом общее решение.

Иерархия заголовков

Один <h1> на страницу, а заголовки должны понижаться по порядку — <h3> должен находиться внутри раздела, у которого уже есть <h2>, а не появляться там просто потому, что текстовый слой в дизайне выглядел такого размера. Как отмечалось выше, в Figma нет встроенного понятия уровней заголовков, поэтому крупно стилизованный текстовый слой автоматически не становится <h1> — это стоит проверить вручную независимо от того, каким инструментом сгенерирована разметка, потому что решение зависит от понимания реальной структуры контента, а не только его визуального размера.

Кнопки против ссылок

Это одна из самых распространённых ошибок доступности в сконвертированной разметке, и структура компонентов Figma сама по себе её не решает: <button> предназначен для действия на текущей странице (отправить форму, открыть модальное окно, удалить элемент); <a href> — для перехода на другую страницу или экран. Файл дизайна, полный одинаково стилизованных «таблеток», никак не показывает, что есть что — это семантическое решение, а не визуальное, и оно напрямую влияет как на поведение клавиатуры (кнопки и ссылки по умолчанию реагируют на разные клавиши), так и на то, что объявит экранный диктор.

Формы и подписи

Каждому полю ввода нужен настоящий, программно связанный <label> — а не placeholder, выполняющий его роль. Текст-заполнитель исчезает в тот момент, когда пользователь начинает печатать, по умолчанию имеет заведомо плохой контраст и не всегда надёжно зачитывается экранными дикторами в качестве замены подписи. Если по дизайнерским причинам форма должна выглядеть без видимых подписей, используйте визуально скрытую подпись, а не убирайте её из разметки полностью. Сообщения об ошибках нужно связывать с соответствующим полем (обычно через aria-describedby), а не просто размещать рядом, полагаясь только на цвет как сигнал проблемы.

Изображения и alt-текст

Экспортированным изображениям нужны осмысленные атрибуты alt, а не пустые строки или имя файла. Это одна из областей, где ручная проверка действительно неизбежна: для чего служит декоративное фоновое изображение и что нужно описать в товарном фото — не всегда очевидно из одного лишь фрейма Figma: файл дизайна не несёт намерения, только пиксели. Чисто декоративные изображения должны получать пустой alt="" (чтобы экранные дикторы их пропускали), а значимым изображениям нужно настоящее описание того, что они передают, а не просто того, что на них изображено.

Навигация с клавиатуры

Каждый интерактивный элемент — ссылки, кнопки, поля форм — должен быть доступен и управляем только с клавиатуры, в порядке, соответствующем визуальному порядку чтения. Здесь по-настоящему помогает Auto Layout: поскольку структура Auto Layout переносится в логичный порядок DOM, а не в набор абсолютно позиционированных фрагментов, порядок перехода по Tab, как правило, автоматически следует порядку чтения, а не скачет непредсказуемо, как это может происходить со свободными, абсолютно позиционированными макетами.

Состояния фокуса

Поскольку наборы компонентов в Figma редко включают спроектированное состояние фокуса, это обычно самый распространённый пробел доступности в сконвертированной странице: пользователь клавиатуры переключается по интерфейсу клавишей Tab и визуально не может понять, где он находится. Как минимум, не убирайте стандартную обводку фокуса браузера (outline: none), не заменив её чем-то столь же заметным — распространённая, легко допустимая ошибка, совершаемая ради соответствия дизайну, в котором это состояние никогда не учитывалось.

Цветовой контраст

Figma позволяет выбрать любые два цвета независимо от того, насколько они читаемы вместе, поэтому здесь нужна явная проверка, а не предположение. WCAG AA требует контраста не менее 4.5:1 для обычного текста и 3:1 для крупного текста (от 18px жирным или от 24px обычным начертанием), а также для значимых элементов интерфейса вроде иконок и границ полей ввода. Прогоните реальные пары цветов дизайна через проверку контраста ещё до конвертации — исправить токен в Figma значительно дешевле, чем потом искать проблему по всей сгенерированной разметке.

ARIA — когда она помогает, а когда откровенно вредит

Первое правило ARIA остаётся верным: отсутствие ARIA лучше, чем плохая ARIA. У нативного <button> уже есть правильная роль, он фокусируем и по умолчанию реагирует на Enter и Space — добавление к нему role="button" не даёт ничего полезного и рискует вступить в конфликт с реальной семантикой элемента. ARIA оправдывает себя именно там, где семантический HTML не может выразить взаимодействие сам по себе:

• Использовать: aria-label на кнопке-иконке без видимого текста (иконка корзины, означающая «удалить»), aria-expanded на переключателе, управляющем сворачиваемым разделом, aria-live="polite" на области, которая обновляется без перезагрузки страницы (сообщение валидации формы, счётчик товаров в корзине).
• Не использовать: добавление ролей ARIA к элементам, у которых уже есть правильная нативная семантика, декоративную ARIA, дублирующую то, что уже видно и объявляется, или aria-live="assertive" на чём-либо, что не является по-настоящему срочным — она прерывает вывод экранного диктора, и её легко переиспользовать без меры.

Доступность в адаптивной вёрстке

Проблемы доступности не остаются решёнными на всех точках перелома только потому, что их устранили при одном размере экрана. Области нажатия должны оставаться не менее примерно 44×44px на мобильных, даже когда макет сжимается — кнопка, удобная для клика на десктопе, может стать слишком маленькой для надёжного нажатия, как только ограничения ресайза Auto Layout уменьшат её. Текст должен переноситься, а не обрезаться или накладываться на узких экранах, а порядок контента не должен запутанно меняться между точками перелома так, чтобы нарушить логичный порядок чтения, на который опирается экранный диктор.

Частые ошибки доступности при конвертации Figma в HTML

• Каждый кликабельный элемент превращён в <div onclick> вместо настоящего <button> или <a>.
• Кнопки-иконки без aria-label, потому что слой в Figma был просто назван «Icon 4».
• Цвет как единственный способ передать состояние (ошибка, отключено, выбрано).
• outline: none на состояниях фокуса без чего-либо видимого взамен.
• Текст-заполнитель, используемый как единственная подпись поля формы.
• Декоративным изображениям в качестве alt-текста присвоено имя файла вместо пустого alt="".
• Уровни заголовков выбраны по размеру шрифта в дизайне, а не по реальной структуре контента.

До / после: кнопка-иконка

До — визуально верно, недоступно:

<div class="icon-btn" onclick="deleteItem()">
  <svg><!-- иконка корзины --></svg>
</div>

После — тот же визуальный результат, реально пригодно к использованию:

<button type="button" class="icon-btn" aria-label="Удалить элемент" onclick="deleteItem()">
  <svg aria-hidden="true"><!-- иконка корзины --></svg>
</button>

Разница вовсе не визуальная — это настоящий элемент <button> (фокусируемый, управляемый с клавиатуры, корректно объявляемый экранным диктором), aria-label, дающий иконке доступное название, и aria-hidden="true" на декоративном SVG, чтобы он не объявлялся дважды.

Практический чек-лист доступности

• Один <h1> на страницу; заголовки понижаются по порядку, а не по размеру шрифта
• Присутствуют настоящие элементы-лендмарки (header, nav, main, footer)
• Каждое кликабельное действие — это <button>; каждая навигационная ссылка — это <a href>
• У каждого поля ввода есть настоящий, связанный <label> — а не только placeholder
• У значимых изображений есть описательный alt-текст; у декоративных — alt=""
• Состояния фокуса видны на каждом интерактивном элементе
• Порядок Tab соответствует визуальному порядку чтения
• Контраст текста и элементов интерфейса соответствует WCAG AA (4.5:1 / 3:1)
• Цвет никогда не является единственным сигналом состояния или значения
• ARIA используется только там, где семантический HTML не может выразить взаимодействие
• Области нажатия остаются пригодными к использованию на мобильных точках перелома
• Макет переносится без обрезания или наложения текста на узких экранах

Как проверять сгенерированный код перед продакшеном

Вывод MarkupGen по умолчанию, а не как опциональная настройка, отдаёт предпочтение семантическим элементам и настоящей структуре заголовков, а перенос структуры Auto Layout в логичный порядок DOM — это основа того, что вообще делает правильный порядок Tab возможным. Автоматическая оценка качества AI, которую получает каждый экспорт, — по-настоящему полезный первый сигнал, но она явно является оценкой визуального соответствия, сравнивающей отрендеренный превью с исходным дизайном. Она не проверяет корректность ARIA, коэффициенты контраста или поведение клавиатуры, потому что ничто из этого не видно при сравнении скриншотов. Относитесь к чек-листу выше как к ручной проверке, которая идёт после высокой визуальной оценки, а не вместо неё — тот же принцип, применённый к проверке кода в более широком смысле, разобран в статье Как оценить сгенерированный AI HTML перед запуском.

Попробуйте на своём дизайне

Самый быстрый способ увидеть, где дизайну нужна проверка доступности, — сконвертировать его и открыть реальную разметку. Попробуйте MarkupGen бесплатно или начните с полного руководства по конвертации Figma в HTML, на котором построено это руководство.