Перейти к основному содержимому

Контактная форма по EAA: пошаговое руководство для веб-разработчиков

Европейский акт о доступности (EAA) [1] вступил в силу и ставит цифровую доступность в центр внимания. Для Вас как разработчика это означает: каждый элемент, особенно контактная форма, должен быть доступен для использования абсолютно каждому. Недоступная форма — это не только юридический риск, но и упущенная возможность связаться с потенциальными клиентами [2].

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

Вот живая демонстрация готовой, доступной контактной формы:

Демонстрационная контактная форма

Все поля, отмеченные звездочкой (), обязательны для заполнения. При отправке сообщения, если нет ошибок, появится сообщение об успехе, но больше ничего не произойдет.

Ваши личные данные
Действительный адрес электронной почты состоит из имени, знака "@" и домена (например, ivan.ivanov@example.tld).
Для возможных обратных звонков. Только действительные немецкие номера мобильных телефонов из 7-11 знаков (например, 01701234567).
Предпочтительный способ связи

Основная структура и инструкции​

Основу любой доступной формы составляет чистый, семантический HTML. Это начинается с правильной связи меток (<label>) с их полями ввода (<input>).

Каждое поле требует постоянно видимой <label> [3], которая связана с id поля через атрибут for [4]. Заполнители, которые исчезают при вводе, не являются заменой метки [5]. На Рисунке 1.1 Вы видите примерную структуру доступной формы, которую мы будем создавать далее.

Кроме того, Вы должны размещать общие инструкции, такие как обозначение обязательных полей, перед формой, чтобы пользователи знали, что их ожидает [6]. Метки полей ввода также должны располагаться перед полем [7].

Открыть текстовое описание для "Схематическая базовая структура доступной формы"

Эта диаграмма показывает основные строительные блоки формы.

  1. Контактная форма: Самый внешний элемент, который все включает. Он содержит инструкции, обзор ошибок, группы полей (Fieldsets) и кнопку «Отправить».
  2. Группы полей (<fieldset>): Служат для группировки связанных полей ввода. Они содержат подпись (<legend>) и сами поля ввода.
  3. Поля ввода: Каждое поле состоит из подписи (<label>), связанной с полем ввода (<input>). Дополнительно может быть помощь при вводе, предоставляющая дополнительную информацию о поле.

Вот пример кода для основной структуры:

HTML: Основная структура формы
<p id="form-instructions-demo">
  Все поля, отмеченные звездочкой (*), являются обязательными.
</p>

<div
  id="error-summary-demo"
  class="contact-form__error-summary"
  role="alert"
  tabIndex="-1"
  hidden
  aria-labelledby="error-summary-title-demo"
>
  <h2 id="error-summary-title-demo">Ваши данные содержат ошибки</h2>
  <p id="error-summary-intro"></p>
  <ul class="contact-form__error-summary-list">
    </ul>
</div>

<form id="contact-form-demo" class="contact-form__form" novalidate>
  <div class="contact-form__group">
    <label for="fname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Ошибка: </span>
      Имя*
    </label>
    <input
      type="text"
      id="fname-demo"
      name="fname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="fname-error-demo"
      class="contact-form__input"
    />
    <div
      id="fname-error-demo"
      class="contact-form__error-message"
      hidden
    ></div>
  </div>
  <button type="submit" class="contact-form__submit-button">
    Отправить сообщение
  </button>
</form>

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

Порядок фокуса и видимость для управления с клавиатуры​

Форма, которой нельзя управлять без мыши, не является доступной. Здесь важны два критерия:

  1. Логический порядок фокуса: Пользователи, навигирующие с помощью клавиши Tab, должны иметь возможность перемещаться по форме в логической и интуитивно понятной последовательности [9]. При чистой структуре HTML (сверху вниз) это обычно обеспечивается автоматически. Более сложные макеты (например, с CSS Grid или Flexbox) должны быть проверены на это.

  2. Видимый фокус: Каждый интерактивный элемент (Input, Button, Link) должен показывать четко видимый индикатор, когда он получает фокус [10]. Это индикатор «Вы находитесь здесь» для пользователей клавиатуры. Никогда не скрывайте стиль outline без предоставления лучшей, четко видимой замены.

