Когато съобщенията за грешки блокират потребителите

Моментът, в който формулярът се чупи

Представете си: сляп потребител попълва формуляр за поръчка, изпраща го и не чува нищо полезно от екранния си четец. Никакво съобщение. Никакво обяснение. Страницата визуално е маркирала пет грешки при валидация в червено, но потребителят няма представа. Той натиска бутона за изпращане отново. И отново. Накрая си тръгва.

Това не е краен сценарий. Недостъпната обработка на грешки е една от най-често срещаните бариери, които откриваме в реални одити, и е от тези, които фрустрират потребителите в най-неподходящия момент — когато се опитват да завършат транзакция или да изпратят нещо важно.

Добрата новина е, че поправянето ѝ до голяма степен е въпрос на това да знаете как изглежда „доброто“. Пропуските почти винаги са едни и същи няколко модела.

Защо съобщенията за грешки са трудни за потребителите на асистиращи технологии

Виждащите потребители с мишка обикновено забелязват грешките при валидация веднага — червената рамка, предупредителната икона, текста, появяващ се под полето. Но потребителите, които разчитат на екранни четци, клавиатурна навигация или гласово управление, се сблъскват с фундаментално различно преживяване.

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

• Потребителите на екранни четци може да не чуят нищо, освен ако фокусът не се премести върху грешката или тя не бъде обявена от жива област
• Потребителите с клавиатура трябва да могат да достигнат всяко съобщение за грешка от клавиатурата и да разберат към кое поле се отнася
• Потребителите с гласово управление трябва да могат да посочват полетата по видим, точен етикет — ако етикетът е грешен или липсва, те са блокирани

Нищо от това не се случва автоматично. Трябва да го изградите.

Приложимите критерии на WCAG

Четири критерия за успех в WCAG 2.2 обхващат директно обработката на грешки:

3.3.1 Идентифициране на грешки (ниво A) — Ако грешка бъде открита автоматично, сгрешеният елемент трябва да бъде идентифициран и описан на потребителя с текст. Не можете да предавате грешки само чрез цвят.

3.3.2 Етикети или инструкции (ниво A) — Полетата, които изискват определен формат, трябва да поясняват това изискване преди или по време на въвеждането, а не само след неуспешно изпращане.

3.3.3 Предложение при грешка (ниво AA) — Ако грешка бъде открита и са известни предложения за поправяне, предоставете ги. „Невалидна дата“ не е достатъчно. „Въведете датата във формат ДД/ММ/ГГГГ“ е.

3.3.4 Предотвратяване на грешки (ниво AA) — При изпращания със сериозни последици (финансови транзакции, правни споразумения) дайте на потребителите възможност да прегледат, коригират и потвърдят, преди действието да стане окончателно.

Съществува и 4.1.3 Съобщения за състояние (ниво AA), който обхваща динамично добавяните съобщения, които не получават фокус — те трябва да бъдат обявявани от асистиращите технологии чрез role="status" или role="alert".

От какво всъщност се нуждае едно достъпно съобщение за грешка

Правилното изграждане на съобщенията за грешки изисква внимание към четири отделни слоя:

1. Програмната връзка

Всяко съобщение за грешка трябва да бъде свързано с полето си чрез aria-describedby. Това казва на екранните четци да обявят текста на грешката, когато полето получи фокус.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

Атрибутът aria-invalid="true" сигнализира, че полето в момента е невалидно, което повечето екранни четци обявяват, когато фокусът попадне върху него.

2. Управление на фокуса след изпращане

Когато формулярът бъде изпратен и има грешки, фокусът трябва да се премести на полезно място. Двата най-често срещани модела:

• Преместете фокуса върху обобщение на грешките в горната част на формуляра, което изброява всички грешки с връзки към съответните полета
• Преместете фокуса върху първото сгрешено поле

Ако фокусът остане върху бутона за изпращане или никъде, потребителите на екранни четци трябва сами да откриват грешките, навигирайки през формуляра — ако изобщо знаят, че има грешки.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Обявяване чрез живи области при динамични грешки

