Цифрова доступність для HR-команд: як зробити рекрутинг та корпоративні системи сумісними з WCAG

Вступ

Якщо ваш кар'єрний сайт, форми подання заявок або внутрішні системи недоступні, ви виключаєте кваліфікованих кандидатів та працівників з інвалідністю — і ви можете порушувати законодавство. Рекомендації щодо доступності веб-контенту (WCAG) 2.2, опубліковані W3C, — це поточна версія стандарту, а рівень AA — це еталон, до якого прагнуть більшість організацій. Це все частіше закріплюється в регуляціях: органи державного сектору Великобританії повинні дотримуватися WCAG 2.2 AA, а правило 2024 року Міністерства юстиції США щодо Title II ADA робить WCAG 2.1 Level AA технічним стандартом для веб-контенту та мобільних додатків органів влади штатів та місцевих органів влади.

Цей посібник надає HR-командам конкретну, практичну дорожну карту для забезпечення доступності систем рекрутингу та роботи в організації.

Крок 1: Аудит вашого кар'єрного сайту

Ваш кар'єрний сайт — це входи до вашої організації для кожного кандидата. Недоступний кар'єрний сайт відправляє зрозумілий сигнал потенційним співробітникам з інвалідністю: ви тут не вітаються.

Контрольний список WCAG 2.2 AA для кар'єрних сайтів

Сприйнятливість

• Усі зображення мають змістовний альтернативний текст (декоративні зображення використовують порожні атрибути alt)
• Відео мають субтитри та описи звуку
• Контрастність кольорів відповідає мінімальним коефіцієнтам (4,5:1 для звичайного тексту, 3:1 для великого тексту)
• Текст можна змінити розмір до 200% без втрати вмісту або функціональності, а вміст переформатується без двовимірного прокручування при ширині 320 пікселів CSS (еквівалентно 400% масштабуванню на екрані шириною 1280 пікселів)
• Інформація не передається лише за допомогою кольору

Функціональність

• Вся функціональність доступна з клавіатури (Tab, Enter, Space, клавіші зі стрілками)
• Індикатори фокусу видимі та відчутливі
• Не існує клавіатурних пасток (користувачі завжди можуть натиснути Tab, щоб відійти від будь-якого елемента)
• Сторінки мають посилання для пропуску навігації
• Користувачам дається достатньо часу для виконання завдань (або вони можуть розширити обмеження часу)
• Вміст не блимає більше трьох разів на секунду

Зрозумілість

• Мова сторінки оголошена в HTML
• Позначки форм програмно пов'язані зі входами
• Повідомлення про помилки чіткі та конкретні (наприклад, "Адреса електронної пошти повинна містити символ @" замість "Неправильне введення")
• Навігація послідовна на всіх сторінках

Надійність

• Сторінки використовують правильно сформований семантичний HTML (WCAG 2.2 позначає стару критерій 4.1.1 Parsing як застарілу та видалену, але чистий розмітка все ще допомагає допоміжним технологіям)
• Власні віджети використовують ARIA ролі, стани та властивості правильно
• Вміст працює з поточними допоміжними технологіями (екранні читачі, лупи, голосове керування)

Крок 2: Забезпечення доступності форм подання заявок

Форми подання заявок — це місце, де найчастіше трапляються порушення доступності. Звичайні проблеми та їхні рішення:

Позначки та інструкції

• Порушення: Текст заповнювача використовується як єдина позначка. Екранні читачі можуть не оголошувати текст заповнювача послідовно.
• Рішення: Використовуйте видимі елементи `<label> пов'язані з кожним входом через атрибути for/id`.

Обробка помилок

• Порушення: Помилки відображаються лише червоним текстом поруч із полем без програмного зв'язку.
• Рішення: Використовуйте `aria-describedby для пов'язування повідомлень про помилки з полями. Надайте резюме помилок у верхній частині форми. Використовуйте aria-invalid="true"` для полів з помилками.

Навігація з клавіатури

• Порушення: Спеціальні меню розкривання та календарі, які працюють лише з мишею.
• Рішення: Використовуйте власні елементи HTML `<select>` де це можливо. Для спеціальних віджетів впровадіть повну підтримку клавіатури відповідно до методів розроблення WAI-ARIA.

Завантаження файлів

• Порушення: Завантаження резюме лише перетягуванням без альтернативи.
• Рішення: Завжди надавайте стандартний файловий вхід (`<input type="file">`) поряд з будь-яким інтерфейсом перетягування.

Індикатори прогресу

• Порушення: Багатоетапні форми, які не вказують поточну позицію або не дозволяють навігацію назад.
• Рішення: Використовуйте `aria-current="step"` та надайте чіткі підрахунки кроків (наприклад, "Крок 2 з 4"). Дозвольте користувачам повертатися на попередні кроки без втрати даних.