Логическая группировка полей ввода​

Связанная информация (например, «Имя» и «Фамилия» или группа радиокнопок) также должна быть программно распознаваема как группа [11]. Для этого Вы используете <fieldset> и <legend> [12] или, в качестве альтернативы, ARIA-роли, такие как role="group" [13].

<fieldset> окружает группу, а <legend> дает ей имя, которое считывается скринридером [12]. Без этой структуры пользователям вспомогательных технологий приходится гадать, какие поля образуют тематический блок.

HTML: Группировка полей с помощью <fieldset>
<fieldset class="contact-form__fieldset">
  <legend class="contact-form__legend">Ваши личные данные</legend>

  <div class="contact-form__group">
    <label for="fname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Ошибка: </span>
      Имя*
    </label>
    <input
      type="text"
      id="fname-demo"
      name="fname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="fname-error-demo"
      class="contact-form__input"
    />
    <div id="fname-error-demo" class="contact-form__error-message" hidden></div>
  </div>

  <div class="contact-form__group">
    <label for="lname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Ошибка: </span>
      Фамилия*
    </label>
    <input
      type="text"
      id="lname-demo"
      name="lname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="lname-error-demo"
      class="contact-form__input"
    />
    <div id="lname-error-demo" class="contact-form__error-message" hidden></div>
  </div>
</fieldset>

<fieldset
  class="contact-form__fieldset"
  aria-describedby="contactMethod-group-error-demo"
>
  <legend id="contactMethod-legend" class="contact-form__legend">
    <span class="contact-form__error-prefix" hidden>Ошибка: </span>
    Предпочтительный способ связи*
  </legend>
  <div class="contact-form__radio-group">
    <label for="contact-pref-email-demo" class="contact-form__radio-label">
      <input
        type="radio"
        id="contact-pref-email-demo"
        name="contactMethod"
        value="email"
        required
        aria-required="true"
        class="contact-form__radio-input"
      />
      По электронной почте
    </label>
    <label for="contact-pref-phone-demo" class="contact-form__radio-label">
      <input
        type="radio"
        id="contact-pref-phone-demo"
        name="contactMethod"
        value="phone"
        required
        aria-required="true"
        class="contact-form__radio-input"
      />
      По телефону
    </label>
  </div>
  <div
    id="contactMethod-group-error-demo"
    class="contact-form__error-message"
    hidden
  ></div>
</fieldset>

Вспомогательные тексты и помощь при вводе​

Иногда полям требуются дополнительные пояснения, например, о конкретном формате. Эти вспомогательные тексты должны быть программно связаны с полем.

Для этого вспомогательный текст получает id, а элемент <input> получает атрибут aria-describedby, который ссылается на этот id [14]. Скринридер сначала считывает метку, а затем вспомогательный текст.

Чтобы еще больше упростить ввод, Вы должны использовать атрибут autocomplete [15]. Он позволяет браузеру автоматически предлагать известные данные (имя, электронную почту и т. д.). Это не только удобно, но и является явным требованием [16].

HTML: Вспомогательные тексты и Autocomplete
<div class="contact-form__group">
  <label for="phone-demo" class="contact-form__label">
    <span class="contact-form__error-prefix" hidden>Ошибка: </span>
    Номер мобильного телефона (Необязательно)
  </label>
  <input
    type="tel"
    id="phone-demo"
    name="phone"
    autocomplete="tel"
    aria-invalid="false"
    aria-describedby="phone-hint-demo phone-error-demo"
    class="contact-form__input"
    placeholder="напр.: 01701234567"
  />
  <span id="phone-hint-demo" class="contact-form__help-text">
    Для возможных обратных вопросов. Только действительные немецкие номера
    мобильных телефонов.
  </span>
  <div id="phone-error-demo" class="contact-form__error-message" hidden></div>
</div>

<div class="contact-form__group">
  <label for="email-demo" class="contact-form__label">
    <span class="contact-form__error-prefix" hidden>Ошибка: </span>
    Адрес электронной почты*
  </label>
  <input
    type="email"
    id="email-demo"
    name="email"
    autocomplete="email"
    required
    aria-required="true"
    aria-invalid="false"
    aria-describedby="email-hint-demo email-error-demo"
    class="contact-form__input"
  />
  <span id="email-hint-demo" class="contact-form__help-text">
    Действительный адрес электронной почты (напр. max.mustermann@example.com).
  </span>
  <div id="email-error-demo" class="contact-form__error-message" hidden></div>
