Решение проблемы обеспечения доступности модального окна для людей с ограниченными возможностями

[dopusteam]

При закрытии всем выставляете tabIndex 0? Но ведь там могли быть другие значения

[dharbachou]

Могут быть, для этого можно просто расширить алгоритм и сохранять значения в момент постройки модального окна, а потом их возвращать, но так как рекомендуемые значения tabidex = [-1, 0], то я просто решил немного схитрить. В реальности же лучше все же их запоминать.

[abyssSoft]

Интересная реализация… «в лоб». Но я бы поостерегся так делать. Смотрите, если это большой проект, то у него есть спецификация от СЕО, как именно должны быть расставлены tabIndex (чтобы элементарно «вести» клиента). А мы тут рраааззз и сбросили все. Я думаю что тут найдется немало людей, которые получали за подобные инновации в юности.

Если уж сбрасывать таким методом, то перед сбросом нужно обязательно сохранять текущие значения tabIndex, а потом уж их восстанавливать.

[dharbachou]

Использование tabidex для маскировки недочетов разметки такая себе идея.
Про сохранение вы правы, но не стоит использовать значения вышле 0, это может все поломать в корне для человека, пользуещесогя программами чтения с экрна.

[leutsky]

некоторые проблемы такого решения:

• потеря оригинального значения tabIndex — это может сломать UX (обход при смене фокуса станет последовательным, а не таким, как задуман)
• tabIndex не всегда равен -1, а может быть задан любым отрицательным числом — таким образом, могут появиться элементы, которые начнут получать фокус (например, при tab) после закрытия модального окна
• препятствование сборщику мусора, да и потенциальное место для утечки памяти. У современной страницы DOM-дерево весьма динамично может меняться — это может привести к тому, что в this.interactiveElementsList и в this.blockElementsList могут остаться ссылки на уже удалённые из дерева элементы, но сборщик мусора их не удалит, пока не закроется модалка (а она может просто "упасть" из-за какой-то ошибки)
• на реальной странице может быть очень много элементов, которые могут получать фокус — обработка всех этих элементов перед открытием модалки — пустая трата ресурсов.
• внутри contains может проверяться много элементов (зависит от сложности DOM-дерева) — это приведет ещё к доп.нагрузке.

Стоит смотреть в сторону перехвата и перенаправления фокуса. Тут будут свои подводные камни, но это менее ресурсоёмкий подход.

Попробуйте такой простой код:

<button id="b1">Button 1</button>
<button id="b2">Button 2</button>
<button>Button 3</button>

<script>
  const b1 = document.getElementById('b1');
  const b2 = document.getElementById('b2');
  b2.addEventListener('blur', () => b1.focus());
</script>

Кнопка №3 не получит фокус при Tab, а само переключение фокуса будет ограничено между первых двух кнопок. Тоже самое можно сделать и с модальным окном — залочить фокус внутри него.

пару ссылок
https://github.com/theKashey/focus-lock
https://github.com/theKashey/react-focus-lock

[dharbachou]

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

Значение -1 используется что бы убрать элемент из навигации, меньше этого значения просто нет смысла применять значения.

Если мы используем значения tabindex что бы улучшить навигацию по сайту, то стоит задуматся над исправлением верстки, которая скорее всего была выполненна неверно.

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

[mx2828ru]

как пример для обучения да, в практике это еще хуже чем jquery юзать

[dharbachou]

Добрый день!

Был бы рад прочитать ваши суждения, почему иммено вы так считаете.
В свое время, jquery был практически незаменим при разработки веб приложений, да и на данный момент находится применение jquery. Всему своё место.