Видимая метка в доступном имени с нейросетью проверяется по двум отдельным строкам: что человек видит на кнопке и какое имя фактически получает вспомогательная технология. ИИ помогает сопоставить выгрузку, но вычисленное имя берут из работающей страницы. Результат упражнения — реестр расхождений с подтверждённой повторной проверкой, а не список красивых названий.
Почему правильного текста на кнопке недостаточно?
На условной учебной странице кнопка называется «Открыть материалы». В разметке ей присвоено другое имя — «Перейти к ресурсам». Оба выражения понятны редактору, однако для человека, который произносит видимую надпись, это разные команды. Заменить одно выражение синонимом здесь недостаточно: нужно проверить связь двух представлений одного элемента.
Пояснение W3C к Label in Name рассматривает именно эту связь. У интерактивного компонента с видимой текстовой меткой доступное имя должно содержать представленный текст. Начинать имя с видимой метки документ рекомендует как хорошую практику; это не отдельное безусловное требование к началу строки.
Факт. В примере техники W3C G208 атрибут aria-label переопределяет текст кнопки при формировании доступного имени. Поэтому сравнивать только надпись и содержимое HTML-элемента недостаточно.
Не добавляйте такой атрибут автоматически «для доступности».
Сначала определите, какая информация уже формирует имя и действительно ли нужно дополнение. В этой статье мы не рассчитываем весь алгоритм имени вручную и не проводим полный аудит WCAG. Учимся находить конкретный конфликт: видимый текст есть, но соответствующей строки в имени нет. Порядок работы с ИИ предложен редакцией, а первичные документы объясняют критерий и примеры его проверки.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Соберите две строки из одного состояния страницы
Выберите небольшой учебный фрагмент без персональных данных. Подойдут кнопка открытия материалов, ссылка на программу и кнопка сохранения ответа. Это вымышленный пример, не проверка сайта AURMIND или клиента. Результаты ниже заданы для упражнения; они не выдаются за замеры реального интерфейса.
Для каждого элемента сохраните видимую метку, вычисленное доступное имя, адрес или идентификатор компонента и состояние страницы. Разработчик получает имя через средства проверки доступности браузера. Редактор фиксирует надпись на экране. Если есть только скриншот, имя остаётся неизвестным: модель не может восстановить скрытые связи по внешнему виду.
Не заполняйте пробел предположением.
Слово «Отправить» на макете ещё не доказывает, что так же называется кнопка в дереве доступности. И наоборот, найденный в исходнике aria-label — основание проверить вычисление, а не универсальная гарантия итогового имени сложного компонента. Сохраняйте фактическое значение и контекст, в котором его получили.
| Элемент учебного примера | Видимая метка | Заданное доступное имя | Предварительный разбор |
|---|---|---|---|
| Кнопка материалов | Открыть материалы | Перейти к ресурсам | Видимой строки в имени нет |
| Ссылка на программу | Программа | Программа практикума | Видимая строка сохранена целиком |
| Кнопка сохранения | Сохранить ответ | Сохранить учебный ответ | Внутрь видимой строки вставлено слово |
| Кнопка с иконкой без текста | Нет текстовой метки | Закрыть окно | Вне узкой проверки Label in Name |
Последняя строка не означает, что кнопка проверена и доступна. Пояснение W3C говорит, что при отсутствии видимой текстовой метки данный критерий не применяется к компоненту. Требования к наличию имени и другим свойствам остаются отдельной задачей. В нашем реестре такой элемент получает пометку «передать в другой объём проверки», а не «всё исправно».
Если нужно сначала подготовить сами названия полей и связь с вводом, используйте упражнение по подписям полей формы. Здесь исходная метка уже определена: мы сравниваем её с другим представлением того же элемента, сохраняя назначение действия.
Схема показывает исходную метку, конфликтующее имя и предлагаемый результат. Она не изображает реальные инструменты браузера и не является квитанцией выполненной проверки.
Как поручить ИИ сравнение без выдуманных результатов?
Передайте таблицу вместе с правилом и границами упражнения. Отделите фактически полученные строки от проектируемых вариантов. Сотрудник должен видеть, где он скопировал значение из страницы, а где согласовал будущую правку.
Предлагаемый запрос:
Сравни видимую текстовую метку и вычисленное доступное имя каждого элемента. Сохраняй исходные строки дословно в отдельных колонках. Отмечай отсутствие видимой строки, вставку слов внутрь неё и нехватку данных. Для обычных текстовых меток предложи вариант имени, сохраняющий видимую строку целиком. Не меняй назначение кнопки, URL или обработчик. Не объявляй соответствие всей страницы WCAG. Не придумывай результаты голосовой проверки. Элементы без видимой текстовой метки вынеси отдельно. Верни причину замечания, предложение и вопрос разработчику.
Полезный ответ для первой строки: «Видимая метка “Открыть материалы” отсутствует в имени “Перейти к ресурсам”. Предложение: имя “Открыть материалы”. Уточнить, какой механизм задаёт текущее имя». Ответ «заменить надпись на более удобную» не решает исходную задачу, поскольку незаметно меняет утверждённый пользовательский текст.
Для третьей строки модель должна заметить разрыв последовательности. В разборе ошибки F96 есть аналогичный случай: скрытое слово помещено между словами видимой ссылки. Все слова метки по отдельности могут присутствовать, но цельная строка нарушена. Наше «Сохранить учебный ответ» поэтому нельзя принять лишь по наличию слов «Сохранить» и «ответ».
Мнение. В учебном разборе лучше сохранить короткое имя без добавлений, если согласованная надпись уже точно называет действие. Дополнительный контекст имеет смысл обсуждать по конкретной потребности, а не ради более длинного ответа модели.
Попросите ИИ объяснить каждое замечание исходной парой строк. Если объяснение ссылается на несуществующий атрибут или обещает, что «любой голосовой помощник теперь сработает», верните ответ на исправление. Эта задача не содержит данных для подобного обещания.
Что считать совпадением, а что требует разбора?
Для наших обычных меток «Программа» и «Программа практикума» связь сохраняется: видимое слово входит в начало имени. Вариант «Материалы практикума» вместо «Программа» меняет строку, даже если обе ссылки ведут к близким разделам. Семантическое сходство не заменяет проверку текста.
Но побайтовое равенство тоже нельзя объявлять универсальным правилом критерия. В пояснении W3C различия регистра и большинства знаков пунктуации не считаются существенными для этой оценки. Например, документ допускает имя без двоеточия из видимой подписи. Для рабочего реестра сохраняйте исходные символы, чтобы специалист мог проверить конкретный случай, а не молча «нормализовать» всё подряд.
Рекомендация начинать имя с видимой метки облегчает наш учебный разбор. Она не даёт оснований отвергать любой вариант, в котором видимая строка находится дальше. Разделяйте обязательное содержание имени и предпочтительный порядок добавленного контекста. Иначе ИИ превратит рекомендацию в более жёсткое выдуманное правило.
Особые случаи выносите из автоматического сравнения. Пояснение W3C отдельно рассматривает символические знаки, формулы и текст в скобках. Буква на кнопке форматирования может обозначать функцию, а не произносимую метку. Не пытайтесь решить всё одной командой «имя должно содержать все видимые символы». Для первого упражнения оставьте обычные словесные кнопки и ссылки; сложные случаи передайте специалисту с исходной разметкой.
И не удаляйте пояснение только потому, что его нет в имени.
Имя и описание — разные свойства. В G208 отмечено, что дополнительный контекст иногда уместнее передавать через доступное описание, в том числе aria-describedby. Пояснение Label in Name уточняет, что этот атрибут не входит в вычисление имени. Проверять доступность важной инструкции нужно отдельно; перенос в описание не должен означать её исчезновение для пользователя.
Исправляйте причину конфликта вместе с разработчиком
Реестр должен вести к конкретной правке. Для кнопки «Открыть материалы» разработчик выясняет, откуда взялось «Перейти к ресурсам»: явный атрибут, ссылка на другой текст или логика компонента. Не поручайте модели убрать все ARIA-атрибуты на странице. Такое изменение затронет элементы, которых в упражнении вообще нет.
Согласованное предложение относится к одному компоненту. Если обычная кнопка уже получает нужное имя из своего текста, специалист может проверить возможность убрать ненужное переопределение. Если дополнительный контекст требуется, предложите вариант, в котором видимая строка сохранена целиком. Выбор реализации остаётся за разработчиком, который проверяет её последствия.
Для «Сохранить ответ» учебное предложение — имя «Сохранить ответ». Вариант «Сохранить ответ практикума» также сохраняет исходную строку, но добавление должно иметь смысл в реальной задаче. Не принимайте его автоматически: сначала выясните, нужна ли эта информация для различения элементов. Мы не утверждаем, что любое расширение имени полезно.
Менять видимую метку тоже можно только как отдельное согласованное редакторское решение. Если владелец действительно хочет «Сохранить учебный ответ», обновите и видимый текст, и проверку имени. Нельзя скрытно подгонять исходные условия под уже полученный ответ ИИ. В журнале должны остаться прежняя пара, причина изменения и новая пара.
Три элемента схемы обозначают этапы протокола. Пока разработчик не получил новое значение из работающего компонента, в графе результата нельзя писать «совпадает».
Как оформить повторную проверку?
После изменения откройте ту же страницу в том же состоянии и снова получите обе строки. Запишите версию материала, элемент, видимую метку и вычисленное имя. Сравнение проводят по новым фактам: сохранённое старое имя не доказывает состояние после правки. Для динамической кнопки зафиксируйте также состояние до и после изменения надписи, если оба входят в проверяемое задание.
Отдельно выполните проверку в согласованной среде голосового управления, если она включена в объём работы. Укажите инструмент, язык, произнесённую команду и фактическое действие. Успех одной команды в одной среде не превращается в гарантию работы всех программ. Неудача также требует разбора: реестр строк и запись окружения помогают не смешивать разные причины.
| Запись протокола | Что должно быть сохранено |
|---|---|
| Исходное расхождение | Две первоначальные строки и конкретный компонент |
| Предложение | Новый вариант имени и основание изменения |
| Реализация | Какая версия проверена и что изменил разработчик |
| Повторное получение | Новая видимая метка и фактическое вычисленное имя |
| Голосовой сценарий | Среда, команда и наблюдение либо честное «не выполнялся» |
| Решение | Закрыт конкретный конфликт или перечислены оставшиеся вопросы |
Не ставьте отметку «не выполнялся» в одну категорию с успешным тестом. Это ограничение объёма, которое нужно сохранить при передаче работы. Точно так же таблица совпадающих имён не подтверждает порядок фокуса, контраст, размер целей или все остальные требования доступности.
Если соседняя задача касается обещанного назначения перехода и реального адреса, её можно разобрать по реестру текстов ссылок. Здесь URL остаётся исходным, а основание замечания — несовпадение двух текстовых представлений компонента.
Как принять учебную работу команды?
Дайте сотруднику четыре строки нашего примера без готовых замечаний. Пусть он сам объяснит конфликт синонимов, сохранение строки в «Программа практикума», вставку слова внутрь «Сохранить ответ» и ограничение для иконки без текстовой метки. После ответа ИИ попросите показать, какие выводы опираются на данные, а какие ещё требуют получения имени из страницы.
Хорошая работа содержит не только исправленные слова. В ней видны исходник, причина, согласованное предложение и доказательство повторной проверки. Отсутствующее доказательство отмечено открытым вопросом. Сотрудник не выдаёт предполагаемое поведение за замер и не подменяет одну проверку заявлением о соответствии стандарту.
Фактическая основа статьи — три первичных документа W3C об одном критерии. Это три документа одного издателя, а не измерение спроса или сравнение нейросетевых сервисов. Документы не подтверждают качество определённой модели. Таблица и промпт предложены редакцией для ограниченного учебного упражнения.
Если команда готовит интерфейсы и учебные материалы, такое задание можно включить в корпоративное обучение работе с ИИ. Для обсуждения подготовьте пример компонента, роли редактора и разработчика и перечень того, что нужно проверять вручную. В упражнении ИИ помогает разобрать записи, а принятие результата остаётся за людьми.
Частые вопросы
Можно ли вычислить доступное имя по одному скриншоту?
Нет: в нашем упражнении изображение подтверждает только видимую метку. Имя нужно получить из реализации. Если данных нет, запись остаётся открытой, даже когда модель предложила убедительное объяснение.
Нужно ли всегда добавлять aria-label?
Нет. G208 показывает, что атрибут может переопределять текст кнопки и создавать расхождение. Сначала специалист проверяет фактическое имя и его источник, затем выбирает согласованную правку конкретного элемента.
Обязано ли имя полностью совпадать с видимой меткой?
Критерий требует включения видимого текста, а не безусловного равенства строк. G208 допускает дополнительный контекст с сохранением целой метки. Начало имени с видимой строки — рекомендуемая практика; регистр и большинство знаков пунктуации рассматриваются отдельно в пояснении W3C.
Доказывает ли такой реестр полную доступность?
Нет. Он описывает ограниченный конфликт метки и имени на определённой версии. Другие свойства компонентов, сценарии работы и требования нуждаются в самостоятельной проверке.
Источники
- W3C: Label in Name — критерий, границы применения и особенности сравнения — .
- W3C: G208 — включение видимой метки целиком в доступное имя — .
- W3C: F96 — ошибки из-за несовпадения и вставки скрытого текста — .