</div>

Обработка ошибок и валидация​

Ошибки случаются. Доступная форма точно направляет пользователя к исправлению [18]. Стандартная валидация браузера (которую мы отключили с помощью novalidate) не подходит для этого, так как ее сообщения часто не фокусируемы или не воспринимаются скринридерами [19].

Наш подход состоит из трех частей:

  1. Сводка ошибок: <div> в начале формы, который перечисляет все ошибки [6]. Это помогает пользователям быстро увидеть, что нужно исправить, и позволяет перейти непосредственно к ошибочным полям [20].
  2. Встроенные ошибки: Текстовое сообщение непосредственно под ошибочным полем, чтобы предоставить пользователю подробную информацию [21]. Само поле ввода помечается с помощью aria-invalid="true", чтобы скринридеры могли распознать ошибку [22].
  3. Управление фокусом: При возникновении ошибки фокус активно устанавливается на сводку ошибок с помощью JavaScript.
  4. Мы настраиваем <label> (или <legend>) каждого ошибочного поля, добавляя префикс "Ошибка: " . Это решающее значение для выполнения критерия успеха WCAG 1.4.1 [23]. Если бы мы изменили только цвет, ошибка не была бы распознана пользователями с дальтонизмом.

На Рисунке 4.1 Вы видите логику валидации и обработки ошибок, которую мы будем реализовывать далее.

Открыть текстовое описание для "Логика доступной обработки ошибок"

Эта блок-схема показывает процесс валидации:

  1. Пользователь нажимает на «Отправить».
  2. JavaScript предотвращает стандартную отправку.
  3. Функция resetErrors() сбрасывает все старые сообщения об ошибках.
  4. Функция validateForm() проверяет все поля.
  5. Принятие решения проверяет: «Ошибка найдена?».
  6. Если Да: Функция showErrorSummary() заполняет сводку ошибок, showInlineError() помечает поля, и фокус устанавливается на сводку ошибок с помощью errorSummary.focus().
  7. Если Нет: Форма отправляется.

Теперь мы реализуем логику и HTML-структуру для обработки ошибок.

Сводка ошибок должна быть подготовлена в HTML. Сводка получает role="alert", чтобы скринридеры сразу же считывали ее при отображении [25], и tabindex="-1", чтобы мы могли сфокусировать ее с помощью JavaScript [26].

HTML: Подготовка сводки ошибок
<div
  id="error-summary-demo"
  class="contact-form__error-summary"
  role="alert"
  tabindex="-1"
  hidden
  aria-labelledby="error-summary-title-demo"
>
  <h2 id="error-summary-title-demo">Ваши данные содержат ошибки</h2>
  <p id="error-summary-intro"></p>
  <ul class="contact-form__error-summary-list"></ul>
</div>

<!-- Поля формы -->

В этом примере сводка ошибок сначала скрыта с помощью hidden и aria-hidden="true". Как только возникает ошибка, она становится видимой с помощью JavaScript.

Таким образом, доступная обработка ошибок реализована!

Доступное оформление статуса отправки (загрузка)​

После того как пользователь нажимает «Отправить» и форма валидна, начинается процесс отправки. Этот сетевой запрос занимает некоторое время. Если Вы не предоставите обратной связи, пользователь не будет уверен:

  • «Что-то произошло?»
  • «Мне нужно нажать еще раз?»

Этот неопределенный «промежуток» мы должны преодолеть доступным способом. Лучший метод — это деактивировать кнопку, чтобы предотвратить двойную отправку [27], и сообщить о статусе «Занято».

Для этого мы настроим блок else в нашем submit-Event-Listener.

JavaScript: Деактивация кнопки отправки и объявление статуса
// ... в submit-Event-Listener ...

// ... (Определения переменных)
const submitButton = form.querySelector('button[type="submit"]');

