Новый виток A11y в Apple?
Джон Тернус — новый CEO Apple, а также тот человек, который в качестве дипломного проекта в University of Pennsylvania разработал механическую руку для кормления, управляемую с помощью движений головы. То есть пользователь, не имеющий возможности двигать конечностями, мог самостоятельно есть — управление шло через head-tracking без участия рук.
Также стоит вспомнить, что именно под его руководством вышли
Apple Watch с Double Tap — классический curb cut effect: жестовое управление изначально появилось в 2021 году как AssistiveTouch, фича для людей с особенностями верхних конечностей, а позже та же технология стала фичей для всех. AirPods Pro с hearing aid — наушники массового рынка, работающие как слуховой аппарат. Vision Pro, где eye-tracking — основной интерфейс: формально это универсальный дизайн, но выросший из accessibility-подхода )
И это уже другой уровень доступности — встройка в железо ) Кайф? Кайф!
___
en<able> - о дизайне в A11y | Наши статьи на VC
Джон Тернус — новый CEO Apple, а также тот человек, который в качестве дипломного проекта в University of Pennsylvania разработал механическую руку для кормления, управляемую с помощью движений головы. То есть пользователь, не имеющий возможности двигать конечностями, мог самостоятельно есть — управление шло через head-tracking без участия рук.
Также стоит вспомнить, что именно под его руководством вышли
Apple Watch с Double Tap — классический curb cut effect: жестовое управление изначально появилось в 2021 году как AssistiveTouch, фича для людей с особенностями верхних конечностей, а позже та же технология стала фичей для всех. AirPods Pro с hearing aid — наушники массового рынка, работающие как слуховой аппарат. Vision Pro, где eye-tracking — основной интерфейс: формально это универсальный дизайн, но выросший из accessibility-подхода )
И это уже другой уровень доступности — встройка в железо ) Кайф? Кайф!
Alt: фотография Джона Тёрнуса на сцене Apple-презентации, за ним крупным планом чипы и схемы.___
en<able> - о дизайне в A11y | Наши статьи на VC
🔥5⚡3❤2
Часть 2: Дизайн-система в космосе и доступность
В прошлой части закончили на том, что проектируем интерфейс как будто мы астронавты. А теперь к нам присоединяются коллеги на Земле: операторы Mission Control в Хьюстоне, ЦУП в Королёве, разработчики из четырёх космических агентств. Все смотрят на один и тот же экран — и всем должно быть одинаково понятно, что на нём происходит.
На МКС одновременно живут и работают шесть человек в модулях, построенных четырьмя космическими агентствами — американским NASA, европейским ESA, японским JAXA и российским Роскосмосом. Американский астронавт заходит в японский модуль Kibo, потом в европейский Columbus, потом в российский «Звезда» — и в каждом должен взаимодействовать с интерфейсом так же быстро, как в своём.
И здесь начинается разговор о доступности — в том числе когнитивной. Не только о шрифтах и контрасте, а о том, сколько усилий нужно пользователю, чтобы понять, что происходит на экране. Каждое расхождение — это лишняя нагрузка. Она накапливается у астронавтов, которые устали и работают, а ещё у людей с СДВГ или дислексией, которым сложнее быстро распознавать паттерны и переключаться между контекстами. И именно в такие моменты понимание нужнее всего.
Поэтому у программы МКС есть общий для всех партнёров стандарт — SSP-50313 Display and Graphics Commonality Standard. По сути это дизайн-система: компоненты, токены, правила иерархии, стандартные паттерны взаимодействия. Но важнее — это единый язык интерфейса. Он снижает когнитивную нагрузку, делает интерфейсы предсказуемыми и позволяет переносить опыт из одного модуля в другой без переобучения.
Самое завораживающее — как связаны экипаж и Земля. Mission Control Center (MCC) в Хьюстоне, ЦУП в Королёве и экипаж на орбите работают в одной информационной системе. Операторы на Земле 24/7 видят ту же телеметрию, что и астронавты. Когда CAPCOM (Capsule Communicator — единственный человек, который напрямую разговаривает с экипажем) говорит «проверь параметр на третьем экране» — он точно знает, что астронавт сейчас видит. Это про общий контекст и общее понимание системы — когда у всех участников одна и та же «картина мира».
В продуктовых командах ведь как бывает? Прод — одна версия, в Figma — другая, аналитика — дай бог правильно настроена. И у команды уже нет этой общей картины. А без неё сложно говорить не только о совместной работе, но и о доступности — потому что пользовательский опыт начинает «расползаться».
Ещё один интересный факт: консоли MCC с 60-х годов спроектированы модульно — каждая панель может быть переставлена на любое место за минуты. Инженер, спроектировавший эту систему, в 1967 году писал, что модульность нужна в том числе для того, чтобы левши могли настроить органы управления под себя. То есть система не только единообразна, но и адаптируема под пользователя.
Но как обеспечить такую согласованность?
• Единая документация. К стандарту SSP‑50313 прилагается интерактивное руководство: для каждого компонента — как он работает, когда используется, какие есть альтернативы.
• Симуляторы. Астронавты и операторы тренируются на виртуальных копиях интерфейсов в стрессовых сценариях: при имитации аварий, сбоев связи или ограниченной видимости.
• Регулярные аудиты. Раз в полгода интерфейсы проверяются на соответствие стандарту — в том числе с участием людей с разными типами восприятия.
Дизайн-система — это не библиотека компонентов. Это договорённость о том, как система ведёт себя с пользователем в любой точке — чтобы её можно было понять быстро и в любой ситуации. И чем больше команд работает над одним продуктом, тем важнее эта договорённость.
Источники
• SSP-50313 Display and Graphics Commonality Standard — обзор на NASA NTRS, 2022
• SSP-50313 — полный документ в Internet Archive
• Christopher C. Kraft Jr. Mission Control Center — NASA JSС
• Hendrickson H.C. The display/control complex of the Manned Space Mission Control Center, 1967
В прошлой части закончили на том, что проектируем интерфейс как будто мы астронавты. А теперь к нам присоединяются коллеги на Земле: операторы Mission Control в Хьюстоне, ЦУП в Королёве, разработчики из четырёх космических агентств. Все смотрят на один и тот же экран — и всем должно быть одинаково понятно, что на нём происходит.
На МКС одновременно живут и работают шесть человек в модулях, построенных четырьмя космическими агентствами — американским NASA, европейским ESA, японским JAXA и российским Роскосмосом. Американский астронавт заходит в японский модуль Kibo, потом в европейский Columbus, потом в российский «Звезда» — и в каждом должен взаимодействовать с интерфейсом так же быстро, как в своём.
И здесь начинается разговор о доступности — в том числе когнитивной. Не только о шрифтах и контрасте, а о том, сколько усилий нужно пользователю, чтобы понять, что происходит на экране. Каждое расхождение — это лишняя нагрузка. Она накапливается у астронавтов, которые устали и работают, а ещё у людей с СДВГ или дислексией, которым сложнее быстро распознавать паттерны и переключаться между контекстами. И именно в такие моменты понимание нужнее всего.
Поэтому у программы МКС есть общий для всех партнёров стандарт — SSP-50313 Display and Graphics Commonality Standard. По сути это дизайн-система: компоненты, токены, правила иерархии, стандартные паттерны взаимодействия. Но важнее — это единый язык интерфейса. Он снижает когнитивную нагрузку, делает интерфейсы предсказуемыми и позволяет переносить опыт из одного модуля в другой без переобучения.
Самое завораживающее — как связаны экипаж и Земля. Mission Control Center (MCC) в Хьюстоне, ЦУП в Королёве и экипаж на орбите работают в одной информационной системе. Операторы на Земле 24/7 видят ту же телеметрию, что и астронавты. Когда CAPCOM (Capsule Communicator — единственный человек, который напрямую разговаривает с экипажем) говорит «проверь параметр на третьем экране» — он точно знает, что астронавт сейчас видит. Это про общий контекст и общее понимание системы — когда у всех участников одна и та же «картина мира».
В продуктовых командах ведь как бывает? Прод — одна версия, в Figma — другая, аналитика — дай бог правильно настроена. И у команды уже нет этой общей картины. А без неё сложно говорить не только о совместной работе, но и о доступности — потому что пользовательский опыт начинает «расползаться».
Ещё один интересный факт: консоли MCC с 60-х годов спроектированы модульно — каждая панель может быть переставлена на любое место за минуты. Инженер, спроектировавший эту систему, в 1967 году писал, что модульность нужна в том числе для того, чтобы левши могли настроить органы управления под себя. То есть система не только единообразна, но и адаптируема под пользователя.
Но как обеспечить такую согласованность?
• Единая документация. К стандарту SSP‑50313 прилагается интерактивное руководство: для каждого компонента — как он работает, когда используется, какие есть альтернативы.
• Симуляторы. Астронавты и операторы тренируются на виртуальных копиях интерфейсов в стрессовых сценариях: при имитации аварий, сбоев связи или ограниченной видимости.
• Регулярные аудиты. Раз в полгода интерфейсы проверяются на соответствие стандарту — в том числе с участием людей с разными типами восприятия.
Дизайн-система — это не библиотека компонентов. Это договорённость о том, как система ведёт себя с пользователем в любой точке — чтобы её можно было понять быстро и в любой ситуации. И чем больше команд работает над одним продуктом, тем важнее эта договорённость.
Источники
• SSP-50313 Display and Graphics Commonality Standard — обзор на NASA NTRS, 2022
• SSP-50313 — полный документ в Internet Archive
• Christopher C. Kraft Jr. Mission Control Center — NASA JSС
• Hendrickson H.C. The display/control complex of the Manned Space Mission Control Center, 1967
🔥10❤3⚡2❤🔥1👏1
Forwarded from Рубанов про мобилу (Михаил Рубанов)
Переиздание книги про доступность
Пришло время перезапустить книгу в виде сайта!
Запускаю ее в формате DocC:
• доступна в онлайне, можно ссылаться на любой раздел,
• верстка под мобилу и декстоп,
• светлая/темная тема.
Как и раньше книжка остается бесплатной.
Как и раньше выпускать буду главами раз в пару недель, про обновления будет в этом канале. Сейчас доступна первая глава про общее понимание доступности, статистику и как пользоваться скринридером.
Самое ценное что вы можете сделать: поделиться сайтом со своими знакомыми программистами, дизайнерами, продактами и рассказать в соцсетях.
https://bookshelf.dev/a11y-book/
Пришло время перезапустить книгу в виде сайта!
Запускаю ее в формате DocC:
• доступна в онлайне, можно ссылаться на любой раздел,
• верстка под мобилу и декстоп,
• светлая/темная тема.
Как и раньше книжка остается бесплатной.
Как и раньше выпускать буду главами раз в пару недель, про обновления будет в этом канале. Сейчас доступна первая глава про общее понимание доступности, статистику и как пользоваться скринридером.
Самое ценное что вы можете сделать: поделиться сайтом со своими знакомыми программистами, дизайнерами, продактами и рассказать в соцсетях.
https://bookshelf.dev/a11y-book/
🔥11❤🔥3
На фоне бесконечных похорон и поминок дизайнеров, давайте о приятных вещах ))) У Миши Рубанова вышел сайт! И это кайфово! Удобно, индексируется поисковиками, ведь на русском языке так мало материалов по доступности, так что радуюсь безумно! Еще бы нам youtube подтянуть, кстати, канал Миши тут
❤7❤🔥3
У меня в планах на неделю пост про цвет в доступности, будем разбираться в OKLCH (здесь уже есть немного) и разбор на доступность приложений в Femtech. И не могут не радовать новости — Исследование: почему инвесторы стали лучше относиться к стартапам с женским участием.
Плюс у меня еще висит исследование пользователей Reddit, рассказать про первые прости господи инсайты?
И в продолжении хайпа по поводу новых инструментов ИИ в дизайне — 100 лет на рынке уже шаблоны для сайтов, анимации, отдельных компонентов. Но дизайн — это нечто большее. ИИ более-менее справляется с формой. Но за формой всегда стоит смысл — и вот здесь начинается настоящая работа дизайнера. Эмпатия, исследования, контекст, этика — это не генерируется по одному промпту.
И раз у меня тут мини дайджест порекомендую пост Ильи Скопина про разный подход дизайнеров, которые будут нужны на рынке. Речь идет об американской практике, но по моему опыту найма мне бы было супер работать с любым из этих типов.
Немного СДВГшный пост, но выложила и полегчало ))
Плюс у меня еще висит исследование пользователей Reddit, рассказать про первые прости господи инсайты?
И в продолжении хайпа по поводу новых инструментов ИИ в дизайне — 100 лет на рынке уже шаблоны для сайтов, анимации, отдельных компонентов. Но дизайн — это нечто большее. ИИ более-менее справляется с формой. Но за формой всегда стоит смысл — и вот здесь начинается настоящая работа дизайнера. Эмпатия, исследования, контекст, этика — это не генерируется по одному промпту.
И раз у меня тут мини дайджест порекомендую пост Ильи Скопина про разный подход дизайнеров, которые будут нужны на рынке. Речь идет об американской практике, но по моему опыту найма мне бы было супер работать с любым из этих типов.
Немного СДВГшный пост, но выложила и полегчало ))
🔥5⚡1👌1
Сейчас слушаю Lenny's podcast c head of design Дженни Вен и ее цитата:
Все так, все так
«Самое сложное в создании продукта — это не само создание. Кто-то всё равно должен решить, что важно строить. И кто-то должен нести за это ответственность».
Все так, все так
🔥5❤1👏1
📄 Инструкция настройки базы знаний для UX-исследований по методу Андрея Карпаты
Я сейчас провожу Reddit-исследование на 1250 постах по цифровой доступности. И мне нужно сделать так, чтобы Claude искал только по моей базе, а не во всем интернете.
Недавно Андрей Карпаты (один из основателей OpenAI) выложил в X пост о том, как он хранит информацию как .md файлы (обычные текстовые файлы) и подключает Claude напрямую к этим знаниям.
Почему это лучше, чем просто загружать файлы в чат? Каждая сессия Claude начинается с чистого листа — приходится заново объяснять контекст. Claude Code подключён к папке постоянно через терминал: один раз структурировала знания, и они работают во всех следующих сессиях.
Настроила примерно за час и то, потому что протупила с путями, куда что сохранять. А так оч быстро ) Потом полдня писала эту инструкцию ) Буду рада вашим реакциям )
В будущем хочу попробовать: настроить поиск по смыслу (семантический), а не по точным словам: чтобы Claude находил «усталость», даже если в заметке написано «выгорание». Автоматизировать обработку новых источников — положила файл в папку, он сам превратился в структурированную заметку. И сделать так чтобы Claude знал базу без чтения файлов каждый раз, как это делает Notebook LM. Карпаты об этом тоже писал.
⚡️Написала инструкцию на VC⚡️
___
en<able> - о дизайне в A11y | Наши статьи на VC
Я сейчас провожу Reddit-исследование на 1250 постах по цифровой доступности. И мне нужно сделать так, чтобы Claude искал только по моей базе, а не во всем интернете.
Недавно Андрей Карпаты (один из основателей OpenAI) выложил в X пост о том, как он хранит информацию как .md файлы (обычные текстовые файлы) и подключает Claude напрямую к этим знаниям.
Почему это лучше, чем просто загружать файлы в чат? Каждая сессия Claude начинается с чистого листа — приходится заново объяснять контекст. Claude Code подключён к папке постоянно через терминал: один раз структурировала знания, и они работают во всех следующих сессиях.
Настроила примерно за час и то, потому что протупила с путями, куда что сохранять. А так оч быстро ) Потом полдня писала эту инструкцию ) Буду рада вашим реакциям )
В будущем хочу попробовать: настроить поиск по смыслу (семантический), а не по точным словам: чтобы Claude находил «усталость», даже если в заметке написано «выгорание». Автоматизировать обработку новых источников — положила файл в папку, он сам превратился в структурированную заметку. И сделать так чтобы Claude знал базу без чтения файлов каждый раз, как это делает Notebook LM. Карпаты об этом тоже писал.
⚡️Написала инструкцию на VC⚡️
___
en<able> - о дизайне в A11y | Наши статьи на VC
🔥6❤3❤🔥1👏1
ИИ-агенты помогут с доступностью
У Nielsen Norman Group вышла интересная статья. Сейчас с сайтами взаимодействуют не только люди, но и ИИ-агенты. Это требует переосмысления: «пользователь» больше не синоним «человека».
Агент — это полноценный пользователь, потому что:
• у него есть цель;
• он сталкивается с интерфейсом;
• он пытается достичь цели через этот интерфейс;
• интерфейс либо поддерживает эту попытку, либо нет.
И это очень хорошие новости! Интерфейсы, хорошо сделанные с точки зрения доступности, уже сегодня лучше работают с агентами.
Как агенты взаимодействуют с интерфейсами сегодня
1. через скриншоты — и с помощью визуальной модели интерпретирует увиденное — распознаёт кнопки, поля ввода, элементы навигации, решает, куда кликнуть, и повторяет цикл. Но это дорого, токенов тратится много.
2. парсинг дерева доступности — агент читает структурированное представление страницы, которое браузер генерирует из HTML, — то же самое, чем пользуются скринридеры! Самое важное для нас с вами!
3. прямой доступ к API — полностью обходит визуальный интерфейс: агент обращается напрямую к структурированным данным и действиям через API, без какого-либо взаимодействия с видимым представлением страницы.
Какой вывод? Дааа! Хорошая доступность = хорошая читаемость для агентов, а значит проектируем для человека и для агента с учетом всего того, что мы тут обсуждаем ) И это еще один классный аргумент для бизнеса, почему доступность важна.
Источник тут.
У Nielsen Norman Group вышла интересная статья. Сейчас с сайтами взаимодействуют не только люди, но и ИИ-агенты. Это требует переосмысления: «пользователь» больше не синоним «человека».
Агент — это полноценный пользователь, потому что:
• у него есть цель;
• он сталкивается с интерфейсом;
• он пытается достичь цели через этот интерфейс;
• интерфейс либо поддерживает эту попытку, либо нет.
И это очень хорошие новости! Интерфейсы, хорошо сделанные с точки зрения доступности, уже сегодня лучше работают с агентами.
Как агенты взаимодействуют с интерфейсами сегодня
1. через скриншоты — и с помощью визуальной модели интерпретирует увиденное — распознаёт кнопки, поля ввода, элементы навигации, решает, куда кликнуть, и повторяет цикл. Но это дорого, токенов тратится много.
2. парсинг дерева доступности — агент читает структурированное представление страницы, которое браузер генерирует из HTML, — то же самое, чем пользуются скринридеры! Самое важное для нас с вами!
3. прямой доступ к API — полностью обходит визуальный интерфейс: агент обращается напрямую к структурированным данным и действиям через API, без какого-либо взаимодействия с видимым представлением страницы.
Какой вывод? Дааа! Хорошая доступность = хорошая читаемость для агентов, а значит проектируем для человека и для агента с учетом всего того, что мы тут обсуждаем ) И это еще один классный аргумент для бизнеса, почему доступность важна.
Источник тут.
❤8✍4⚡3🗿1
67% пользователей, которые работают с клавиатурой, сталкиваются с неправильным tab order каждый месяц. 82% пользователей скринридеров — регулярно натыкаются на барьеры на сайтах.
Давайте разбираться, как эти цифры уменьшить )
Reading order отвечает за то, как пользователь понимает страницу. Условно это книга. Порядок идет сверху вниз, слева направо. Читает всё: заголовки, текст, картинки, кнопки. Строит картину страницы последовательно. Именно по нему ориентируются скринридеры.
Reading Order = порядок смысла.
Tab Order же — это оглавление.
Правило простое: всё, что можно нажать — входит в Tab Order. Неважно, как это выглядит визуально: кнопка, ссылка, чекбокс, селект. Если элемент интерактивный, клавиатура до него доберётся.
Tab Order = порядок действий.
В карточках на примере моего любимого Dodo 🧡 показала разницу.
Если порядок и того, и другого определишь не ты, то это сделает за тебя браузер по своей логике. Скринридер может зачитать кнопку раньше, чем название товара. Клавиатурный фокус может уйти в сайдбар посреди основного контента. Пользователь не поймёт, где он. И просто уйдёт.
Как проще всего понять это на практике?
Откройте свой последний проект в браузере. Уберите мышь и нажмите Tab несколько раз. Как ощущения?
И также со скринридером, чтобы понять reading order. Если Mac — пройдитесь скринридером VoiceOver. Если Windows — NVDA, он бесплатный. Это займёт 15 минут. Но вы увидите свой продукт совсем другими глазами.
Как это включить в работу? Аннотировать для разрабов цифрами и стрелочками, ниже дам готовые компоненты для разметки - easy! либо еще easier — плагинами для Figma.
↓
Готовые компоненты для аннотаций от GitHub
Плагин TabA11y
Плагин Stark
___
en<able> - о дизайне в A11y | Наши статьи на VC
Давайте разбираться, как эти цифры уменьшить )
Reading order отвечает за то, как пользователь понимает страницу. Условно это книга. Порядок идет сверху вниз, слева направо. Читает всё: заголовки, текст, картинки, кнопки. Строит картину страницы последовательно. Именно по нему ориентируются скринридеры.
Reading Order = порядок смысла.
Tab Order же — это оглавление.
Правило простое: всё, что можно нажать — входит в Tab Order. Неважно, как это выглядит визуально: кнопка, ссылка, чекбокс, селект. Если элемент интерактивный, клавиатура до него доберётся.
Tab Order = порядок действий.
В карточках на примере моего любимого Dodo 🧡 показала разницу.
Если порядок и того, и другого определишь не ты, то это сделает за тебя браузер по своей логике. Скринридер может зачитать кнопку раньше, чем название товара. Клавиатурный фокус может уйти в сайдбар посреди основного контента. Пользователь не поймёт, где он. И просто уйдёт.
Как проще всего понять это на практике?
Откройте свой последний проект в браузере. Уберите мышь и нажмите Tab несколько раз. Как ощущения?
И также со скринридером, чтобы понять reading order. Если Mac — пройдитесь скринридером VoiceOver. Если Windows — NVDA, он бесплатный. Это займёт 15 минут. Но вы увидите свой продукт совсем другими глазами.
Как это включить в работу? Аннотировать для разрабов цифрами и стрелочками, ниже дам готовые компоненты для разметки - easy! либо еще easier — плагинами для Figma.
↓
Готовые компоненты для аннотаций от GitHub
Плагин TabA11y
Плагин Stark
___
en<able> - о дизайне в A11y | Наши статьи на VC
1❤5🔥4✍3
Проверка проекта в AI
На гитхабе дизайнер создал файл A11y.md — готовый контекст, который загружаешь в Claude (или любую другую нейронку) — и она начинает проверять твои макеты по стандартам WCAG 2.2.
Дима и Миша рассказывали уже о том, что если не спросить нейронку, то она и не расскажет о доступности, так вот md решает данную проблему.
Мне нравится, как этот диз написал: Accessibility is not a feature or an incremental improvement; it is a pre-condition for use. Доступность — это необходимое условие.
Как пользоваться, если ты диз?
1. Открыть файл на GitHub A11Y.md из папки docs/en/
2. Вставить в начало чата с AI «Строго следуй правилам разработки, описанным в файле A11Y.md»
3. Скинуть файл или ссылку на свой проект
4. Готово!
Что внутри репозитория:
⚡ Command Center — главный файл с матрицей приоритетов, правилами поведения для AI и протоколом для сложных компонентов.
📚 Support Library — справочная библиотека с готовыми решениями по контрасту, формам, кнопкам, навигации и модалкам.
🛠️ Templates — шаблоны для финальной проверки перед релизом и структурированный лог для фиксации технического долга.
📝 Examples — реальные ошибки доступности из проекта на Figma Make, с конкретными исправлениями, которые предложил A11Y.md в роли автоматического ревьюера.
Немного того, что важно для дизайнера:
→ Контраст текста должен быть 4.5:1, элементов UI — 3:1
→ Нельзя передавать состояние только цветом — нужны иконка + текст + цвет
→ Минимальный размер кнопки — 44×44px
→ Плейсхолдер не заменяет подпись к полю
→ Графики обязаны различаться без цвета — текстурами или штриховкой
и многое другое
Этот файл не научит доступности с нуля, он действует скорее как быстрый фильтр и сверка с WCAG. Конечно, я за то, чтобы изучать A11y глубже )
На гитхабе дизайнер создал файл A11y.md — готовый контекст, который загружаешь в Claude (или любую другую нейронку) — и она начинает проверять твои макеты по стандартам WCAG 2.2.
Дима и Миша рассказывали уже о том, что если не спросить нейронку, то она и не расскажет о доступности, так вот md решает данную проблему.
Мне нравится, как этот диз написал: Accessibility is not a feature or an incremental improvement; it is a pre-condition for use. Доступность — это необходимое условие.
Как пользоваться, если ты диз?
1. Открыть файл на GitHub A11Y.md из папки docs/en/
2. Вставить в начало чата с AI «Строго следуй правилам разработки, описанным в файле A11Y.md»
3. Скинуть файл или ссылку на свой проект
4. Готово!
Что внутри репозитория:
⚡ Command Center — главный файл с матрицей приоритетов, правилами поведения для AI и протоколом для сложных компонентов.
📚 Support Library — справочная библиотека с готовыми решениями по контрасту, формам, кнопкам, навигации и модалкам.
🛠️ Templates — шаблоны для финальной проверки перед релизом и структурированный лог для фиксации технического долга.
📝 Examples — реальные ошибки доступности из проекта на Figma Make, с конкретными исправлениями, которые предложил A11Y.md в роли автоматического ревьюера.
Немного того, что важно для дизайнера:
→ Контраст текста должен быть 4.5:1, элементов UI — 3:1
→ Нельзя передавать состояние только цветом — нужны иконка + текст + цвет
→ Минимальный размер кнопки — 44×44px
→ Плейсхолдер не заменяет подпись к полю
→ Графики обязаны различаться без цвета — текстурами или штриховкой
и многое другое
Этот файл не научит доступности с нуля, он действует скорее как быстрый фильтр и сверка с WCAG. Конечно, я за то, чтобы изучать A11y глубже )
❤9⚡1👌1