Тестування доступності у Playwright: від встановлення до першого звіту

Тестування доступності стає невіддільною частиною процесу забезпечення якості сучасних вебдодатків. В тому числі тому, що, як ми вже згадували в статті «Playwright на практиці», це допомагає компаніям уникнути потенційних штрафів за недотримання вимог доступності. Автоматизовані тести доступності можуть виявити поширені проблеми, однак багато питань можна виявити лише шляхом ручного тестування. Наприклад, таких як логічність порядку фокусування елементів при навігації з клавіатури, зрозумілість альтернативних текстів для зображень у контексті сторінки, відповідність кольорової гами та контрасту для різних сценаріїв використання, правильність роботи адаптивного дизайну на різних пристроях та при різних налаштуваннях масштабу, а також коректність озвучування динамічного контенту програмами зчитування з екрана. Саме тому ми рекомендуємо використовувати комбінований підхід для всебічної оцінки доступності.

Вебтестування доступності з використанням Playwright надає нам потужний інструмент для автоматизації цього процесу. Завдяки інтеграції Playwright з Axe-Playwright або інших бібліотек, про які ми згадуємо в цій статті , ми можемо ефективно виконувати тестування доступності, покращуючи як користувацький досвід, так і відповідність стандартам. У цій статті ми розглянемо, як налаштувати середовище для тестування доступності, створити базові сценарії та ефективно аналізувати результати. Таким чином, ви зможете впровадити тестування доступності у свій процес розробки та забезпечити більш інклюзивний досвід для всіх користувачів ваших додатків.

WCAG: ключ до доступності вебконтенту

Тут варто зупинитися на стандарті WCAG та пояснити що це таке. Отже, WCAG (Web Content Accessibility Guidelines) — це міжнародний стандарт доступності вебконтенту, розроблений Консорціумом Всесвітньої павутини (W3C). Ці рекомендації визначають, як зробити вебсайти та додатки доступними для людей з різними обмеженнями, включаючи порушення зору, слуху, рухливості та когнітивні особливості.

Ключові аспекти WCAG:

1. Рівні відповідності: WCAG має три рівні — A, AA та AAA, де AAA є найвищим рівнем доступності.
2. Принципи: WCAG базується на чотирьох основних принципах: сприйняття, керованість, зрозумілість та надійність.
3. Постійне оновлення: стандарти регулярно оновлюються для відповідності сучасним технологіям. Наприклад, WCAG 2.1 розширює попередню версію 2.0, додаючи нові критерії для мобільних пристроїв.
4. Практичне застосування: дотримання WCAG не лише робить вебсайти доступнішими, але й покращує SEO та загальний користувацький досвід.

Для розробників та тестувальників важливо розуміти та впроваджувати ці стандарти, щоб створювати інклюзивні цифрові продукти та уникати потенційних штрафних санкцій в разі недотримання вимог. Таких як контрастність, розмір елементів та правильне використання HTML-тегів і атрибутів для програм зчитування з екрана є критично важливими аспектами доступності. Саме ці деталі можуть значно вплинути на користувацький досвід.

Наприклад:

1. Контрастність: недостатній контраст між текстом і фоном може зробити контент нечитабельним для людей з вадами зору.
2. Розмір елементів: занадто малі кнопки чи поля вводу можуть створювати проблеми для користувачів з обмеженою моторикою.
3. HTML-теги та атрибути: правильне використання семантичних тегів (як-от, ,) та ARIA-атрибутів суттєво покращує навігацію для користувачів програм зчитування з екрана.

У нашій практиці ми рекомендуємо створювати чек-листи, які включають перевірку цих аспектів. Це допомагає забезпечити, що жоден важливий елемент доступності не буде пропущений під час розробки та тестування.

Перш ніж розпочинати тестування доступності, необхідно налаштувати відповідне середовище. Процес підготовки складається з кількох основних кроків та встановлення необхідних інструментів.

Для початку переконайтеся, що у вас встановлено Node.js та менеджер пакетів npm або yarn. Це легко перевірити, виконавши в терміналі команди node -v та npm -v (або yarn -v). Якщо ці інструменти відсутні, спочатку встановіть їх, скориставшись інструкціями з офіційного сайту Node.js.

Наступним кроком є встановлення Playwright. Для цього виконайте одну з таких команд:

npm install -D @playwright/test

# або

yarn add -D @playwright/test

Після цього потрібно встановити інтеграцію з Axe-core — бібліотекою, яка забезпечує функціональність тестування доступності:

npm install -D @axe-core/playwright

# або

yarn add -D @axe-core/playwright

Додатково можна встановити пакет для генерації HTML-звітів, який допоможе візуалізувати результати тестування:

npm install -D axe-html-reporter

Тепер створимо базовий файл для тестування доступності. Назвіть файл, наприклад, accessibility.test.js і додайте такий код:

import { test, expect } from '@playwright/test';

import AxeBuilder from '@axe-core/playwright';

test.describe('Тестування доступності', () => {

  test('Головна сторінка не повинна мати порушень доступності', async ({ page }) => {

    await page.goto('https://your-website.com'); // Замініть на URL вашого сайту

    // Виконати аналіз доступності

    const results = await new AxeBuilder({ page }).analyze();

    // Перевірити, що немає порушень

    expect(results.violations).toEqual([]);

  });

});

У цьому прикладі ми імпортуємо необхідні модулі: @playwright/test для фреймворку тестування та @axe-core/playwright для інтеграції Axe. Клас AxeBuilder ініціалізується з об'єктом сторінки Playwright і використовує метод analyze() для виконання перевірок доступності.

Щоб запустити тест, виконайте команду:

npx playwright test accessibility.test.js

Крім того, можна налаштувати тестування для різних браузерів. Playwright підтримує роботу з Chromium, Firefox та WebKit, а інтеграція з Axe-core працює з усіма цими браузерами.

Після налаштування середовища настав час перейти до створення та запуску тестів доступності. Playwright разом з Axe надає потужний інструментарій для автоматизованої перевірки вебресурсів на відповідність стандартам доступності.

Насамперед розглянемо базовий сценарій перевірки всієї сторінки.

Цей підхід дозволяє виявити автоматично визначені проблеми доступності:

import { test, expect } from '@playwright/test';

import AxeBuilder from '@axe-core/playwright';

test.describe('Тестування доступності', () => {

  test('Сторінка не повинна мати автоматично виявлених проблем доступності', async ({ page }) => {

    await page.goto('https://your-website.com');

    const results = await new AxeBuilder({ page }).analyze();

    expect(results.violations).toEqual([]);

  });

});

У цьому прикладі AxeBuilder({ page }).analyze() запускає сканування всієї сторінки та зберігає результати у змінній results. Якщо масив violations порожній, тест успішно пройдено.

Крім того, Axe дозволяє налаштувати тести для перевірки тільки певних частин сторінки. Це особливо корисно для компонентів, які з'являються після взаємодії:

test('Меню навігації не повинно мати проблем доступності', async ({ page }) => {

  await page.goto('https://your-website.com');

  await page.locator('button[aria-label="Меню навігації"]').click();

  // Важливо дочекатися, поки елемент з'явиться, перш ніж запускати аналіз

  await page.locator('#navigation-menu').waitFor();

  const results = await new AxeBuilder({ page })

    .include('#navigation-menu')

    .analyze();

  expect(results.violations).toEqual([]);

});

Для перевірки на відповідність конкретним стандартам WCAG можна використати метод withTags(). Стандартний набір тегів включає:

• wcag2a - для перевірки відповідності WCAG 2.0 рівня A;
• wcag2aa - для WCAG 2.0 рівня AA;
• wcag21a - для WCAG 2.1 рівня A;
• wcag21aa - для WCAG 2.1 рівня AA.

test('Сторінка не повинна мати порушень WCAG A та AA', async ({ page }) => {

  await page.goto('https://your-website.com');

  const results = await new AxeBuilder({ page })

    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])

    .analyze();

  expect(results.violations).toEqual([]);

});

Варто зазначити, що для повноцінного тестування доступності автоматизовані тести слід поєднувати з ручними перевірками, оскільки не всі аспекти доступності можна перевірити автоматично.

У процесі автоматизації тестування доступності часто виникає питання: як обробляти вже відомі проблеми, які не можна виправити негайно? Playwright разом з Axe надає кілька ефективних методів для розв'язання цієї проблеми.

Виключення елементів з тестування

Якщо ваш вебдодаток містить елементи з відомими проблемами, метод exclude() дозволяє тимчасово виключити їх із перевірки:

const scanResult = await new AxeBuilder({ page })

  .exclude('#елемент-з-відомою-проблемою')

  .analyze();

expect(scanResult.violations).toEqual([]);

Однак цей підхід має певні обмеження:

• виключає вказаний елемент та всі його дочірні елементи;
• запобігає виконанню всіх правил перевірки для вказаних елементів, а не лише тих, що відповідають відомим проблемам.

Вимкнення окремих правил перевірки

Коли додаток містить численні порушення певного правила, доцільно використовувати метод disableRules():

const scanResult = await new AxeBuilder({ page })

  .disableRules(['duplicate-id'])

  .analyze();

Ідентифікатори правил можна знайти у властивості id порушень, які потрібно виключити.

Використання знімків для відстеження відомих проблем

Для більш детального підходу до відомих проблем можна використовувати «відбитки порушень»:

expect(violationFingerprints(scanResult)).toMatchSnapshot();

// util.js

function violationFingerprints(scanResult) {

  const відбиткиПорушень = scanResult.violations.map(порушення => ({

    правило: порушення.id,

    цілі: порушення.nodes.map(node => node.target),

  }));

  return JSON.stringify(відбиткиПорушень, null, 2);

}

А це приклад того, як виглядають «відбитки порушень»:

[

  {

    правило: "color-contrast",

    цілі: ["#header", ".main-content p"]

  },

  {

    правило: "aria-required-attr",

    цілі: ["button#submit-form"]

  },

  {

    правило: "image-alt",

    цілі: ["img.product-image", "img.logo"]

  }

]

У цьому прикладі:

• кожен об'єкт у масиві представляє окреме порушення доступності;
• поле «правило» вказує на конкретне правило доступності, яке було порушено;
• поле «цілі» містить список селекторів елементів, де виявлено це порушення.

Створення звітів для аналізу

Для зручності аналізу результатів тестування доступності можна додавати результати сканування як вкладення до тесту:

test('приклад з вкладенням', async ({ page }, testInfo) => {

  await page.goto('https://ваш-сайт.com/');

  const scanResult = await new AxeBuilder({ page }).analyze();

  await testInfo.attach('результати-сканування-доступності', {

    body: JSON.stringify(scanResult, null, 2),

    contentType: 'application/json'

  });

  expect(scanResult.violations).toEqual([]);

});

Використання фікстур для спільної конфігурації

Для повторного використання конфігурацій між тестами доцільно створити фікстуру:

const test = baseTest.extend({

  makeAxeBuilder: async ({ page }, use) => {

    const makeAxeBuilder = () => new AxeBuilder({ page })

      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])

      .exclude('#спільний-елемент-з-відомою-проблемою');

    await use(makeAxeBuilder);

  }

});

Таким чином, Playwright з інтеграцією Axe надає потужні інструменти не лише для виявлення проблем доступності, але й для гнучкого керування процесом тестування та ефективної обробки вже наявних проблем.

Отже, тестування доступності з використанням Playwright та Axe надає потужний інструментарій для забезпечення інклюзивності вебдодатків. Безсумнівно, автоматизація цього процесу значно підвищує ефективність роботи інженерів з тестування та якість кінцевого продукту.

Варто пам'ятати, що автоматизовані тести виявляють лише близько 30% проблем доступності. Відповідно, для всебічної оцінки необхідно поєднувати автоматизоване тестування з ручними перевірками.

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

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