if (Object.keys(newErrors).length > 0) {
  // ... (Обработка ошибок, как выше) ...
} else {
  // НЕТ ОШИБОК: Отправить форму

  // 1. Установить статус UI на 'submitting'
  // Эта функция управляет кнопкой, спиннером и живой областью
  updateUIforStatusChange('submitting');

  // 2. Здесь находится Ваша реальная логика отправки (напр. fetch)
  // В этом примере мы ее имитируем:
  simulateFormSend() // Эта функция возвращает Promise
    .then((response) => {
      // Обработать случай успеха
      updateUIforStatusChange('success');
    })
    .catch((error) => {
      // Обработать случай ошибки
      updateUIforStatusChange('error');
    });
}
// ...

/**
 * Имитирует отправку (длится 3 сек.)
 */
function simulateFormSend() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ success: true });
    }, 3000);
  });
}

Для объявления статуса (statusRegion.textContent = ...) нам нужна живая область. Вы можете разместить ее непосредственно рядом с Вашей сводкой ошибок в HTML. Важно использовать role="status" и aria-live="polite", чтобы объявление не прерывало текущее считывание скринридером [28].

HTML: Живая область для статуса загрузки и успеха
<div
  id="form-status-message"
  role="status"
  aria-live="polite"
  class="visually-hidden"
>
  <!-- Здесь будет отображаться статус -->
</div>

Статус после отправки (Успех/Ошибка)​

После процесса загрузки есть два результата: успех (HTTP 200) или ошибка (например, серверная ошибка, HTTP 500). Вы должны недвусмысленно сообщить об обоих пользователю. Здесь есть два распространенных, доступных сценария.

Это самый надежный и простой метод.

  1. При успехе: Перенаправьте пользователя на страницу «Спасибо» (например, /contact/thanks).
  2. При ошибке: Перенаправьте пользователя на страницу «Ошибка» (например, /contact/error).

Вот пример перенаправления при успехе в handleSuccess():

JavaScript: Перенаправление при успехе
function handleSuccess(response) {
  // 1. Перенаправление при успехе
  window.location.href = '/contact/thanks';
}

Чтобы это было доступно, новая страница должна:

  • Иметь четкий, описательный тег <title> (например, «Спасибо за Ваше сообщение - Мой веб-сайт»).
  • Иметь четкий заголовок <h1> (например, «Большое спасибо!»).
  • Фокус автоматически устанавливается на начало документа при загрузке новой страницы, в результате чего скринридер считывает новый заголовок страницы и <h1>.

Вам не нужны aria-live или управление фокусом, так как смена страницы в браузере уже четко сообщает об изменении контекста.

Вывод​

Создание доступной формы — это не магия, а добросовестное мастерство. Это требует тщательности и понимания того, как разные люди взаимодействуют с веб-пространством.

Используя семантический HTML (label, fieldset), создавая четкие структуры и внедряя устойчивое к ошибкам, поддерживающее руководство пользователя, Вы не только выполняете законодательные требования EAA [1]. Вы создаете лучший, более удобный для пользователя продукт для всех Ваших пользователей [29]. Показанные здесь методы являются универсальными и представляют собой решающий шаг к по-настоящему инклюзивному Интернету.

Сводный чек-лист всех пунктов из этого руководства Вы найдете в моем Чек-листе по формам для веб-разработчиков.

Часто задаваемые вопросы (FAQ) о доступных формах​

Почему нужно использовать novalidate в теге <form>?​

Атрибут novalidate отключает стандартные сообщения об ошибках браузера. Они часто недоступны (например, видны только как небольшие всплывающие подсказки, которые быстро исчезают) и не имеют единого дизайна [19]. С помощью novalidate мы берем на себя полный контроль и можем реализовать надежную, доступную для всех обработку ошибок с помощью JavaScript.

Разве красной рамки недостаточно для сообщений об ошибках?​

Нет. Красная рамка — это чисто визуальная информация, которую не могут воспринять пользователи с нарушениями зрения (например, дальтонизмом) или при использовании скринридера [23]. Доступная обработка ошибок требует программных состояний (таких как aria-invalid="true") [22] и текстовых альтернатив, которые могут быть считаны вспомогательными технологиями [18].

Я должен соблюдать WCAG 2.1 или 2.2?​

