Web アクセシビリティ向け Node.js 製の自動チェックツールや DevTools 用の拡張機能など
Posted: Updated:
アクセシビリティを担保するプロセス作り
この記事は Web Accessibility Advent Calendar 2016 - Adventar の 12 日目の記事です。
UI 実装の再考と a11y - Frontrend Vol.8 LT でも述べましたが、Accessibility is a Process, Not a Project ということでアクセシビリティ対応するプロジェクトではなく、アクセシビリティを担保するプロセスを作りましょうということで、チェックツールをいくつか並べて俯瞰してみます。対象読者は自分と同じようなクライアントサイドの Web アプリケーション屋さんということにしておきます。
ちなみにアクセシビリティ評価ツールについては 3 日目のアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent Calendar 2016) - 有限会社時代工房でも言及されています。CI でライトに実行するのは難しそうですが試してみたい所。レポーターの出力さえ何とかなれば、Docker イメージにして使えるかも？
過去のアクセシビリティ関連の Advent Calendar で既出のネタかもしれませんが平にご容赦を mm
自動チェックツールのポジション
昨今の Web アプリ開発においては、継続的インテグレーション ( CI = Continuous Integration ) が行われていることが多いはずですが、その中にチェックツールを組み込んでおくのは有効な手段です。
標準的な開発プロセスを想定すると、次のような手順で開発、テスト、レビューが行われるのをよく見るはずです。Web アクセシビリティに取り組む際もこの手順に落とし込めます。
- 開発作業を行う
- Pull Request を出して CI でテストや Lint を実行する
- CI を異常なくパスした Pull Request をレビューする
「機械的にテストしたのちに人間がレビューをする」という手順にさえ落とし込めれば、普段の開発プロセスに溶け込んで Web アクセシビリティに取り組めます。ということで自動チェックツールを見ていきましょう。
Node.js で実行できる自動チェックツール
Web アクセシビリティにおいて自動チェックというのは、突き詰めれば HTML の評価です。マシンリーダビリティ的な観点（時には機械的にチェック可能な範囲でヒューマンリーダビリティも含まれるでしょう）で、HTML に込められた情報に過不足がないかをテストしてレポートします。
Web アプリケーションで完全に静的な HTML を管理していることは稀です。十中八九、サーバーサイドテンプレートかクライアントサイドテンプレートか、その両方かを管理して、Web アプリが実行された結果として HTML が動的に生成されます。
となると、特定のファイルに向けてチェックを実行するよりも Web アプリを立ち上げて、Web ブラウザのレンダリングエンジンで実際に実行してしまうのが一番手っ取り早いということで、PhantomJS をはじめとしたヘッドレスブラウザが好んで使われています。
a11y - Accessibility Audits For The Web
Google の Addy Osmani 氏の公開している a11y は（名前まんまですね）、GoogleChrome/accessibility-developer-tools に含まれる axs_testings.js を PhantomJS で実行したページに inject してテストした結果を、標準出力としてレポートします。
a11y https://havelog.ayumusato.com > report.txt
適用されるルールは accessibility-developer-tools/src/audits at master · GoogleChrome/accessibility-developer-tools に準拠し、Accessibility Developer Tools 導入時の Audits パネルを実行したときと同一と考えられます。 私見ですが比較的準拠しやすいルールセットが揃っている印象な反面、特定のルールだけ多めにみる（PASSさせる）というオプションもないので、途中から導入するのは辛いかもしれない。
Pa11y is your automated accessibility testing pal
pa11y は HTML_CodeSniffer を PhantomJS で実行したページに inject してテストした結果をレポートします。こちらは標準出力ほか CSV、JSON、HTML など各種形式をサポートしています。
pa11y --reporter json https://havelog.ayumusato.com > report.json
適用されるルールは WCAG 2.0 Standard: Summary と U.S. "Section 508" Guidelines: Summary に準拠し前述の a11y とは違ったチェックを行います。Section 508 というのはアメリカ合衆国のリハビリテーション法第508条のようです。
オプションが豊富で融通が融通が利きそうなのと、pa11y/dashboard: Pa11y Dashboard is a web interface which helps you monitor the accessibility of your websites というメトリクスの可視化を目的としたダッシュボードの開発も進んでいたりと、なかなか期待させてくれる活発さです。
ダッシュボードはパフォーマンス分野でいえば、SpeedCurve みたいなものでしょうか。そうだといいなぁ。
evcohen/eslint-plugin-jsx-a11y: Static AST checker for a11y rules on JSX elements.
開発中にざっくりとチェックをかけるなら、Lint ツールくらい軽量なほうが良いわけですが、JSX 向けの ESLint 用 Plugin があります。PhantomJS はブラウザそのものを立ち上げて色々やる都合どうしても動作が鈍重なので、 ESLint で WebStorm や Visual Studio Code などと連携してリアルタイムチェックも可能なのはありがたいです。
豊富なルールセットが用意されており、もちろん ESLint なので、コマンドラインで実行してもエラーがあればキチンと CI を落とせます。airbnb/javascript: JavaScript Style Guide にも javascript/react-a11y.js として設定があるので参考にできるでしょう。
eslint-config-airbnb として気付かずに使ってきた人もいるかもしれない。
Tenon.io can identify 508 and WCAG 2.0 issues in any environment
Node.js かどうか不明だし、正確にはコマンドラインツールですらありませんが、API として叩けるので CI に組み込むことも容易そうです。ただし有料で、ルールセットについても精査していないです。Web ページから URL などを指定して、直接手動でチェックすることは可能なので、どんなレポートを出力するかは実際に試してみると良さそうです。
Developer Tools との機能統合
Chrome Extension としてインストールして、Developer Tools に機能が追加されるアクセシビリティ関連の開発者向け拡張機能もあります。CI に組み込める自動チェックツールとは性質が異なるので、このあたりの詳しい紹介は割愛します。
- Accessibility Developer Tools - Chrome Web Store
- aXe - Chrome Web Store
- ChromeLens - Chrome Web Store
Accessibility Developer Tools はとりあえず入れておくと、Element パネルで要素を選択時に、Accessibility Properties でアクセシビリティに関するヒントが得られるのでオススメです。
その他、問題の可視化など
その他、と言い始めるとまだまだ色々あると思いますがとりあえず2点だけ。
- Tota11y Plugin, from Khan Academy - Chrome Web Store
- reactjs/react-a11y: Identifies accessibility issues in your React.js elements
Tota11y は表示中の Web ページのアクセシビリティ関連の issue などを可視化してくれます。ブックマークレットもありますが、Chrome 使いならとりあえず Extension で入れておけば良さそうです。
react-a11y は <a> や <img>、<button> などのフォーム系要素に対して基本的な属性（React 的にはむしろ prop）を動的にチェックして、console にメッセージを表示してくれます。他のチェックツールとかぶりそうなのと、わざわざ console に出す必要は薄そうですが React 全盛時代なので一応紹介。
自動チェックツールの穴とヒューマンリーダブル
チェックリストで評価できることの多くは、あくまで HTML の出来映えに関する評価です。人間にとって認知しやすいラベリングかどうか、ページをまたいで一貫性のあるナビゲーション設計になっているか、コンテンツが平易に理解できる情報構造なっているか... などはこれらのツールでは検知できません。
誰もが必ずしもアクセシビリティの専門家ではないかもしれませんが、チェックツールで最低限の部分をおさえつつ、普段のコードレビューなどでも油断せず更なる品質の向上に努めていきたいところです。
超高級品とかになると、ヒューマンリーダブル方面にも踏み込めるくらい賢いのかもしれませんが...どうなんでしょう？
以上で Web アクセシビリティと呼ばれているものと Web アプリ開発現場に思いを寄せて でうっかりネタを使ってしまった後に慌てて用意した記事を終えます。メリークリスマス。
