axe-core を用いて web a11y test に触れる - エムスリーテックブログ

【QAチームブログリレー8日目】エンジニアリンググループ QA の窪田です。最近は AWS 資格を取ることにハマっています。資格勉強は結果が目に見えやすいので、モチベーションが維持しやすいですね。今回は web accessibility (a11y) test とそのツールである axe-core について調べてみました。

はじめに
- web a11y test とは
axe-core について
- axe-core を使ってみる
まとめ
We're hiring!

はじめに

最近のテストツールの中には、web a11y test に対応したものが増えてきました。アクセシビリティテストなどの名前で提供されている場合が多いです。このアクセシビリティテストとは一体どういったものなのでしょうか。見やすさ？使いやすさ？何を基準としたテストかご存知でしょうか。

web a11y test とは、web アプリケーションのアクセシビリティをテストするためのツールです。アクセシビリティとは高齢者や障害の有無などにかかわらずすべての人が、支障なく利用できることあるいはその度合いのことです。例えば、視覚障害者の方が、スクリーンリーダーなどを使って、web アプリケーションを操作できるようにすることがアクセシビリティを高める行為の1つです。

web a11y については World Wide Web Consortium (W3C) が定めた Web Content Accessibility Guidelines (WCAG) というガイドラインがあります。現在は WCAG 2.1 (日本語訳) が最新です(2.2 がもう少しで出てくる予定)。

WCAG 2.1 は、以下の 4 つの原則に基づいています。

知覚可能 (Perceivable)
操作可能 (Operable)
理解可能 (Understandable)
堅牢 (Robust)

これらそれぞれについて様々な確認項目があり、３つのレベル (A, AA, AAA) が定められています。レベル A（適合の最低レベル）には、以下のような確認項目があります。

知覚可能
- 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている
- 色が、情報を伝える、動作を示す、反応を促す、または視覚的な要素を判別するための唯一の視覚的手段になっていない。等
操作可能
- コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能
理解可能
- 入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される等
堅牢
- マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どの ID も一意的

これを見ると、Web開発において、当たり前になっている項目も多いです

もちろん、全ての項目を満たすことは難しいです。例えば、音声コンテンツに手話通訳をつけるなどの項目は全てのWebサービスにおいて提供されているわけではありません。

axe-core について

WCAG にどの程度従っているかを確認するには、ガイドラインに沿ったチェックリストなどを用意し目視確認を丁寧に実行することもできますが、手間がかかります。そこで、自動でチェックしてくれるツールがあると便利です。そのようなツールの1つが axe-core¹ です。axe-core を用いると WCAG で規定された項目の 57% について自動的に確認してくれます。

github.com

axe-core を使ってみる

axe-core は、Selenium、Puppeteer、Playwright、jestなど、様々なツールと組み合わせて利用できます。今回は、Puppeteer と組み合わせて利用してみます。

axe-core 内に example が色々あるのですが、@axe-core/puppeteer の実装例がわかりやすかったので、これを参考にしてみました。

また、レポートが見やすいように、axe-reports を利用します。

インストールは以下のようにします（Node.jsが入っている前提です）。

npm install puppeteer
npm install @axe-core/puppeteer
npm install axe-reports

検証対象となるページが、WCAG 2.1 の各種レベルに準拠しているかを確認する場合は以下のように記述します。

const { AxePuppeteer } = require('@axe-core/puppeteer');
const puppeteer = require('puppeteer');

const AxeReports = require('axe-reports');

(async () => {
  AxeReports.createCsvReportHeaderRow();
  const browser = await puppeteer.launch();

  const page = await browser.newPage();
  await page.setBypassCSP(true);

  await page.goto("https://example.com")
  const results = await new AxePuppeteer(page).withTags(['wcag2a','wcag2aa','wcag2aaa','wcag21a','wcag21aa','wcag21aaa']).analyze();

  AxeReports.createCsvReportRow(results);

  await page.close();
  await browser.close();
})();

設定など色々と長いですが、下記のように AxePuppeteer に対して、利用したいタグ（ルールの集合）を設定することにより、検証したいルールを決定できます。

この部分、ちょっと分かりにくかったのですが、WCAG 2.0 Level A Rules（wcag2a: 56個のルール）と WCAG 2.1 Level A Rules（wcag21a: 1個のルール）は別物なので、設定しないと見てくれません。（最初 wcag2a と wcag21a は、WCAG2.0 A レベルと WCAG2.1 Aレベルと対応しており、共通部分は双方に含まれると勝手に思っていたのでうまく結果が出ませんでした）

この部分で、.disableRules() を追加することにより、検証したくないルールを省くことができます。

  const results = await new AxePuppeteer(page).withTags(['wcag2a','wcag2aa','wcag2aaa','wcag21aa','wcag21aaa']).analyze();

上記コードを適当な場所に配置し、以下コマンドを実行します。

node axe-example.js　=> report.csv

すると指定したルールに基づき実行され、レポートは以下のように出力されます。省略していますが、Help 列に各ルールの詳細に付いてのリンクが出力されているので、どのような対処をすれば良いかもわかりやすいです。

URL,Volation Type,Impact,Help,HTML Element,Messages,DOM Element
https://example.com,color-contrast-enhanced,serious,省略,<span>例の文章</span>,Element has insufficient color contrast of 4.99 (foreground color: #65717b- background color: #ffffff- font size: 10.8pt (14.4px)- font weight: normal). Expected contrast ratio of 7:1,.Paragraph_sidenote__MnaJg > span

この例では、文字のコントラストが十分でないため読みづらい可能性があるという指摘です。このような指摘が CSV 形式で大量に出力されます。これらを一つ一つ対処していくことでどのような人でもアクセスしやすいウェブページを作ることができます。

検証するページが1ページであればレポート書き出しまで数秒程度で実行が終わるので、そこまで実行時間がかかる印象はありませんでした。実装もそこまで難しいものではないため導入ハードルは低かった印象です。

まとめ

今回は axe-core を試してみました。実装が比較的容易で、実行時間が短く、レポートまで出力してくれるので良いツールだなと思いました。気軽にアクセシビリティの確認ができるのは良いですね。まだ実施していませんが、独自ルールなどを追加して社内のデザインガイドなどを確認できるようにできるかなとも思ったので、今後試してみたいなと思います。