EAA ссылается на WCAG 2.1 [30] через европейский стандарт EN 301 549 [31]. Однако WCAG 2.2 [32] является более новым, рекомендуемым стандартом. Ориентация на WCAG 2.2 является проверенной практикой (Best Practice), поскольку она ориентирована на будущее и полностью охватывает требования 2.1. Больше информации об этом Вы найдете в моем разделе "Законодательство в области цифровой доступности".

В чем разница между required и aria-required="true"?​

required — это атрибут HTML5, который сообщает браузеру, что поле должно быть заполнено (и вызывает нативную валидацию, если отсутствует novalidate). aria-required="true" — это ARIA-атрибут, который явно и наиболее надежным образом сообщает вспомогательным технологиям (таким как скринридеры), что поле является обязательным. Лучше всего использовать оба для обеспечения максимальной совместимости и семантической ясности, поскольку в некоторых случаях required сам по себе неверно интерпретируется всеми технологиями или ARIA не поддерживается.

Что насчет размера области нажатия кнопок (Target Size)?​

Важным нововведением в WCAG 2.2 является критерий 2.5.8 Размер цели (Минимум) (Уровень AA) [33]. Он гласит, что интерактивные элементы (кнопки, ссылки, радиокнопки, чекбоксы) не должны быть меньше 24x24 CSS-пикселей.

Это критически важно для пользователей с моторными нарушениями, например, на сенсорных устройствах или при дрожании рук, так как это уменьшает вероятность случайного нажатия на неправильный элемент. При работе с CSS убедитесь, что Ваши цели клика (особенно часто слишком маленькие радиокнопки и чекбоксы) соответствуют этому требованию.

Отказ от ответственности​

Содержание этого руководства предназначено исключительно для информационных целей и не является юридической консультацией. Хотя я стремлюсь предоставлять точную и актуальную информацию, я не несу ответственности за полноту, правильность или актуальность предоставленной информации. Соблюдение стандартов доступности может варьироваться в зависимости от конкретного контекста и сценария использования. Рекомендуется получить профессиональную консультацию при внедрении доступных форм и проводить регулярные тесты с реальными пользователями, чтобы убедиться в выполнении требований руководства WCAG 2.2. Я не несу ответственности за ущерб или убытки, возникшие в результате использования или доверия к информации, содержащейся в данном руководстве.

