Не нужно блокировать кнопки

от автора

Одна из наиболее распространенных проблем доступности, которую я нахожу (и исправляю) в проектах своих клиентов – это динамическое блокирование кнопок в формах после отправки последних. Сегодня я хотел бы рассказать, почему разработчики так делают, почему это не работает и что нужно делать вместо этого. Давайте разбираться!

Почему разработчики деактивируют кнопки

По моим наблюдениям, паттерн используется для того, чтобы исключить возможность повторной отправки формы в процессе ожидания, пока обрабатывается первая. Часто случается, что нужно дождаться ответа API и на это требуется несколько секунд; нежелательно, чтобы пользователь успел отослать еще одну форму, пока система не закончит реагировать на предыдущую.

form.addEventListener('submit', function (event) {  // Don't let the form reload the page event.preventDefault();  // Get the submit button and disable it let btn = form.querySelector('button'); btn.addAttribute('disabled', '');  // Do more form stuff...  // re-enable the button after the API responds btn.removeAttribute('disabled');  });

При блокировании button еще раз нажать на кнопку не получится.

Почему этот паттерн не работает

Начнем с того, что он не делает того, на что рассчитан. Одно то, что кнопка блокирована, не означает, что отправить форму становится невозможно. Можно перейти на какое-нибудь из полей формы, нажать на клавишу enter или return – и форма будет отправлена.

Но, помимо этого, метод никуда не годится с точки зрения доступности. Элементы с атрибутом disabled не могут принимать на себя фокус, а это создает путаницу для тех, кто использует скринридеры или перемещается по вебсайтам при помощи клавиатуры.

Если кнопка находится в фокусе в тот момент, когда вы задаете ей атрибут disabled (скажем, пользователь только что нажал на нее, чтобы отправить форму), то фокус переходит с нее на элемент document. Человека со скринридером это собьет с толку – он окажется совершенно в другой части страницы.

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

Более удачный способ

Что же тогда делать? Лично я предпочитаю добавлять атрибут для элемента form, а затем убирать его, когда все необходимые действия с формой будут произведены. Всякий раз, когда происходит событие submit, в первую очередь проводится проверка на наличие атрибута. Если он в наличии, я прерываю обработчик событий, чтобы предотвратить многократную отправку формы.

form.addEventListener('submit', function (event) {  // Don't let the form reload the page event.preventDefault();  // If the form is already submitting, do nothing if (form.hasAttribute('data-submitting')) return;  // Add the [data-submitting] attribute to stop multiple submissions form.setAttribute('data-submitting', '');  // Do more form stuff...  // Remove the [data-submitting] attribute form.removeAttribute('data-submitting');  });

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

Вдобавок вы можете придать элементам особый «деактивированный» вид при помощи CSS-селектора [data-submitting]…

[data-submitting] button { opacity: 0.8; }

Не забывайте также включать ARIA live region и отображать оповещения о статусе обработки формы на протяжении всего процесса.


ссылка на оригинал статьи https://habr.com/ru/articles/775648/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *