Від автора: у цій статті буде розглянуто перевірка доступності сайту, показано, як використовувати автоматичні і ручні засоби для роботи з настільними і мобільними версіями. Ми розглянемо п’ять інструментів тестування доступності, які можуть бути встановлені або як розширення браузера, або букмарклет JavaScript. Я вкажу всі плюси і мінуси кожного інструменту тестування, опишу кращі функції окремого інструменту і покажу, які проблеми доступності добре розпізнає кожен інструмент.
Важливо пам’ятати, що автоматичні інтсрумент тестування доступності ніколи не зможуть замінити ручне зчитування екрану і тестування на клавіатурі. Ми обговоримо, як автоматизовані інструменти для перевірки доступності по сторінкам вписуються в процес ручного тестування і як використання автоматизованих інструментів на ранніх етапах розробки може заощадити час тестувальників QA, щоб уникнути документування дуже простих проблем доступності.
Ми поговоримо про те, які інструменти тестування працюють на настільних веб-браузерах, а які інструменти тестування можна використовувати безпосередньо з мобільного пристрою. Якщо ви тестуєте настільні і мобільні подання з урахуванням налаштованого дизайну, ви можете використовувати ті ж інструменти для перевірки доступності на робочому столі, щоб протестувати сайт RWD.
Вивчення доступності через інструменти тестування
Установка і використання інструментів автоматичного і ручного тестування доступності — відмінний спосіб для розробників і тестувальників QA вивчити доступність, не вникаючи в складність навчання ручного тестування екранного рідера.
Інструменти тестування спеціальних можливостей допоможуть вивчити доступність веб-сторінок, оскільки більшість з них містять будь-яку довідкову документацію помилок або виконують роботу, вказуючи на помилки, які можна навчитися уникати при кодуванні.
Замість того, щоб спочатку вивчати WCAG, можна безпосередньо використовувати інструменти тестування доступності і знати, що якщо виправити всі проблеми, про які повідомляють кілька інструментів, сайт, ймовірно, буде досить доступний, навіть не прочитавши WCAG або не використовуючи програму читання з екрану.
Інструменти тестування не можуть знайти всі проблеми з доступністю, тому завжди потрібно ручне тестування з використанням клавіатури і пристрої читання з екрану.
Вивчення і використання інструментів тестування vs. читання екрану
Набагато простіше дізнатися, як використовувати простий інструмент тестування спеціальних можливостей, ніж програмне забезпечення допоміжних технологій. Читання екрану дуже складний процес, і іноді тестери можуть повідомляти хибнопозитивні помилки доступності, засновані на непорозуміння щодо нормального поведінки зчитувача. Можливо, буде потрібно встановити платне пристрій читання з екрану, або воно може сповільнити роботу системи. Можуть бути інші причини, за якими не завжди є можливість тестувати читанням екрану.
Тестування лише на клавіатурі
http://pauljadam.com/demos/focusvisible.html
Тестування на одній тільки клавіатурі — це простий і потужний метод тестування доступності, який гарантовано знайде проблеми або з відсутніми індикаторами фокуса клавіатури, або просто без фокусування і без клавіатури. Сучасна мережа жахлива при проектуванні і кодуванні для роботи з клавіатурою, тому, перш ніж витрачати занадто багато часу на вивчення екранних програм, обов’язково виконуйте базову перевірку на клавіатурі за допомогою ТАБУЛЯЦІЇ, проводячи навігацію по сторінці, і спробуйте інші ключі для складних віджетів, наприклад, Escape для меню та діалогу, Up/ Down/ Right/ Left стрілки для інших окремих елементів управління.
ARIA Authoring Practices покаже вам, як користувальницькі елементи управління і віджети повинні вести себе і як вони мають бути закодовані для читання екрану і клавіатури користувачів.
Точне тестування доступності для розробників і дизайнерів
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/main.html
Перевага автоматичних засобів тестування доступності — як можна раніше змусити розробників і дизайнерів використовувати ці інструменти і вирішити свої проблеми доступності до того, як вони перейдуть на QA і тестери доступності. Використання автоматизованих інструментів на ранніх етапах розробки може заощадити час тестувальникам QA, щоб вони не витрачали його на документування найпростіших проблем доступності, на які розробники могли помітити з допомогою одного з цих інструментів тестування.
Якщо ви коли-небудь писали звіт про доступність з сотнею і більше проблем, вам би не хотілося витрачати час на створення проблем і рекомендацій для простих збоїв, начебто відсутнього текст, відсутніх ярликів або низького колірного контрасту, який легко може виявити автоматизований інструмент.
Інтеграція інструментів в процес перевірки доступності вручну
Під час ручного читання екрану і тестування доступності тільки на клавіатурі також можна запускати автоматичні інструменти тестування з розширень браузера і букмарклет, щоб знайти більше проблем.
Використання цих інструментів в основному являє собою комбінацію ручного процесу тестування області перевірки або користувальницьких потоків, а для кожної відвідуваної сторінки, екрану чи діалогу потрібно запускати всі улюблені інструменти тестування доступності, документувати проблеми, а потім виконувати читання і тестування клавіатури до або після використання автоматизованих інструментів.
У кожного є інший процес і потік для тестування доступності, немає правильного або неправильного порядку, тому він допомагає запускати кілька тестових інструментів, тестувати тільки на клавіатурі, тестувати за допомогою декількох програм читання з екрана, а також тестувати на iPhone або iPad, щоб знайти ще більше проблем. Чим більше методів тестування ви використовуєте, тим більше проблем знайдете, і в кінцевому результаті виберете деякі з улюблених інструментів і методів і повторіть їх для всіх веб-сайтів, які тестуєте.
П’ять інструментів перевірки доступності для вашого інструментарію
WAVE
aXe
a11yTools
tota11y
HTML_CodeSniffer
Це п’ять інструментів перевірки доступності, які я хотів би використовувати на регулярній основі для тестування доступності та звітності. У кожного інструменту є свої плюси і мінуси, і у кожного є певні проблеми з доступністю, для ідентифікації яких вони відмінно підходять.
Тестери доступності мають різні настройки для інструментів, а також ті браузери та інструменти розробника, які вони використовують. Я користувач MacOS і iOS, і Safari — мій улюблений браузер для особистого використання і для перевірки коду і тестування.
Safari і Chrome – два моїх головних браузера, іноді я використовую Firefox для тестування інструментів і подвійної перевірки деяких проблем, наприклад, таких як видимість клавіатури.
Хороші / погані можливості демонстрації і тестування сторінки
Щоб дізнатися, як використовувати інструменти тестування доступності, запустіть їх на деяких хороших і поганих сторінках демонстрації доступності, прочитайте всі помилки, які з’являються на поганих сторінках, потім запустіть їх на хороших сторінках і подивіться відмінності.
Я буду використовувати ці три сайту в якості прикладів тестування для інструментів.
Accessible University 3.0
W3C BAD – Before and After Demo
Form Bad / Form ARIA
WAVE
WAVE був одним з перших інструментів тестування доступності, який я коли-небудь використав, і я все ще вважаю його дуже цінним, коли тестую.
WAVE доступний для Firefox, Chrome у якості розширень браузера, або ви можете використовувати його з веб-сайту WAVE в якості онлайн-інструменту тестування. Розширення браузера WAVE набагато потужніше, ніж веб-сайт WAVE, тому що ви не зможете використовувати онлайн-WAVE за захищеними паролем веб-сайтами, і іноді онлайн-версія не працює на дуже складних веб-сайтах. Розширення WAVE працюють за брандмауером, швидше запускають тести і обробляють складні веб-сайти.
Основні кроки використання WAVE — відвідати кожну сторінку, яку ви хочете протестувати, і натиснути кнопку значка WAVE розширення браузера, щоб побачити порушення доступності.
Натискайте значки, які з’являються, і ви можете прочитати помилки доступності або повідомлення про успішність у підказках значків.
Перейдіть на вкладку Contrast, щоб побачити кольорові контрастні помилки в тексті. Автоматизовані інструменти зазвичай не виявляють помилки контрасту за допомогою наповнювачів чи зображень тексту, тому протестувати потрібно вручну. Для ручної контрастною перевірки того, що пропустить автоматичний інструмент, я рекомендую Colour Contrast Analyser.
Вкладка No Styles покаже сторінку без стилів CSS і спростить пошук значків помилок WAVE, які були візуально приховані через макета сторінки. Тому пам’ятайте, коли ви не бачите значки помилок на сторінці, вони можуть бути візуально приховані, і вам потрібно перевірити їх на вкладці No Styles.
Посилання для скачування
WAVE Firefox
WAVE Chrome
Ви можете відвідати WAVE Online Report наших сторінок тестування, навіть якщо не можете встановити розширення браузера. Пам’ятайте, що розширення браузера будуть працювати за сайтами, захищеними паролем і паролем, тоді як онлайн-версія WAVE не буде тестувати сайти з підтримкою входу в систему.
Inaccessible University WAVE Report
Accessible University WAVE Report
W3C BAD Survey Form Demo WAVE Report
W3C GOOD Survey Form Demo WAVE Report
«+»
Іконки з помилками доступності і спливаючі підказки WAVE чудові і зрозумілі.
WAVE Online-сервіс означає, що він може працювати на будь-якому веб-сайті, не має логін.
Розширення для Chrome і Firefox.
Ні одна кнопка стилів не допомагає знайти проблеми зі складними веб-сторінками, які візуально приховані, але все ж помилки.
WAVE Online дозволяє вам стежити за сайтом і тестувати нові сторінки по мірі їх завантаження.
WAVE доступний тільки для читання екрану і клавіатури.
Я можу використовувати WAVE Online в Safari, коли тестую публічний сайт.
Тести для можливих заголовків, в яких відсутні теги заголовків.
«-»
Іноді WAVE не може обробляти дуже складні веб-сайти.
Іноді помилки важко побачити, якщо ви не натиснете кнопку No Styles.
WAVE Online працює повільніше, ніж розширення Chrome і Firefox.
aXe
Це платформа тестування доступності, заснована на JavaScript, яка може бути запущена безліччю способів, наприклад, при безперервному тестуванні складання інтеграції, запускається з командного рядка консолі JavaScript або з розширень браузера за допомогою користувальницького інтерфейсу. Найпопулярніший спосіб використання аХе, ймовірно, через розширення Chrome і Firefox, які надають користувальницький інтерфейс для виводу помилок доступності.
Example aXe Learn More link
axe-core on Github
aXe Rule Descriptions
aXe – розширення для браузера
aXe Firefox
aXe Chrome
Якщо вам потрібен aXe в Safari, у мене є в a11yTools і в ярлику JavaScript, але у нього немає користувальницького інтерфейсу, тому результати потрібно читати в консолі.
«+»
Філософія «без помилкових спрацьовувань» означає, що ви не будете перевантажені безліччю помилок доступності.
Додаткова довідкова документація пояснює проблему і її усунення.
Може запускатися з будь-якого браузера в консолі JavaScript.
Безперервна інтеграція, тестування командного рядка, автоматичне тестування складання.
Точні тести для підвищення чутливості при відключенні в мета вьюпорте.
«-»
Ніякі помилкові спрацьовування не можуть означати, що при виявленні інших помилок не можуть виникнути помилки доступності.
Як і більшість інструментів, ви не знайдете проблем з елементами, які не працюють на клавіатурі, наприклад, div з подією JavaScript onclick.
aXe візуально не виділяє помилки на сторінці, де вони легко виділяються.
Проблеми розширення зчитуються по одній, доводиться багато разів натискати Next.
Мені не подобається, що aXe говорить розробникам, що можна виправити відсутню ім’я доступної форми, використовуючи Aria-мітку, тому що тоді мітка не буде видно.
a11yTools
a11yTools — це розширення для браузера Safari, яке я розробив як набір всіх моїх улюблених інструментів тестування доступності в одному місці в Safari, і яка є моїм основним веб-браузером для особистого використання та програмою читання з екрану VoiceOver.
a11yTools Safari
Bookmarklets version
«+»
Працює на Safari!
Також більшість інструментів доступні в JavaScript Букмарклет для будь-якого браузера.
Об’єднує всі ці інструменти в одне розширення Safari з більш корисними документами, такими як специфікація ARIA, практика ARIA, контрольний список WCAG і т. Д.
a11yTools — це інструмент тестування по часу, в якому ви вибираєте елемент або функцію HTML a11y, і ви тестуєте по одному, а не відразу запускаєте всі тести.
Розширення Safari буде працювати на додаткових захищених веб-сайтах, які блокують букмарклет JavaScript.
Має стару платформу інструментів розробника Google Accessibility, в якій є непогані тести.
Включений інструмент тестування відтінків сірого.
«-»
Немає розширення Chrome або Firefox.
Не запускає відразу всі тести, тільки по одному.
Не завжди має останню топову версію, так як розробник повинен вручну оновлювати її при появі нових випусків.
tota11y
tota11y може мати найкрутіше ім’я з групи інструментів тестування. tota11y — ще один букмарклет JavaScript, який буде працювати в будь-якому браузері. Закладки відмінно підходять для тестування колірного контрасту, коли у вас немає інструменту ручного тестування, доступного на пристрої, на зразок iPhone.
«+»
tota11y класне ім’я
Інструмент тестування заголовків відмінно підходить для тестування неправильних рівнів заголовків і вкладеності і не запускає сторінку з елементом H1.
Відрізняється колір від будь-якого браузера, тому що це букмарклет.
Тести на відсутність позначок.
«-»
Інструмент тестування орієнтирів ARIA здається менш корисним, ніж деякі інші.
Іконки виглядають однаково, тому вони не вистрибують візуально так само швидко, як інші інструменти.
HTML_CodeSniffer
HTML_CodeSniffer це букмарклет JavaScript, який я використовую вже дуже давно. Мені подобається, що він працює в Safari, бо є можливість тестувати на iOS, використовуючи VoiceOver. CodeSniffer може пригнічувати складні веб-сайти, тому що генерує велику кількість помилок, і можуть виникнути помилкові спрацьовування в залежності від методів, обраних розробниками.
Потрібно проклацувати по всім проблемам, щоб побачити подробиці для кожного типу інтерфейсу aXe.
Link to HTML_CodeSniffer
«+»
Тестування квітів та рекомендації за рішенням проблем.
vПоказывает HTML код помилки, пов’язані з цим помилки WCAG і методи вирішення.
Букмарклет, тому він працює у всіх браузерах.
Тестування iframe.
Тести для значень атрибутів повторюваних ідентифікаторів.
«-»
Проблема перевантаження! Спочатку обов’язково відключіть попередження, щоб зменшити шум.
Помилкові спрацьовування.
Майте на увазі, як прочитати всі результати і дізнатися, що ігнорувати, а що дуже корисно.
Мені не подобається, що CodeSniffer каже, що ви можете використовувати атрибут title для виправлення введення форми без доступного імені, бо тоді мітка не буде видно.
Інструменти тестування: настільна версія vs мобільний
Деякі з інструментів в цьому списку будуть запускатися з мобільного браузера, такого як Mobile Safari в iOS або Chrome на Android. tota11y і HTML_CodeSniffer будуть працювати з будь-якого веб-браузера, тому що це ярлики JavaScript, які не встановлені як розширення.
Тестування сайтів адаптивного дизайну
Ви можете використовувати ці ті ж інструменти тестування, щоб протестувати чуйний веб-сайт, відрегулювавши розмір вікна браузера, щоб він був маленьким, як телефон або планшет, або збільшуючи розмір тексту до самого великого, поки ви не активуєте розміри вьюпорта мобільного пристрою і, наприклад, не відобразіть гамбургер меню. Після того, як ви запустите чуйні подання з свого веб-браузера, ви можете запустити всі інструменти перевірки доступності, які ми розглянули.
Для мобільних сайтів, які обслуговують різні HTML-представлення на основі рядка User Agent String, ви можете перемкнути користувальницький агент вашого браузера, наприклад, iPhone або iPad на робочому столі Safari в меню Develop. Переключіть користувальницький агент на мобільний рядок, і тепер браузер завантажить мобільний контент, і ви зможете запускати всі ці автоматизовані засоби тестування і виконувати ручну перевірку клавіатури і перевірку працездатності.
Висновок
Інструменти перевірки доступності — відмінний спосіб вивчити доступність і подвійну або потрійну перевірку, якщо ваш сайт доступний. Існують інструменти перевірки доступності для вашого браузера за вибором або букмарклета JavaScript, які будуть запускатися в будь-якому браузері. Не забудьте об’єднати інструменти тестування доступності з допомогою ручного зчитувача екрану і тестування працездатності клавіатури, і ви виявите більше проблем і створите більш зручний веб-сайт.
Поділіться цими інструментами тестування доступності з розробниками і дизайнерами і попросіть їх протестувати їх роботу якомога раніше і частіше, тому більшість питань можна усунути, перш ніж вони потраплять до тестувальникам QA або іншим експертам.
Є багато доступних інструментів тестування, але у мене не було часу, щоб охопити їх всіх в одній статті. Я більше пов’язаний з моєю сторінкою ресурсів, і, будь ласка, поділіться своїми улюбленими інструментами тестування в коментарях нижче.
Є визначена функція тестування, яку ви хочете або маєте потребу в інструменті тестування? Дайте нам знати в коментарях, може бути, хтось ще знає про інструмент, який може виконати цю роботу, або, може бути, ви будете мотивувати когось створювати їх.