​

  1. Bundesministerium der Justiz und für Verbraucherschutz, «Gesetz zur Umsetzung der Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen (Barrierefreiheitsstärkungsgesetz – BFSG)». 2023 г. [Онлайн]. Доступно на: https://www.gesetze-im-internet.de/bfsg/ ⤴
  2. Forrester Research, «Accessibility Is Still Vital For Businesses». 3 февраль 2025 г. [Онлайн]. Доступно на: https://www.forrester.com/blogs/accessibility-is-still-vital-for-businesses/ ⤴
  3. W3C, «Success Criterion 3.3.2 Labels or Instructions», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#labels-or-instructions ⤴
  4. W3C, «H44: Using label elements to associate text labels with form controls», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/html/H44 ⤴
  5. W3C, «F82: Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/failures/F82 ⤴
  6. W3C, «G83: Providing text descriptions to identify required fields that were not completed», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/general/G83 ⤴
  7. W3C, «G162: Positioning labels to maximize predictability of relationships», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/general/G162 ⤴
  8. W3C, «Success Criterion 1.4.10 Reflow», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#reflow ⤴
  9. W3C, «Success Criterion 2.4.3 Focus Order», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#focus-order ⤴
  10. W3C, «Success Criterion 2.4.7 Focus Visible», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#focus-visible ⤴
  11. W3C, «Success Criterion 1.3.1 Info and Relationships», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#info-and-relationships ⤴
  12. W3C, «H71: Providing a description for groups of form controls using fieldset and legend elements», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/html/H71 ⤴
  13. W3C, «ARIA17: Using grouping roles to identify related form controls», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA17 ⤴
  14. W3C, «ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA1 ⤴
  15. W3C, «H98: Using HTML autocomplete attributes», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/html/H98 ⤴
  16. W3C, «Success Criterion 1.3.5 Identify Input Purpose», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#identify-input-purpose ⤴
  17. W3C, «Success Criterion 1.4.3 Contrast (Minimum)», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#contrast-minimum ⤴
  18. W3C, «Success Criterion 3.3.1 Error Identification», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#error-identification ⤴
  19. E. Smith, «Accessible form validation with examples and code», Pope Tech, окт. 2025, [Онлайн]. Доступно на: https://blog.pope.tech/2025/09/30/accessible-form-validation-with-examples-and-code/ ⤴
  20. W3C, «G139: Creating a mechanism that allows users to jump to errors», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/general/G139 ⤴
  21. W3C, «G85: Providing a text description when user input falls outside the required format or values», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/general/G85 ⤴
  22. W3C, «ARIA21: Using aria-invalid to Indicate An Error Field», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA21 ⤴
  23. W3C, «Success Criterion 1.4.1 Use of Color», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#use-of-color ⤴
  24. W3C Web Accessibility Initiative (WAI), «W3C Forms Tutorial: User Notifications». 2023 г. [Онлайн]. Доступно на: https://www.w3.org/WAI/tutorials/forms/notifications/ ⤴
  25. W3C, «ARIA19: Using ARIA role=alert or Live Regions to Identify Errors», 2023, [Онлайн]. Доступно на: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA19 ⤴
  26. WHATWG, «HTML Living Standard». 2024 г. [Онлайн]. Доступно на: https://html.spec.whatwg.org/ ⤴
  27. W3C, «Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data ⤴
  28. W3C, «Success Criterion 4.1.3 Status Messages», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#status-messages ⤴
  29. W3C Web Accessibility Initiative, «The Case for Digital Accessibility». 2022 г. [Онлайн]. Доступно на: https://www.w3.org/WAI/business-case/ ⤴
  30. W3C, «Web Content Accessibility Guidelines (WCAG) 2.1». 2021 г. [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG21/ ⤴
  31. ETSI, «ETSI EN 301 549 V3.2.1 (2021-03) - Accessibility requirements for ICT products and services». 2021 г. [Онлайн]. Доступно на: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf ⤴
  32. W3C, «Web Content Accessibility Guidelines (WCAG) 2.2». 2023 г. [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/ ⤴
  33. W3C, «Success Criterion 2.5.8 Target Size (Minimum)», 2023, [Онлайн]. Доступно на: https://www.w3.org/TR/WCAG22/#target-size-minimum ⤴
Портрет Дмитрия Дугарева

С наилучшими пожеланиями,

Дмитрий Дугарев

Основатель Barrierenlos℠ и разработчик плагина Semanticality™. Имея степень магистра, более 8 лет опыта в веб-разработке и IT-комплаенса в компаниях «Большой четвёрки», банках и концернах и более 1 000 протестированных на доступность веб-страниц для более чем 50 клиентов, я помогаю веб-командам системно внедрять доступность — без многомесячных переделок.

Станьте сами разработчиком-профи EAA - всего за 4 дня!

Узнайте на нашем 4-дневном семинаре, как самостоятельно проводить сложные аудиты и создавать доступные компоненты. Получите индивидуальный учебный план, 1:1 стратегическую консультацию и сертификат.

Зарегистрироваться на воркшоп сейчас

На этой странице

Ваша конфиденциальность важна для нас

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

Эти файлы cookie необходимы для базовой функциональности веб-сайта и не могут быть деактивированы.

Эти файлы cookie помогают нам понять, как посетители взаимодействуют с нашим веб-сайтом, анонимно собирая и сообщая информацию.

  • Google Analytics: Собирает анонимную статистику использования страниц.
  • Hotjar: Анализирует поведение кликов и прокрутки для улучшения удобства использования (анонимно).

Эти файлы cookie используются для показа вам релевантной рекламы на других платформах и предоставления контента на основе ваших интересов.

  • Google Ads и Microsoft Ads: Измеряют успех рекламных объявлений и позволяют персонализировать рекламу.
  • Meta Pixel: Позволяет таргетированную рекламу в Facebook и Instagram.
  • Партнерское отслеживание (Freemius): Присваивает покупки партнеру для расчета комиссии (срок хранения 30 дней) - если вы пришли к нам по партнерской ссылке, эти файлы cookie должны быть активированы, чтобы партнер получил свою комиссию.