ARIA Альтернатива меткам, которые используют очень очень длинный идентификатор элемента формы

Question

Я добавляю различные стандарты доступности в нашу инфраструктуру пользовательского интерфейса платформы предприятия.Мы используем веб-клиент, элементы DOM и т. Д. Мы визуализируем всю структуру в DOM, но клиенты могут (и годами) собирать виджеты в структуре нестандартными способами для создания различных страниц своего пользовательского интерфейса..

Мне удалось охватить и обработать большую часть спецификаций (я думаю), но у меня есть конкретный случай, когда у нас есть «текстовые лабиринтные виджеты», которые используются для описания различных «входных / формоподобных виджетов».».Единственное, что их связывает с DOM, - это общий родительский элемент-контейнер, переменное расстояние до дерева.

Рекомендации ARIA, с которыми я сталкиваюсь (которые в любой момент могут быть неправильно поняты), предполагаютМне нужно использовать aria-labeledby="id_of_text_label_widget" для фактического элемента формы.Я имею в виду следующее:

<div id="parent_label_value_widget_001">
  <div class="inputLabel">This is visible Label Text</div>
  <div class="various_other_junk_in_here"></div>
  <div class="some_wrapper_around_the_input">
    <input id="I_am_the_form_input_in_question_with_a_very_long_id" value="42">
  </div>
</div>

Я мог бы легко добавить атрибут aria-labeledby к входу, но это означает, что мне нужно добавить идентификатор к элементу inputLabel.И хотя это кажется не таким уж большим делом (это немного сложнее, потому что то, что вы видите в DOM, является результатом гораздо более сложного цикла рендеринга из WYSIWYG-редактора отключенных виджетов), это происходит без возможности изменения, что наши идентификаторы уже невероятно длинны.Из-за огромных страниц, иногда десятков тысяч полей и вложенных динамических объектов и т. Д.

Наши идентификаторы составляют 60% нашей полезной нагрузки.И мне фактически пришлось бы удвоить этот кусок, добавив новый идентификатор к каждому элементу метки, и наш контент не распакован.Вот чего я пытаюсь избежать.На самом деле я также не хочу делать это по другим причинам, поскольку виджет метки и виджет ввода фактически ничего не знают друг о друге, поэтому мне пришлось бы написать дополнительную логику рендеринга, чтобы виджет ввода извлекал идентификатор изВиджет метки родного брата.

Мой вопрос: есть ли у кого-нибудь другие решения?

Вещи, которые я себе представлял: A. Есть ли какая-то техника, использующая метку aria,где я мог бы пометить родительский контейнер и чтобы программы чтения с экрана знали, как связать внутреннюю метку и ввод?

B.Я мог бы продублировать текст метки из виджета метки на виджет ввода и использовать aria-label="duplicated text".Я мог бы сделать это на стороне сервера с некоторой болью, или на стороне клиента с некоторой неуклюжей логикой ходьбы, но я бы предпочел избежать дублирования и дополнительной логики.Но если я это сделаю, то мне нужно скрыть все существующие виджеты ярлыков?

C.Есть ли какое-нибудь сокращение для <label for=""> или aria-labeledby="", где вместо идентификатора он может ссылаться на элементы с помощью селектора css или близости?(Сновидения, я знаю), но это выстрел.

D.Сделайте так, чтобы пользователь включил поддержку aria, и только тогда он получит удвоенный размер пакета.(да, я знаю, что gzip многое решит, но это длинная история, почему ее нет на месте).

Answer 1

Короткий ответ: элементам <input> нужна какая-то метка, и эта метка должна быть напрямую связана или "привязана" к <input>.«Близость» не является прямой ассоциацией.То есть, просто потому, что метка «близка» к входу в DOM, это не связывает два элемента вместе.

Некоторые программы чтения с экрана будут пытаться найти какой-либо текст для использования в качестве метки, если он явно не найден, но это обычно подразумевает переход к предыдущему брату <input> в DOM и если этот брат имееткакой-то текст, связанный с ним, затем относитесь к нему как к метке.Иногда это работает, а иногда нет.Я бы не стал на это полагаться.

Например,

<label>password</label>
<p>should contain upper and lower case letters, a number, and a special character</p>
<input>

В этом случае текст «должен содержать ...» будет считаться меткой ввода, что неверно.Неважно, что до <p> есть элемент <label>.В DOM нет ничего, связывающего <label> с <input>.Приведенный выше пример должен быть записан как:

<label for="pw">password</label>
<p id="rules">should contain upper and lower case letters, a number, and a special character</p>
<input id="pw" aria-describedby="rules">

Это связывает оба текстовых элемента с вводом.<label> связывается напрямую через атрибут for (и идентификатор на <input>), а описание пароля связывается с помощью aria-describedby на <input>.

Так чтопервый выбор маркировки ввода должен быть с нативным HTML, если это возможно.Используйте атрибут for для <label>.

Другой способ пометить, как вы заметили, это использование aria-label или aria-labelledby на самом <input>.Хотя это даст вводное доступное имя для программ чтения с экрана, это не поможет зрячим пользователям.aria-label не видимая вещь.Однако, в вашем случае, похоже, что уже есть визуальный ярлык (даже если он официально не «привязан» к входу).

Итак, чтобы прокомментировать ваши четыре предложения (AD):

* * 1040 A.Вы можете поместить aria-label в родительский контейнер, но <input> все равно нужно будет указать родительскому элементу, чтобы получить метку, и это сделано с aria-labelledby для <input> (и потребуется идентификатор народитель, чтобы вы могли указать на него.).

B.Если вы поместите aria-label непосредственно на <input>, тогда да, вы должны установить aria-hidden="true" на видимой метке, в противном случае пользователь программы чтения с экрана может перейти к тексту видимой метки, а затем перейти к вводу и услышать то же самое.Снова текстНо это странное решение.Если текст уже виден, лучше всего поместить идентификатор в видимый текст и связать его с <input> через aria-labelledby.

C.Стоит коротко, но нет.

D.Это дружественное место, поэтому все идеи будут рассмотрены, но, пожалуйста, не делайте этого.Не разделяйте пользователей разных типов и не заставляйте людей подписываться на доступный сайт.

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