Державний сайт, доступний для людей з обмеженими можливостями (Чек-лист доступності)

Введення
В рамках «Дизайну госсистем» ми створили для вас (розробників всіх видів) чек-лист доступності сайту для людей з обмеженими можливостями, який потрібно прибити над робочим столом кожного дизайнера і фронтендера. Він підходить до будь-яких проектів (зовсім не тільки державним) у ньому немає нічого зайвого. У ньому тільки винятково важлива, критична і корисна інформація.
Так що друкуйте, читайте та діліться зі своїми колегами.
Це вкрай необхідні текст і знання.
Оброблений в Photoshop текст із застосуванням фільтра blur

Вимоги щодо доступності сайту визначаються стандартом WCAG рівня AA. Стандарт досить докладно описує всі вимоги, що містить посилання на роз'яснення, використовувані техніки і часто зустрічаються помилки. Це дозволяє повністю спиратися на нього при аналізі доступності веб-сторінок та їх адаптації. Крім того, в загальному доступі є великий інструментарій для напівавтоматичного виявлення помилок: валідатори і доповнення для браузерів.
У цьому документі подано практичні рекомендації по застосуванню стандарту, описаний інструментарій і процес перевірки сайту на доступність, даються посилання на ключові матеріали та керівництва по доступності сайтів, а також на приклади реалізації найбільш поширених віджетів.
Стандарт WCAG 2.0 рівня AA описує критерії доступності для різних категорій користувачів. На практиці для додержання хорошого рівня відповідності критеріям тестировщику буде корисно уявити себе на місці наступних категорій користувачів (або залучити їх до тестування):
  • Страждають різними видами дальтонізму (колірної сліпоти). Там, де колір використовується для індикації або надання інформації, повинні бути передбачені альтернативні візуальні засоби.
  • Зором. Накладаються вимоги по контрастності, розміром елементів і підтримки масштабування сторінки.
  • Сліпі (повністю незрячі користувачі екранних читців). Потрібен широкий набір заходів, включаючи:
    • надання текстової альтернативи для всіх значущих нетекстових елементів,
    • надання семантичної верстки,
    • правильне використання семантичних областей, заголовків і інших навігаційних елементів,
    • надання додаткових засобів навігації по сторінці,
    • надання додаткової метаінформації про елементи на сторінці і зв'язках між ними,
    • обов'язкове надання текстових міток і, при необхідності, підказок для елементів вводу,
    • облік особливостей сприйняття вмісту: воно сприймається на слух, тобто послідовно, без можливості охоплення всієї сторінки поглядом цілком, без можливості помітити інформацію в іншій області сторінки (якщо вона не пов'язана відповідним чином), без сприйняття сенсорних характеристик тексту,
    • реалізація взаємодії з елементами управління або введення за допомогою набору атрибутів (role, aria-* і ін).
  • Користувачі з порушенням слуху. Потрібне обов'язкове надання текстової альтернативи для аудіоконтенту.
  • Користувачі з порушенням опорно-рухового апарату, яке може виражатися в нездатності користуватися мишею. Потрібна повна керованість і доступність сайту для клавіатури.
Всім учасникам розробки (дизайнерів, розробників, проект-менеджерів, тестувальникам і редакторам) можна також ознайомитися з коротким чек-листом, в якому описані основні обов'язки кожного фахівця по забезпеченню доступності.
См. також:
Дизайн
  1. Колір не може бути єдиним способом надання будь-якої інформації або розмітки.
  2. Необхідно дотримуватися контрастність згідно WCAG 2.0.
    Вимірювати контрастність в HTML можна WAVE Evaluation Tool
  3. Не слід спиратися на сенсорні характеристики.
    Детально дана вимога розібрано нижче в описі критерію 1.3.3.
  4. Повинно бути передбачено візуальне відображення станів фокусу на полях і елементах управління.
  5. Для інформації, яку принципово не можна зробити доступною, слід передбачати альтернативні форми подання або, якщо це неможливо, надати текстовий опис можливостей інтерфейсу (наприклад, щоб незрячий користувач мав можливість зрозуміти функціонал сторінки і звернутися за допомогою до зрячому).
См. Accessibility Guidelines. The Checlist for Designers.
Засоби перевірки
  1. Перевірка сайту валидаторами на загальну валідність HTML: https://validator.w3.org/
  2. Перевірка сайту спеціалізованими валидаторами:
    • http://achecker.ca/checker/ валідатор на основі аналізу HTML-коду. Не враховує JavaScript, помилки виводяться в текстовому вигляді, не дуже зручні для аналізу. Видає список потенційних проблем, більша частина з яких не відповідають дійсності, проте список може використовуватися в якості додаткового чек-листа.
    • http://wave.webaim.org/ і розширення для Chrome WAVE Evaluation Tool. Знаходять велику кількість помилок, надають підказки по виправленню і посилання на стандарт, надають інформацію в зручному вигляді, підсвічують синтаксис і aria-атрибути.
      Головне зручність в тому, що розширення може аналізувати не вихідний код, а поточний стан сторінки.
    • http://khan.github.io/tota11y/ — встраиваемый на сторінку з допомогою букмарклета візуалізатор і валідатор доступності. Підтримує вимірювання контрастності. На відміну від Wave Evaluation Tool, не показує всі помилки відразу і визначає не так багато помилок.
    • AInspector Sidebar for Firefox. На відміну від попередніх валідаторів, дозволяє знаходити помилки в логіці застосування aria-атрибутів. Крім списку помилок видає також список перевірок, які рекомендується зробити вручну.
    • Accessibility Developer Tools Chrome. Відловлює в основному формальні помилки застосування aria-атрибутів. З мінусів: незручний інтерфейс і незрозумілий формат виводу помилок.
    Треба пам'ятати, що наявність повідомлень про помилки валідатора саме по собі не є формальним критерієм невідповідності WCAG. Крім того, деякі повідомлення мають рекомендаційний характер або помічені як потенційні. Рішення щодо них повинні прийматися виходячи з контексту.
    Вірно і зворотне: не будь-яка проблема знаходиться валідатором: необхідно ручне тестування в т. ч. з застосуванням екранних читців (див. нижче).
  3. Перевірка в екранних чтецах.
    Найбільш простий в налаштуванні є комбінація Windows + Firefox/IE + NVDA. Також широко поширений JAWS (програма платна і дорога, але поставляється в тріал-версії з 40-хвилинним режимом). Користувачам інших ОС тестове оточення можна налаштувати у віртуальних машинах від Microsoft (https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ — колишній modern.ie), працює задовільно, принаймні, з ВМ Windows 7.
    Програми екранного доступу доволі специфічні для тих, хто з ними стикається вперше, однак до користування ними можна відносно швидко звикнути. Освоїти програму на рівні короткої інструкції (див. нижче) рекомендується всім фронт-енд розробникам і тестерам. Це не займе багато часу.
Спочатку при вертске потрібно враховувати
  1. Дотримання семантики розмітки. Зокрема, можна виділити наступне (перераховано далеко не всі):
    • Розмітка списків, перерахувань пунктів, стрічок документів тощо тегами <ul> <ol> <li> або відповідними атрибутами role.
    • Розмітка табличних даних тегами <table>, <tr> <th> <td> або відповідними атрибутами role. Зверніть увагу Правила вкладення елементів для атрибутів role повністю аналогічні правилам для тегів.
    • Використання тегів <caption> <summary>
    • Правильне використання заголовків таблиці. Потрібно врахувати, що заголовками комірки є всі вищестоящі елементи <th> у всій таблиці. Заголовки з colspan застосовуються до кожної іншій клітинці у всіх порушених стовпцях.
    • Не розбивати таблицю або список на кілька тільки для відображення.
    • Кнопки рекомендується оформляти за допомогою клікабельних елементів: <button> <a href… role="button"> <input type="button">. Допускається також використання некликабельных елементів з role=button, за умови фокусируемости (tabindex) і обробки подій клавіатури (натискання на натискання enter).
  2. Розмітка семантичних областей з допомогою role=main, role=navigation, role=contentinfo, role=complementary, role=banner та ін
    • Будь-який контент сторінки повинен належати будь-якої семантичної зоні.
    • Якщо на одній сторінці зони з role рівним navigation або complementary зустрічаються більше одного разу, то їм слід додавати текстові підписи, які пояснюють їх призначення допомогою атрибуту aria-label.
    • " Додавання посилання для пропуску повторюваних блоків і переходу до блоку role="main".
    Посилання має бути першим фокусируемым елементом на сторінці. Це посилання, призначена для незрячих користувачів. Після завантаження сторінки фокус повинен потрапляти на посилання з першого натискання TAB, потім після натискання на ENTER сторінка повинна якориться на елементі з основним вмістом.
    Еталонна реалізація на http://webaim.org/. Після завантаження потрібно натиснути TAB — посилання стає видимою в лівому верхньому куті, а потім ENTER.
  3. Сувора ієрархія заголовків починаючи з заголовка рівня 1.
  4. Керованість з клавіатури:
    • Всі елементи управління і введення повинні бути фокусируемы
    • Стан фокуса повинно бути помітно
  5. Надання додаткової текстової інформації:
    • Атрибут `alt`: у порожній декоративних елементів і осмислений текст для інформативних елементів.
    • Надання міток (label) для елементів вводу: за допомогою <label for="...">, aria-label, aria-labelledby. Не повинно бути елементів управління і введення без тексту або текстової мітки.
      Детальніше про те, як обчислюється текстова альтернатива, див. https://www.w3.org/TR/wai-aria/roles#textalternativecomputation
      Зверніть увагу, що не має сенсу додавати aria-label до не мають семантики елементів (наприклад, <span>).
      Для інших елементів (списки, групування полів <fieldset> та ін, віхах) атрибут aria-label також буде інтерпретуватися по-різному, і при його використанні треба розуміти його призначення для кожного елемента.
    • Відображення помилок: загальне повідомлення про помилку (у заголовку сторінки title, або на початку блоку основного вмісту сторінки, або в елементах з role="alert" або aria-live="assertive".
    • Використання тегів <caption> <summary> для опису таблиць, призначення яких незрозуміло з попереднього контексту або навігація по яким може вимагати додаткових відомостей.
    • Розкриття скорочень з допомогою <abbr title> (замість вмісту тега зачитується значення title):
    <abbr title="і так далі">
    і т. д.
    </abbr>

    • Для елементів, сенс яких стає зрозумілий лише з урахуванням положення на сторінці або зовнішнього вигляду, накреслення шрифту, закресленого тексту, поданої за допомогою іконок інформації (наприклад, зірковість готелю), потрібно текстовий опис, можливо, приховане за допомогою виносу за лівий край екрану:
    .sr_only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    border: 0;
    }

    <span class="sr_only">
    текст для екранних читців
    </span>

    • Значуща інформація, представлена у вигляді діаграм, графіків, інтерактивних Flash (в більшості випадків), SVG, Canvas та інших, повинна бути представлена також і в текстовому вигляді: окремими параграфами, таблицями, можливо, на окремій сторінці або в прихованому від зрячих користувачів за допомогою class="sr_only" блоці.
      Примітка: в більшості випадків є технічна можливість адаптувати перераховані елементи для користування незрячими, але на увазі трудозатратности, необхідність опрацювання по суті окремого інтерфейсу для незрячих, проблем з тестуванням і т. д. зазвичай легше і, головне, зручніше для користувача мати текстове представлення даних.
  6. Рекомендується використовувати вбудовані компоненти браузера, якщо вони задовольняють необхідного функціоналу: комбіновані списки (<select>), прапори (checkbox), радіокнопки, кнопки, поля введення.
    Слід також уникати переусложнения управління з клавіатури, не винаходити нові патерни взаємодії при наявності вирішують ті ж завдання стандартних рішень, намагаючись компонувати інтерфейс з відомих і доступних для інвалідів компонентів і підходів. См. розділ "Приклади реалізації доступних інтерфейсів" і опис критерію 4.1.2 нижче.
  7. Допускається створення елементів, прихованих для зрячих користувачів, але доступних для незрячих. Робиться це з допомогою техніки винесення елемента далеко за лівий край екрана (клас sr_only, описаний вище).
  8. Допустима реалізація окремого альтернативного інтерфейсу для екранних читців (з приховуванням основного варіанту інтерфейсу) у разі, якщо звичайний віджет зробити доступним важко. При цьому потрібно не забувати про керованість елемента з клавіатури зрячими користувачами.
    Користуватися цим прийомом потрібно з обережністю: якщо є вибір, то слід віддати перевагу адаптувати загальний інтерфейс під використання незрячими користувачами.
    Реалізація окремого інтерфейсу сенс, якщо це значно спрощує інтерфейс для незрячих, наприклад, введення дати вручну замість календаря (але календар теж можна зробити доступним), використання списку замість карти для вибору країн/міст.
    Важливо не перестаратися: практика показує, що сліпі користувачі не відчувають труднощі при користуванні деякими інтерфейсами, які на перший погляд здаються незручними для незрячих.
Швидка перевірка
  1. Перевірка сайту валидаторами на загальну валідність HTML: https://validator.w3.org/.
    Максимальну відповідність специфікації версії HTML не є обов'язковим, але рекомендується (див. техніку [G192][g192]). Однак є ряд помилок, важливих для доступності сайту і обов'язкових до виправлення. Вони перераховані в описі критерію 4.1.2 в розділі "Детальна перевірка на відповідність WCAG AA".
  2. Перевірка сайту спеціалізованими валидаторами. См. розділ "Засоби перевірки".
  3. Перевірка керованості з клавіатури без екранних читців.
    Не повинно бути клікабельних, але недоступних з клавіатури елементів (якщо їм немає спеціальної доступної альтернативи). Такі елементи слід реалізовувати за допомогою тегів <a href=..></a> <button> або за допомогою комбінації атрибутів role=button, role=link і tabindex.
    Фокус повинен бути видимим, коректно переміщатися, не "застрявати" при попаданні ні на один елемент і не губитися при будь-якій дії користувача в будь-якому стані сторінки.
  4. Перегляд сайту з застосованими стилями, приближающими його до того, яким його бачать незрячі. Стилі можна знайти за адресою https://github.com/Harut/wai-aria.css. Це дозволить знайти більшу частину помилок «на око», не звіряючись з кожним пунктом чек-листа. Цей пункт є необов'язковим, не замінює, а передує перегляд сторінки в екранних чтецах. Звертати увагу, в першу чергу, рекомендується на невідповідності у повній візуальної версії і версії з застосованими стилями.
  5. Перевірка в екранних чтецах. На цьому етапі більшість критичних помилок повинно бути виявлено і виправлено при попередніх перевірках.
    Необхідно перевірити сприйняття екранними читцями таблиць, нестандартних елементів, зручність користування функціоналом сторінки, правильність і повноту озвучуваних атрибутів (в основному, role і aria-*.
  6. Перевірка форм в екранних чтецах потребує особливої уваги. Потрібно перевірити коректність всіх текстових виправлень, помилок і інструкцій, перевірити поведінку форми при успішну відправку і наявності помилок, послідовність і повноту надання інформації в режимі заповнення форми (при перемиканні між полями з допомогою TAB, а не в режимі читання сторінки), коректне переміщення фокусу і т. д.
Приклади реалізації доступних інтерфейсів
Детальна перевірка на відповідність WCAG AA
В даному розділі наведена вичавка з WCAG у формі чек-листа на відповідність рівню AA, згрупований за відповідними критеріями WCAG. Список складений на основі http://webaim.org/standards/wcag/checklist. Офіційний набір рекомендацій, технік і список часто зустрічаються помилок можна знайти за посиланням: https://www.w3.org/WAI/WCAG20/quickref/.
Всім учасникам розробки і тестування сайту рекомендується уважно вивчити і освоїти даний список, щоб допускати менше помилок на етапі розробки або виправляти їх на ранніх етапах. Це дозволить обійтися найменшими трудовитратами при розробці та тестуванні, а також зосередитися при тестуванні на деталі, які важливі, але можуть бути втрачені в загальній кількості помилок.
1.1. Текстова версія: надайте текстову версію будь-якого нетекстового контенту
1.1.1. Нетекстовий контент (Level A)
  • Всі зображення, кнопки зображення (form image buttons), і області image map мають відповідний еквівалентний альтернативний текст.
  • Зображення, які не представляють будь-якого вмісту, є декоративними або зміст яких вже представлено текстом, мають порожній alt="" чи виконані у вигляді фонових зображень CSS.
  • Всі зображення-посилання мають альтернативний текст (aria-label у посилання або alt зображення).
  • Для складних зображень на тій же або окремій сторінці є розгорнутий текстовий аналог. Зображення може бути пов'язано з текстом за допомогою посилання або атрибута longdesc.
  • Всі кнопки мають осмислений текст.
  • Всі поля мають осмислені текстові мітки.
  • Вбудовані медіа-об'єкти повинні бути заголовки чи іншим чином ідентифіковані текстом, доступним для програм екранного доступу.
  • Вбудовані фрейми мають осмислені назви.
1.2. Медіаконтент: надайте альтернативну версію медіаконтенту, обмеженого в часі
Коротко, слід надавати розшифровку тексту запису, текстовий опис вмісту або субтитри. Якщо відео містить візуальну інформацію, яка не представлена звуком, слід також надати для нього аудіо-опис.
У випадку, якщо вміст з'явиться на сайті, слід звернутися до стандарту WCAG або, наприклад, рекомендацій Webaim.
1.3. Адаптованість: створюйте контент, який можна представити в різних видах без втрати даних або структури
1.3.1. Інформація та зв'язність (Level A)
  • Семантично значущі елементи використані по призначенню у відповідності зі специфікацією HTML.
  • Для позначення заголовка (<h1>), списків (<ul> <ol>, and <dl>), спеціального або виділеного тексту (наприклад, <strong> <code> <abbr> <blockquote>) та інших важливих елементів використана семантична верстка.
  • Для табличних даних використовуються таблиці. Клітинки коректно пов'язані зі своїми заголовками по горизонталі та/або вертикалі. Якщо вміст таблиці потребує пояснення, використані теги <caption> <summary>.
  • Пов'язані поля форми згруповані в <fieldset>, що містить осмислений <legend>.
1.3.2. Значуща послідовність читання (Level A)
  • Порядок читання і навігації по сторінці, визначається порядком елементів в HTML-коді, інтуїтивний і логічно обґрунтований, не спотворює суті вмісту.
1.3.3. Сенсорні характеристики (Level A)
Якщо це не є невід'ємною і неминучою частиною функціоналу:
  • У тексті відсутні відсилання до форми, розмірів і розташування елементів, вказівки щодо користування сторінкою не зав'язані на цих характеристиках (наприклад, "Натисніть на квадратну іконку", "Інструкцію можна знайти в правій колонці" і т. д.).
  • Використання сторінки не зав'язано на звуці (наприклад, "Продовжите після звукового сигналу").
1.4. Вибірковість: спростіть перегляд і прослуховування контенту, відокремивши важливі частини від другорядних
1.4.1. Використання кольору (Level A)
  • Колір не використовується в якості єдиного засобу надання вмісту, індикації або відмінності елементів.
  • Колір не використовується як єдиний засіб позначення посилань на тлі решти тексту, за винятком випадку, коли контраст яскравості між квітами тексту і посилань не менше 3:1, і при навігації або фокусі посилання отримує додаткові відмінності (наприклад, підкреслення).
1.4.2. Управління звуком (Level A)
  • Якщо на сторінці є звук, який автоматично програється більше 3 секунд, необхідно дати можливість його зупинити, поставити на паузу, заглушити або налаштувати його гучність.
1.4.3. Контраст (Level AA)
  • Текст і текст на зображеннях повинні мати коефіцієнт контрастності не менше 4,5:1.
  • Збільшений текст і зображення збільшеного тексту мають коефіцієнт контрастності не менше 3:1.
1.4.4. Зміна розмірів тексту (Level AA)
  • Бажано, щоб сторінка залишалася читається і функціональної при збільшенні масштабу в межах до 200%. Особливо це актуально для блоків, що містять дрібний і низкоконтрастный текст.
1.4.5. Текст на зображеннях (Level AA)
  • Якщо можна домогтися такого ж візуального представлення допомогою доступного тексту, і якщо зміст тексту в зображенні не має ключового значення (логотип, скріншот і т. п.), то не слід використовувати зображення, що містять текст.
2.1. Доступність управління з клавіатури
2.1.1. Клавіатура (Level A)
  • Весь функціонал повинен бути доступний для керування з клавіатури, за винятком випадків, коли це в принципі неможливо (наприклад, малювання від руки).
    Необхідно переконатися в працездатності як в поєднанні з екранними читцями, так і без.
  • Всі елементи, з якими можна взаємодіяти, повинні приймати фокус. У разі, якщо реалізовано натискання на елемент, воно повинно бути доступно нарівні як за допомогою миші, так і за допомогою клавіатури.
    За замовчуванням, фокусування і взаємодію з клавіатурою підтримують елементи форми, кнопки <button> і посилання <a href>.
  • Власні реалізації елементів управління або введення повинні надавати ті ж можливості для взаємодії за допомогою клавіатури, що і вбудовані в браузер елементи та/або приклади реалізації схожих віджетів на спеціалізованих сайтах з доступності (наприклад, Open Ajax Accessibility).
    Треба пам'ятати, що реалізації віджетів на цих сайтах може бути не ідеальною, і в багатьох випадках може знадобитися їх доопрацювання або виправлення. Необхідно перевіряти складні рішення в екранних чтецах.
  • Рекомендується уникати використання атрибута accesskey без необхідності. Атрибут accesskey потрібно застосовувати з обережністю: він не повинен конфліктувати з популярними гарячими клавішами екранних читців (JAWS, NVDA). На російській версії рекомендується вибирати accesskey таким, щоб символ розташовувався на одній і тій же кнопці в російській і англійській розкладці.
  • Завдання позитивного tabindex може викликати проблеми з порядком перемикання фокусу.
  • Використання обробників mousedown і mouseup як обробників натискання на елемент буде призводити до недоступності його з клавіатури. Також не забезпечує доступність подія click на не фокусованих за замовчуванням елементах, тобто всіх, крім елементів форми, кнопок <button> і посилань <a href>.
    Рекомендується уникати таких випадків, але якщо це неможливо, то для таких елементів необхідно додатково прописувати обробку подій клавіатури.
  • Відкриваються при наведенні миші підказки або меню також повинні бути доступні з клавіатури. Можна, наприклад, показувати (а для підказок ще й озвучувати) текст елемента при фокусі.
    Специфікація ARIA передбачає атрибут aria-haspopup для реалізації подібних віджетів (наприклад), але з його підтримкою і роботою з клавіатури без екранних читців є питання.
  • Екранні читці можуть перекрити обробку натискання деяких клавіш (наприклад, стрілок клавіатури або букв в режимі читання — без фокусу на елементах форми), тому до обробки натиснення клавіш поза полів форми потрібно ставитися з обережністю, спочатку продумувати і згодом тестувати їх поведінка в поєднанні з екранними читцями; перевизначення обробки натискання TAB також може викликати проблеми з порядком перемикання фокусу.
2.1.2. Відсутність пасток для фокуса (Level A)
  • Фокус при попаданні на будь-який елемент або групу елементів ніколи не застряє в них, і може бути вільно переміщений на будь-який доступний для управління елемент на сторінці.
2.2. Достатній час: надайте користувачам достатньо часу для ознайомлення і роботи з контентом
2.2.1. Налаштування часу (Level A)
  • Якщо сторінка або програми мають тимчасові обмеження, то у користувача повинна бути можливість його вимкнути, налаштувати, продовжити.
  • Винятки, передбачені стандартом:
    • що працюють в реальному часі програми;
    • випадки, коли обмеження по часу мають ключове значення і не можуть бути прибрані без шкоди для функціоналу, інформаційної значущості сторінки або безпеки;
    • обмеження по часу більше 20 годин.
2.2.2. Пауза, зупинка, приховання. (Level A)
  • Користувач повинен мати можливість зупинити, поставити на паузу або приховати тривають більше 5 секунд руху, мерехтіння або перемотування будь-яких елементів. Це не відноситься до індикаторів завантаження.
  • Для анімації переходів і залучення уваги користувачів можна використовувати рух, мерехтіння або перемотування тривалістю менше 5 секунд.
  • Також повинна бути можливість поставити на паузу автоматичне оновлення будь-якого змісту, за винятком випадків, коли оновлення має ключове значення, і без нього сторінка втрачає сенс.
Стандарт передбачає виключення з правил, якщо відсутня технічна можливість або якщо анімація або оновлення мають ключове значення для функціоналу сторінки, і без них змінюється зміст або поведінку сторінки. Приклади винятків з поясненням можна знайти у поясненнях до критерію.
Критерій досить строгий, і повне дотримання йому іноді може зажадати багато часу на розробку і погіршити користування сторінкою для звичайних користувачів. Потрібно шукати компроміс між строгими формальними вимогами стандарту і реальністю в кожному випадку, але при цьому потрібно продумувати взаємодія для кожної з перелічених категорій користувачів (див. Вступ).
2.3. Не використовуйте свідомо небезпечні для здоров'я елементи дизайну
2.3.1. Обмеження в три або менше спалаху в секунду (Level A)
  • На сторінці не повинно бути елементів, які спалахують більше 3 разів на секунду. Детальний опис понять спалаху і допустимих значень можна знайти в стандарті https://www.w3.org/Translations/WCAG20-ru/#general-thresholddef.
2.4. Навігація: надайте користувачам допомогу і підтримку в навігації, пошуку контенту і у визначенні їх поточного становища на сайті
2.4.1. Пропуск повторюються на всіх сторінках блоків (Level A)
  • Є посилання для пропуску повторюваних блоків.
  • Є коректна ієрархія заголовків починаючи з рівня 1.
2.4.2. Заголовок сторінки (Level A)
  • Сторінка має інформативний заголовок <title>, описує її призначення і цілі.
  • При навігації по сайту без перезавантаження сторінки також слід змінювати вміст <title>.
2.4.3. Порядок переміщення фокуса (Level A)
  • Порядок переходів по посиланнях, елементів форми та ін. об'єктів інтуїтивно зрозумілий і логічно обґрунтований.
2.4.4. Призначення посилання (у контексті) (Level A)
  • Призначення кожної посилання (або іншого активного елемента) ясно з самого тексту посилання, або з тексту посилання в поєднанні з її програмно обчислюється контекстом.
  • Посилання з однаковим текстом, що ведуть у різні місця, легко помітні між собою.
2.4.5. Різні способи пошуку (Level AA)
  • Користувачеві доступно більше одного способу пошуку потрібної веб-сторінки: список пов'язаних сторінок, зміст, карта сайту, пошук, список всіх сторінок сайту і т.д.
2.4.6. Заголовки і мітки (Level AA)
  • Заголовки і мітки (<label> <legend>, aria-label) повинні бути інформативні та чітко описувати ту частину сторінки або той елемент, до якого вони відносяться.
  • Бажано уникати повторюваних заголовків і міток, якщо тільки структура сторінки не надає очевидного способу їх розрізнення.
2.4.7. Видимий фокус (Level AA)
  • Елемент з фокусом повинен бути чітко помітний.
3.1. Читабельність: зробіть весь текстовий контент читання та зрозумілим
3.1.1. Мова сторінки (Level A)
  • Мову сторінки необхідно вказувати за допомогою атрибута <html lang>.
3.1.2. Мова частин сторінки (Level AA)
  • Для елементів, мова яких відрізняється від мови сторінки, його також необхідно вказувати за допомогою атрибута lang.
3.2. Передбачуваність відображення і функціоналу
3.2.1. Передбачуваність при фокусі (Level A)
  • Потрапляння фокусу на який-небудь елемент не повинна викликати значних змін на сторінці (зміни контексту):
    • перехід на іншу сторінку;
    • відкриття спливаючого вікна;
    • втрата або непередбачуване повторне зміна фокуса;
    • непередбачувана перемотування сторінки;
    • інші зміни, які можуть заплутати або збити з пантелику користувача.
  • Такі речі, як розгортка списку, показ динамічного меню або перемикання табуляторного елемента керування, допустимі. Детальніше див. стандарт WCAG 2.0.
3.2.2. Передбачуваність при введенні (Level A)
  • Введення інформації або взаємодія з яким-небудь поля або елемента керування не повинен викликати значущих змін на сторінці (зміни контексту), якщо користувач не був проінформований про це заздалегідь.
    Приклади зміни контексту можна знайти вище в п. 3.2.1.
  • Найбільш поширений випадок — перехід на іншу сторінку або відкриття нового вікна за події onchange на елементах <select>, радіокнопках або чекбоксах. За можливості слід уникати такої поведінки, переходити на сторінку лише за допомогою натискання на кнопку або на ENTER [G80][g80].
    При тестуванні слід врахувати, що подія onchange в різних браузерах спрацьовує по-різному.
3.2.3. Однакова навігація (Level AA)
  • Навігаційні елементи, представлені на декількох сторінках сайту, при навігації по сайту не повинні змінювати порядок і розташування.
3.2.4. Однаковість назв (Level AA)
  • Елементи зі схожою функціональністю на різних сторінках повинні бути підписані схожим чином.
3.3. Допомога при введенні: допомагайте користувачам уникати помилок при введенні інформації та виправляти їх
3.3.1. Виявлення помилок (Level A)
  • Обов'язкові поля розмічені відповідним чином для зрячих і незрячих: згадка про обов'язковість поля в <label>, атрибут aria-required на полі введення.
  • Помилки форми повинні бути представлені в інтуїтивному і доступному вигляді.
    У більшості випадків рекомендується наступний підхід: у елемента з помилкою повинен бути id, по якому на нього поле посилається за допомогою атрибута aria-describedby.
    Атрибут aria-describedby динамічно змінюється: у звичайному стані він вказує на підказку або опис поля, а у випадку помилки введення — на текст помилки (замість або разом з підказкою — aria-describedby може містити декілька ідентифікаторів).
  • Бажано надати загальне повідомлення про помилку на початку сторінки. Плюсом буде також можливість переходу з повідомлення по посиланню до першого поля з помилкою.
    У всіх деталях дана техніка описана у статті від WebAIM.
  • Щоб негайно зачитати помилку користувачеві у деяких випадках можна використовувати повідомлення з допомогою role="alert" або aria-live [ARIA21][aria19].
3.3.2. Текстові мітки та інструкції для полів вводу (Level A)
  • Є інформативні і правильно пов'язані мітки (<label>, aria-label, aria-labelledby), підказки та інструкції (aria-describedby), приклади заповнення полів, заголовками угруповань полів (<legend>).
    • Підказки та інструкції до полів введення і посиланнях, пов'язані з допомогою aria-describedby ([ARIA1][aria1], [OAA44][oaa44]).
    • Позначення обов'язкових полів з допомогою aria-required або required ([ARIA2][aria2]).
    • Позначення полів з помилкою за допомогою aria-invalid [ARIA21][aria21].
    Слід звернути увагу на поля складаються з кількох елементів (наприклад, радіокнопки, вибір дати — від і до, телефон — окремо код та номер і т. д.): необхідно синтактически зв'язати загальну текстову мітку з кожним полем. Наприклад, <fieldset> <legend>, або aria-labelledby="field-label-id subfield-label-id", або aria-label="Дата від".
3.3.3. Підказки при помилках (Level AA)
  • За помилки в заповненні форми, знайдених на клієнтській або серверній стороні, коли це доречно, потрібно виводити в доступному вигляді підказки та рекомендації щодо їх виправлення.
3.3.4. Запобігання помилок (для юридичних, фінансових і користувальницьких даних) (Level AA)
Для вводу даних, які мають юридичну або фінансову значущість, для інших контрольованих користувачем даних (визначення дано в стандарті), виконується хоча б одне з вимог:
  • Перевірка. Дані, введені користувачем, перевіряються на наявність помилок, і користувачу надається можливість виправити помилки.
  • Підтвердження. Надано механізм для підтвердження і виправлення інформації перед остаточною відправкою даних. Наприклад, запит на підтвердження дії або перегляд введених даних.
  • Оборотність (якщо можливо). Надіслані дані можна повернути, наприклад, протягом заданого проміжку часу.
4.1. Максимальна сумісність з існуючими та майбутніми додатками, включаючи ассистивные технології
4.1.1. Синтаксис (Level A)
  • Відсутні суттєві помилки валідації HTML/XHTML (http://validator.w3.org/)
    Максимальну відповідність специфікації версії HTML не є обов'язковим, але рекомендується (див. техніку [G192][g192]).
    Важливі для доступності сайту моменти:
    • повторюються ідентифікатори (id) елементів ([помилка 77][f77]),
    • помилки використання відкриваючих і закриваючих тегів ([помилка 70][f70]),
    • помилки в іменах тегів і атрибутів,
    • недотримання формату машиночитаних даних (наприклад, помилки в URL, в значеннях тегом <time> і атрибуту datetime).
    • інші помилки, якщо вони можуть спотворити сприйняття сайту браузерами і екранними читцями.
4.1.2. Задані імена, ролі, значення, стану і взаємозв'язку між елементами (Level A)
  • Розмітка повинна коректно сприйматися програмами доступу.
  • Контрольовані браузером стану (managed state — фокус і виділення тексту — повинні бути задані коректно в кожен момент часу. Це може бути або вбудований механізм фокусу, або один з описаних тут: Providing Keyboard Focus.
  • Якщо елементи мають ролі, значення, назви, або між ними є відносини, вони повинні бути виражені по можливості з допомогою role, aria-* та інших атрибутів.
    Нижче неповний перелік випадків, коли доречна додаткова семантична розмітка:
    • Надання текстових міток полів посиланнях і керуючим елементів, підписів до зображень ([ARIA6][aria6] — [ARIA10][aria10], [ARIA14][aria14] — [ARIA16][aria16]).
    • Розмітка структури сторінки: семантичних областей, заголовків[ARIA11][aria11] — [ARIA13][aria13], [ARIA20][aria20]).
    • Групування полів форми в role="group" — аналог <fieldset> ([ARIA17][aria17]).
    • Зачитываемые користувачам помилки і попередження ([ARIA18][aria18], [ARIA19][aria19]).
    • Скасування семантики елемента з допомогою role="opendocument" (наприклад, щоб використовувана для верстки таблиця не сприймалася як таблиця з даними).
    • Розмітка індикаторів завантаження role=progressbar ([OAA27][oaa27]).
    • Розмітка відкриваються поверх сторінки модальних вікон з допомогою role="dialog" ([OAA2][oaa2], WAI ARIA Authoring practices 3.3).
    • Розмітка вкладок або акордеона з допомогою role="tablist". ([OAA34][oaa34], [OAA35][oaa35], [OAA36][oaa36], [OAA37][oaa37]).
    • Розмітка власної реалізації комбінованого списку за допомогою role="combobox". ([OAA9][oaa9], [OAA12][oaa12]).
    • Розмітка поля вводу з автодополнением role="combobox" і aria-autocomplete="list" ([OAA11][oaa11], [OAA14][oaa14]).
    • Розмітка посилання, що розкриває або приховує якийсь блок на сторінці з допомогою aria-expanded (w3c wiki).
      Увага! Приклад на Open Ajax Accessibility містить помилку і суперечить наприклад на w3c wiki і специфікації WAI-ARIA, не слід на нього посилатися або використовувати. Атрибут aria-expanded повинен бути не у розкривного елемента, а у пов'язаної кнопки або посилання.
    • Розмітка інтерактивного меню з вкладеними елементами ([OAA26][oaa26], [OAA27][oaa27], WAI ARIA Authoring practices 4.4).
    • Розмітка слайдера (вибору значення у діапазоні) з допомогою role="slider" ([OAA32][oaa32]).
    • Розмітка дерев з допомогою role="tree" ([OAA41][oaa41], [OAA42][oaa42], [OAA43][oaa43]).
    • Приховування елементів з допомогою aria-hidden="true".
Післямова
  • Спасибі @Harut.
  • Ви можете взяти участь у коригуванні цього чеклиста у нас на GitHub.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.