За грешки, които се появяват, докато потребителят пише (валидация в реално време), използвайте ARIA живи области, така че съобщението да бъде обявено, без да е нужно фокусът да се мести.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Използвайте role="alert" / aria-live="assertive" за грешки, които изискват незабавно внимание. Използвайте role="status" / aria-live="polite" за по-малко спешна обратна връзка, която може да изчака потребителят да направи пауза.

4. Самото съобщение за грешка

Езикът има значение. Достъпните съобщения за грешки са:

• Конкретни: казват какво е грешно, а не просто че нещо е грешно
• Действени: казват на потребителя точно какво да направи, за да го поправи
• Учтиви: избягват обвинителен език като „въвели сте невалидна стойност“

Недостъпно	Достъпно
„Невалидно въвеждане“	„Имейл адресът трябва да съдържа символа @, напр. name@example.com“
„Грешка“	„Датата трябва да е във формат ДД/ММ/ГГГГ“
„Задължително поле“	„Пълното име е задължително“
„Невалидна парола“	„Паролата трябва да е поне 8 знака и да включва една цифра“

Модели за различни сценарии на грешки

Инлайн грешки при полета

Най-често срещаният модел. Съобщение за грешка се появява директно под свързаното с него поле. Работи добре при прости формуляри. Изисква aria-describedby и aria-invalid, за да бъде обявено правилно.

Банери с обобщение на грешките

При дълги формуляри с множество грешки поставете обобщение в горната част, изброяващо всички проблеми като връзки, които водят до съответното поле. Преместете фокуса тук след неуспешно изпращане. Това е моделът, използван от GOV.UK, и широко препоръчван за сложни формуляри.

Toast известия

Краткотрайните съобщения, които се появяват в края на екрана, са сред най-недостъпните модели в широка употреба. Те изчезват, преди потребителите на екранни четци да успеят да ги достигнат, често изобщо не се обявяват и не предлагат път за възстановяване. Избягвайте да използвате toast известия за грешки. Ако все пак ги използвате, съчетайте ги с постоянно състояние на грешка в самия формуляр.

Системни грешки

Когато нещо се обърка от страна на сървъра, кажете на потребителя на ясен език какво се е случило и какво може да направи след това. „Нещо се обърка“ без допълнителни насоки оставя потребителите в безизходица.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

Контролният списък за тестване

След като внедрите обработката на грешки, проверете следното ръчно — автоматизираните инструменти няма да уловят повечето от тези неща:

• Изпращането на празен задължителен формуляр премества фокуса върху обобщение на грешките или първото сгрешено поле
• Всяко съобщение за грешка е свързано с полето си чрез aria-describedby
• Сгрешените полета имат aria-invalid="true"
• Съобщенията за грешки се обявяват, когато фокусът попадне върху засегнатото поле
• Валидацията в реално време използва живи области
• Съобщенията за грешки използват конкретен, действен език — не просто „невалидно“
• Цветът не е единственият начин за обозначаване на грешки (икона или текстов етикет наред с червеното)
• Грешката може да бъде достигната с tab от клавиатурата
• Редът на фокуса след изпращане е логичен и не скача непредсказуемо
• Toast съобщенията са съчетани с постоянно състояние на грешка

Защо автоматизираните инструменти пропускат по-голямата част от това

Автоматизираният скенер може да провери дали aria-describedby сочи към съществуващ елемент и дали aria-invalid присъства. Той не може да провери дали фокусът се мести правилно след изпращане, дали текстът на грешката е точен или дали toast известието изчезва, преди да може да бъде прочетено. Нашите ръчни одити за достъпност включват специализирано тестване на формуляри с реални асистиращи технологии — единственият надежден начин да се провери, че обработката на грешки наистина работи от край до край.

Ако не сте сигурни къде стоят вашите формуляри, пуснете безплатно сканиране, за да откриете първо автоматично установимите проблеми, и продължете оттам.