Поліпшите доступність вашого сайту за допомогою WAI-ARIA

32

Від автора: дана стаття є витягом з книги HTML5 і CSS3 для реального світу, 2-е видання за авторством Алексіса Гольдштейна, Луї Лазариса і Естель Вейль. Книгу можна знайти в магазинах по всьому світу, а також купити цифрову версію.

В розділах 2 і 3 ми розповідаємо основи того, як зробити сторінки більш семантичними і потенційно більш доступними з допомогою нових семантичних елементів HTML5. Однак покращеної семантики часто буває недостатньо, щоб зробити складне веб-додаток повністю доступним.

Щоб зробити контент і функціонал наших сторінок максимально доступними для користувачів, нам необхідно скористатися можливостями WAI-ARIA, наклавши їх на вже існуючих функцій HTML5. У цій статті ми не будемо глибоко розбирати, що таке WAI-ARIA, про це можна написати кілька статей. Але все ж ми подумали, що важливо трохи розповісти про цю технологію, щоб у вас було уявлення.

WAI-ARIA розшифровується як Web Accessibility Initiative-Accessible Rich Internet Applications. На сайті W3C про WAI-ARIA пишуть наступне: «… спосіб, як зробити веб-контент і веб-додатки більш доступними для людей з обмеженими можливостями. Особливо добре працює з динамічним контентом і просунутими елементами інтерфейсу з сильною прив’язкою до JS, розроблених з допомогою Ajax, HTML, JS і супутніх технологій.»

Люди, які змушені переглядати інтернет з скрін рідерами або ті, хто не може використовувати мишу, часто втрачають будь-то функціоналу на сайті або веб-додатку. Наприклад, слайдери, прогрессбары і вкладки. WAI-ARIA дозволяє виправити ці недоліки ваших сторінок, навіть якщо контент і функціонал перебувають у полоні складної архітектури. Таким чином, користувачі з обмеженими можливостями можуть використовувати ті частини сайту, які зазвичай їм недоступні.

Як WAI-ARIA доповнює семантику

WAI-ARIA присвоює елементам ролі, а ролями дає властивості і стани. Простий приклад:

  • Sort by Date
  • Додаток може зв’язати елемент списку з будь-яким контентом. Однак без ролі і атрибуту aria-checked скрін рідер не зможе зрозуміти, для чого потрібен цей елемент. Просто семантика (в нашому випадку елемент списку) не говорить нічого. З допомогою цих атрибутів допоміжний пристрій зможе краще зрозуміти, для чого потрібен цей елемент.

    У більшості випадків для семантичних елементів, наприклад, header, h1 і nav атрибути WAI-ARIA необов’язкові. Ці теги вже і так передають своє призначення. Дані атрибути потрібно використовувати на тих елементах, чий функціонал і призначення можна визначити відразу (або на елементах з невеликою доступністю або взагалі без неї в одному або більше основних браузерів).

    Поточний стан WAI-ARIA

    Специфікація WAI-ARIA все ще поліпшується, як і HTML5, тому ці технології ще дадуть нам всі необхідні переваги. Ми вже розповіли, як за допомогою WAI-ARIA розширити семантику елементів на сторінці, однак ролі WAI-ARIA необхідно також надавати тим елементам, які вже своєю назвою висловлюють призначення, так як допоміжні технології не підтримують всі семантичні теги HTML5. Іншими словами, WAI-ARIA можна використовувати в якості тимчасового рішення для поліпшення доступності HTML5 сторінок, поки підтягуються скрін рідери.

    Розберемо, наприклад, меню сайту:

    Здавалося б, ми дублюємо семантику: тег nav вже каже, що набір посилань усередині нього виступає в ролі меню, однак ми додали WAI-ARIA роль navigation. У безлічі випадків такий тип дублювання буде обов’язковим. У випадку з тегом nav на даний момент тільки браузер IE неправильно виставляє роль navigation, тому атрибут у даному випадку необхідний.

    Чи означає це, що WAI-ARIA стане непотрібним, коли семантика HTML5 і доступність будуть повністю підтримуватися? Немає. У WAI-ARIA тобто ролі, що не мають аналогів серед HTM5 тегів. Наприклад, роль timer. Для імітації таймера в HTML5 можна використовувати тег time і оновлювати час через JS, проте це ніяк не говорить скрін рідера, що це таймер. Він думає, що це просто статичний час.

    Для передачі WAI-ARIA ролей в скрін рідер браузер повинен передати їх через API доступності. Це дозволяє скрін рідера взаємодіяти з тегами, як з нативними елементами управління комп’ютера.

    Підтримка ARIA в браузерах зростає, і на даний момент досягла хороших значень. Всі нові версії браузерів, хоча б частково, підтримують WAI-ARIA. На сайті Paciello Group можна знайти новітнє керівництво за підтримки функцій доступності зразок WAI-ARIA в браузерах на певних ОС.

    Варто також сказати, що не всі користувачі, які могли б використовувати WAI-ARIA, використовують дану технологію. У січні 2014 WebAIM (Web Accessibility In Mind) провели свій п’ятий опитування по скрін рідерам, де з’ясували, що 28% опитаних рідко або взагалі не користуються засобами ARIA для навігації по сторінкам. Серед хороших новин можна відзначити, що кількість користувачів, що використовують WAI-ARIA, зросла. У 2010 році за результатами подібного опитування більше 50% або не використовувати ARIA ролі, або не знали про них.

    Якщо коротко, у WAI-ARIA досить хороша підтримка, і ви точно не зіпсуєте свій HTML5, якщо пропишіть ці атрибути. Атрибути проходять HTML5 валідацію, а всіх переваг не злічити, специфікація досі поліпшується.

    Додаткові джерела

    Як я писав вище, пояснення всіх ролей WAI-ARIA виходить за рамки даної книги, але якщо вам цікаво, в першу чергу можемо порекомендувати офіційну специфікацію. На W3C є скорочений довідник і практичне керівництво.

    Можете ознайомитися зі статтею Стефана Макса знайомство з WAI-ARIA на SitePoint. Також можете зайти на сайт HTML5 Accessibility, яким займається експерт по доступності Стів Фолкнер. Він побудував таблиці з описом підтримки семантичних HTML5 тегів в браузерах з точки зору доступності.