Крок 3: Налаштування вашої ATS для забезпечення доступності

Системи відстеження кандидатів (ATS) генерують багато сторінок, з якими взаємодіють кандидати. Типові проблеми доступності ATS:

• Автоматично згенеровані сторінки списків вакансій можуть мати недостатню структуру заголовків. Працюйте зі своїм постачальником ATS, щоб переконатися, що теги H1/H2/H3 використовуються правильно.
• Функції "Подати з LinkedIn" або аналогічні однокліковані функції можуть не бути доступні з клавіатури. Тестуйте ретельно або надайте ручну альтернативу.
• CAPTCHA на формах подання заявок можуть заблокувати користувачів екранних читачів та людей з когнітивними порушеннями. Використовуйте методи перевірки, які не спираються на зоровий або когнітивний головоломку, і зверніть увагу, що критерій успіху WCAG 2.2 3.3.8 (Accessible Authentication) обмежує когнітивні функціональні тести на етапах входу.
• Тайм-аути сеансу під час тривалих заявок штрафують користувачів, які повільно набирають текст. Розширте або видаліть тайм-аути або попередьте користувачів перед тайм-аутом та дозвольте розширення.

Пункт дії: Запросіть у постачальника ATS звіт про відповідність доступності (ACR) — заповнену форму VPAT (Voluntary Product Accessibility Template). Якщо вони не можуть його надати, розглянете можливість переходу на постачальника, який серйозно відноситься до доступності.

Крок 4: Створення доступних документів для введення в посаду

Нові найманці отримують потік документів: контракти, довідники, посібники з пільг, навчальні матеріали. Усі вони повинні бути доступними.

Доступність PDF

• Використовуйте теговані PDF-файли з логічним порядком читання
• Переконайтеся, що усі зображення мають альтернативний текст
• Використовуйте справжній текст (а не скановані зображення тексту)
• Визначте мову документа та назву
• Тестуйте з екранним читачем (перевірка доступності Adobe Acrobat — це стартова точка, але ручне тестування є важливим)

Слайд-шоу та навчальні матеріали

• Використовуйте макети слайдів (не вільнодосяжні текстові поля), щоб екранні читачі дотримувалися логічного порядку читання
• Додайте альтернативний текст до всіх візуальних елементів
• Забезпечте достатню контрастність кольорів
• Надайте нотатки промовця як альтернативний текстовий наратив
• Записуйте аудіо/відео з субтитрами

Форми та опитування

• Використовуйте доступні конструктори форм (Microsoft Forms, Google Forms є розумно доступними; протестуйте інші перед розгортанням)
• Ніколи не використовуйте форми PDF, які вимагають від користувача друкування, рукописного написання та сканування

Крок 5: Забезпечення доступності внутрішніх комунікацій

Електронна пошта

• Використовуйте семантичний HTML у шаблонах електронної пошти (заголовки, списки, альтернативний текст для зображень)
• Уникайте надсилання критичної інформації лише як вкладень зображень
• Надавайте альтернативи у простому текстовому форматі

Інтранет

• Застосовуйте ті ж стандарти WCAG 2.2 AA, що й для вашого кар'єрного сайту
• Переконайтеся, що функціональність пошуку працює з екранними читачами
• Зробіть сховища документів навіганими з клавіатури

Slack, Teams та платформи чату

• Заохочуйте використання альтернативного тексту на зображеннях, поділених у каналах, де ваша платформа це підтримує
• Використовуйте потоки замість довгих неструктурованих розмов (більш легко для когнітивної доступності)
• Включіть та просуйте субтитри у відеозвинках
• Переконайтеся, що критичні оголошення також надаються у текстовому форматі, а не лише як відео або аудіо

Інструменти тестування

Процес тестування

1. Автоматизоване сканування за допомогою axe або Lighthouse — виявляє лише частину проблем, тому ніколи не покладайтеся на нього самого
2. Ручне тестування клавіатури — навігуйте по кожній сторінці, використовуючи лише Tab, Enter, Space та клавіші зі стрілками
3. Тестування екранного читача — тестуйте з NVDA (Windows) або VoiceOver (macOS) як мінімум
4. Користувальницьке тестування — залучайте користувачів з інвалідністю для тестування реальних потоків подання заявок

Типові порушення та рішення

Висновок

Цифрова доступність для HR-систем — це не одноразовий проект — це постійне зобов'язання. Проведіть аудит ваших поточних систем, виправте найбільш критичні перешкоди спочатку, регулярно тестуйте з реальними допоміжними технологіями та притримуйте своїх постачальників відповідальними. Кожне вдосконалення робить вашу робочу місцезнаходження більш інклюзивною та вашу кадрову базу більшою.