Альтернатива перетаскиванию с нейросетью начинается с описания результата действия. Если сотрудник переносит карточку между разделами учебного задания, нужно сохранить этот перенос, но дать способ выполнить его щелчками или касаниями без удержания и движения. ИИ можно поручить черновик спецификации и сценариев. Проверять работу готового компонента предстоит человеку.
Разберём учебное упражнение для команды, которая готовит материалы и передаёт требования разработчику. Результат — таблица эквивалентных действий и журнал проверки конкретного компонента.
Какую проблему решает альтернатива перетаскиванию?
Представьте практикум: карточку «Проверить источник» нужно перенести из раздела «Подготовка» в раздел «Проверка». Мышью это получается только при удержании кнопки. Пользователь, которому трудно одновременно удерживать контакт и двигать указатель, не может закончить задание. Увеличенная карточка сама по себе не меняет способ действия.
Разъяснение W3C Dragging Movements описывает требование уровня AA: функциональность, использующая перетаскивание, должна быть достижима одним указателем без перетаскивания. В требовании есть исключения для существенности перетаскивания и функциональности, определяемой пользовательским агентом и не изменённой автором.
Факт. Клавиатурный эквивалент не закрывает это требование автоматически: пользователю указателя нужен доступный ему способ действия. Например, сочетание клавиш не становится кнопкой, которую можно нажать мышью или пальцем.
Далее предложен редакционный способ учебной работы с ИИ. W3C не оценивает наш промпт и не подтверждает эффективность обучения. Карточки, состояния и возможные дефекты вымышлены; мы не сообщаем результаты аудита клиента или AURMIND. Упражнение не заменяет полный аудит доступности.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Сначала опишите действие и его результат
Не просите модель «сделать drag-and-drop доступным», пока не определили назначение компонента. Перестановка внутри списка, смена статуса и назначение получателя — разные функции. Они могут выглядеть похоже, но требуют разных результатов.
В нашем условном практикуме согласуем следующие правила. Есть разделы «Подготовка» и «Проверка». Карточка «Проверить источник» изначально находится в «Подготовке». Перетаскивание в «Проверку» меняет только раздел карточки; название и текст сохраняются. Автоматической отправки ответа в этом упражнении нет. Задание завершается отдельной кнопкой после проверки распределения.
Для альтернативного пути владелец упражнения выбирает кнопку «Переместить» у карточки. Она открывает выбор доступного раздела; отдельное нажатие «Проверка» переносит карточку туда. Для возврата можно тем же способом выбрать «Подготовка». Это спецификация нашего учебного компонента, а не обязательный для всех интерфейсов шаблон.
Запишите результат до обсуждения кнопок.
Неизменность текста карточки и отдельная отправка — два самостоятельных условия нашего примера. При проверке сохраните исходный текст и сравните его после переноса. Если меняется только картинка расположения, этого недостаточно, чтобы принять всю функцию по нашей спецификации. Сначала уточните, где компонент хранит раздел карточки и как проверяющий сможет увидеть актуальное состояние.
| Свойство | Исходное действие | Предлагаемый альтернативный путь |
|---|---|---|
| Объект | Карточка «Проверить источник» | Та же карточка |
| Начальное состояние | Раздел «Подготовка» | Тот же раздел |
| Действие | Удержать и перетащить в «Проверку» | Нажать «Переместить», затем «Проверка» |
| Итог | Карточка в разделе «Проверка» | Тот же раздел, название и текст сохранены |
| Возврат | Перетащить обратно | Выбрать «Подготовка» через ту же кнопку |
| Завершение задания | Отдельная отправка | Та же отдельная отправка |
Если модель предлагает удалить карточку и создать новую, она изменила операцию. Если сразу отправляет весь ответ, она добавила побочное действие. В обоих случаях нужно вернуться к исходной спецификации.
При работе с настоящим материалом добавьте сведения о сохранении изменений, ограничениях доступа и возможных потерях данных, если они существуют в спецификации. Не разрешайте ИИ достраивать их по названию компонента. Для неизвестного поведения нужна пометка «нет данных» и вопрос владельцу.
Какое поручение дать нейросети?
Передайте описание функции, начальное состояние, разрешённые назначения и условия результата. Для тренировки достаточно вымышленной карточки. Настоящие учебные ответы и внутреннюю разметку используют только в разрешённой организацией среде; персональные сведения для нашего примера не нужны.
Предлагаемый запрос:
По приложенной спецификации подготовь черновик альтернативы перетаскиванию карточки. Сохрани объект, доступные разделы, результат переноса и отдельную отправку задания. Альтернатива должна работать одним указателем без удержания с движением: простыми щелчками или касаниями. Не заменяй её только сочетанием клавиш или свайпом. Составь таблицу «исходное состояние — действие — ожидаемый результат — основание в спецификации». Фактический результат оставь незаполненным. Отдельно запиши вопросы по отсутствующим сведениям. Не утверждай, что выполнил тест или подтвердил соответствие всего сайта WCAG.
Приложите выдержки из первичного документа, а не только ссылку на него. После ответа проверьте каждую строку по исходнику. В нашем примере нет третьего раздела, группового выбора и автоматического подтверждения. Их появление в ответе — повод убрать выдуманные условия.
Один из полезных вопросов модели — что происходит после выбора текущего раздела. Мы пока не определили это правило. Сотрудник должен согласовать его с владельцем компонента перед тестированием, а не объявлять придуманное поведение обязательным.
Мнение. Для первого занятия я предлагаю один объект и два назначения: так участникам проще заметить подмену результата. Это редакционный выбор масштаба упражнения, а не ограничение стандарта.
Для общего навыка сверки можно использовать материал о проверке ответа нейросети. Здесь предмет уже: сохранить результат конкретного переноса и подготовить проверяемый путь без перетаскивания.
Достаточно ли добавить управление клавишами?
Нет, если единственная альтернатива доступна только с клавиатуры. W3C отдельно объясняет связь требований: клавиатурная доступность и действие одним указателем без перетаскивания оцениваются независимо. Один интерфейс может поддерживать drag-and-drop и сочетание клавиш, но оставаться неудобным для человека, использующего только касания.
Кнопки можно спроектировать так, чтобы они поддерживали разные способы ввода.
Но наличие надписи «доступно с клавиатуры» ещё не доказывает, что нужный результат достигается простыми щелчками. В проверке нужно действительно пройти этот путь.
Разделите наблюдения.
| Что проверяем | Какое наблюдение нужно | Что им нельзя заменить |
|---|---|---|
| Альтернатива перетаскиванию | Перенос достигается щелчками или касаниями без удержания и движения | Факт работы сочетания клавиш |
| Клавиатурная работа | Функция доступна через согласованный клавиатурный способ | Факт наличия кнопки на экране |
| Сохранность результата | Перенесена нужная карточка в нужный раздел | Изменение одной подписи или цвета |
У клавиатурного пути есть собственные детали. Например, порядок фокуса помогает проверить последовательность переходов. Он не заменяет испытание указателем, которое рассматривается в этой статье.
В журнале могут одновременно стоять разные статусы: «перенос касаниями выполнен» и «клавиатурный маршрут ещё не проверен». Такая запись точнее общего «доступность пройдена».
Почему свайп не всегда решает задачу?
Разъяснение W3C Pointer Gestures отделяет жест с заданной траекторией от обычного перетаскивания. Для жеста важны путь или направление движения. При обычном переносе объекта могут иметь значение только начало и конец, без обязательной траектории между ними.
Документ Dragging Movements прямо предупреждает: альтернатива не может опираться исключительно на жест по заданному пути, например свайп. Замена «удержать и перенести» на «провести строго вправо» может оставить другую преграду для пользователя указателя.
Не переносите вывод по внешнему виду.
Ползунок выглядит как элемент, который двигается по дорожке. Однако его техническая реализация может позволять указателю отклоняться от неё после захвата. Тогда оценка жеста отличается от случая, где выход за дорожку немедленно прерывает действие. Если команда не знает поведения компонента, это вопрос для исследования, а не готовый ответ по скриншоту.
В нашем учебном задании проще проверять явно описанный путь: нажать кнопку и выбрать назначение. Удерживать контакт, рисовать линию и проводить пальцем вдоль карточки не требуется. Это проектное условие предстоит подтвердить на стенде после реализации.
Какие варианты показывает первичный документ?
Техника W3C G219 описывает несколько примеров. В списке можно показывать кнопки перемещения вверх и вниз. На доске задач — меню выбора другого раздела. Для числового значения возможно поле ввода. Общая идея — выполнить ту же функцию одним или несколькими нажатиями без перетаскивания.
Выбирайте вариант по функции, а не по похожей картинке. Если пользователь должен назначить карточку в раздел, кнопка «вверх» сама по себе ещё не объясняет, куда она попадёт. Если нужно установить точное значение, пошаговое перемещение может потребовать другого решения. Конкретные условия согласует команда, затем проверяет их.
Техники W3C — примеры способов выполнения требований. Они сами по себе не обязательны; существование другого соответствующего решения возможно. Не превращайте приведённый пример меню в требование «у каждой карточки непременно должно быть такое меню».
Процедура G219 предлагает найти функции с перетаскиванием и проверить наличие альтернативы одним указателем без перетаскивания для той же функции. Если выбранная техника не реализована, это ещё не исключает выполнение критерия иным способом. Для заключения нужны условия нормативного требования и фактическая реализация.
Что проверить на готовом стенде?
Начните с согласованной версии компонента. Запишите адрес, браузер, устройство или способ ввода и исходное положение карточки. Используйте тестовые данные, где разрешены такие действия. Если стенда нет, можно сдать подготовленную спецификацию, но нельзя подписывать её как выполненное испытание.
Ниже строки самостоятельных сценариев. Перед каждой восстановите указанное состояние. Таблица задаёт ожидания учебного примера; реальные результаты здесь не сообщаются.
| Начальное состояние | Действие без перетаскивания | Ожидание по нашему заданию |
|---|---|---|
| Карточка в «Подготовке», выбор закрыт | Щёлкнуть «Переместить» | Доступен выбор разрешённых разделов |
| Карточка в «Подготовке», выбор открыт | Щёлкнуть «Проверка» | Та же карточка в «Проверке», название и текст сохранены |
| Карточка в «Проверке», выбор закрыт | Нажать «Переместить», затем «Подготовка» | Та же карточка возвращена в исходный раздел |
| Карточка перенесена | Прочитать состояние задания до отправки | Сам перенос не отправил ответ |
Для каждой строки укажите наблюдение после выполнения. Фраза «кнопка существует» не подтверждает перенос. Возможно, меню открылось, но выбор раздела требует снова тащить карточку. Возможно, визуально объект переместился, а сохранённый результат остался прежним. Последнее проверяют по согласованному механизму сохранения, если он предусмотрен реальным компонентом.
Проверьте итоговую функцию, не только первый шаг.
Пример карточки замечания: «На тестовой версии карточка находится в “Подготовке”. После щелчка “Переместить” открывается выбор. Щелчок “Проверка” не меняет раздел; перенос получается только удержанием и движением». Это вымышленный образец записи. В реальном отчёте нужны фактическая версия и последовательность действий проверяющего.
Не назначайте причину по такому описанию. Отключённый обработчик, ограничение прав и несохранённое состояние требуют технического разбора. Нейросеть может помочь отредактировать ясное наблюдение; это не делает её ответ диагностикой кода.
Как разобраться с исключениями?
В первичном требовании существенность означает, что удаление свойства принципиально изменит информацию или функцию и их нельзя получить другим соответствующим способом. «Так привычнее» и «компонент из библиотеки» не являются таким определением.
Для обычной учебной сортировки сначала выясняют, что именно оценивает задание. Если цель — распределить действия по этапам, важно сохранить распределение. Если предполагается специальная деятельность, где само движение является предметом работы, специалисту нужно разобрать её назначение и основание исключения. Модель не может разрешить исключение только по слову «тренажёр».
Есть и граница ответственности за пользовательский агент. Разъяснение отделяет собственную прокрутку браузера от механизма, который перехватывает или реализует автор содержимого. Обычная прокрутка области через браузер и специально написанный автором механизм требуют разных исходных сведений. Не записывайте любое движение страницы как отказ по этому критерию.
Сохраните вопрос, если данных недостаточно.
В карточке обсуждения укажите функцию, кто обрабатывает движение и почему команда считает перетаскивание существенным, если она ссылается на исключение. Приложите описание реализации и оставшиеся неизвестные. Это наша рабочая форма обсуждения, а не автоматическое подтверждение соответствия.
Как принять работу сотрудника?
Попросите коллегу сопоставить спецификацию, ответ ИИ и наблюдения на стенде. Он должен понять, какой объект перемещался, какой результат ожидался и каким способом действие было выполнено. Если сотрудник сдал только красивое описание меню, практическая часть ещё не завершена.
После исправления повторите те же условия на новой версии. Сохраните прежнее замечание и новый результат. Сообщение разработчика «готово» даёт повод для повторной проверки, но не заменяет её.
Такое упражнение можно включить в корпоративное обучение ИИ: участник готовит спецификацию с моделью, коллега проверяет источник и выполняет сценарии. Приёмка относится к качеству этой конкретной работы. Из неё не следует обещание результатов обучения или подтверждение доступности всего сайта.
Частые вопросы
Нужно ли полностью убирать drag-and-drop?
Из рассматриваемого требования не следует общий запрет перетаскивания. Нужен соответствующий способ получить ту же функцию одним указателем без него, с учётом исключений. В нашем примере оба способа сохраняют перенос одной карточки.
Несколько щелчков допустимы?
Да. G219 прямо описывает один или несколько одиночных вводов, например открытие меню и выбор назначения. Проверять нужно всю последовательность и тот же результат; один указатель не означает единственное нажатие.
Крупные кнопки уже решают проблему?
Размер области нажатия и наличие альтернативного способа действия — разные проверки. Большая карточка, которую всё равно обязательно тащить, не становится альтернативой без перетаскивания. Геометрию управления оценивают отдельно.
Можно ли подтвердить результат ответом ИИ?
Нет. В нашем упражнении модель готовит спецификацию и черновик сценариев. Фактическую работу проверяет человек на согласованной версии. Если испытание не выполнялось, сохраните статус «не проверено».
Источники
- W3C: Dragging Movements — требование, клавиатурный эквивалент и исключения — .
- W3C: G219 — примеры альтернатив и процедура проверки — .
- W3C: Pointer Gestures — отличие жеста с траекторией от перетаскивания — .
