以前、@axe-core/puppeteer を使用して、テキストファイルで作成した URL リストに対して自動的にアクセシビリティテストを実行し、その結果を HTML ファイルとして保存するスクリプト 「axe-auto-reporter」 ってのを作ったんですけども （下記記事参照）、今回、これを Web UI から利用できるツールにしてみたので紹介です。
Burnworks A11y Reporter Web UI
ということで、今回公開したツールは下記です。
「axe-auto-reporter」 は、コマンドラインで、あらかじめ作っておいた URL リスト、つまり複数の URL に対して自動的にアクセシビリティチェック （テスト） を実行して、HTML 形式のレポートを作成するツールでしたけども、今回公開したツールは、アクセシビリティチェックレポートを作りたい URL を 1 件だけ入力して実行する単発のアクセシビリティチェックツールです。
要するに、axe のブラウザ拡張機能である 「axe DevTools」 と同じようなことを、Web UI から実行するってことですね。
「axe DevTools」 を日常的に使っている人や、「axe-auto-reporter」 をはじめ、コマンドラインツールを当たり前に使える人にはあまり関係ないんですけども、そのようなブラウザ拡張やコマンドラインツールをどうしても使えない方が、アクセシビリティチェックをはじめて体験する入門用ツールとしてはいいんじゃないかなと思います。
このツールは、アクセシビリティチェックツールに対して詳しい知識を持たない人でも、簡単にアクセシビリティチェックを体験してみることができます。それによって、自分、あるいは自分の所属する組織などが運営する Web サイトのアクセシビリティ品質ってやつに興味を持ち、アクセシビリティに取り組むきっかけにでもなってくれたらうれしいですね。
なお、ご利用になる場合は 「ご利用に当たっての注意点」 セクションを確認の上でお願いします。ないとは思いますが、アクセス数があまり増えるとサーバリソース的に厳しいことになりそうなのでちょっとだけ心配。
少しだけ技術的な話
今回のツールの、アクセシビリティチェックレポート生成に関する主要なロジックは、前述の 「axe-auto-reporter」 をほぼそのまま流用しています。よって、生成される HTML 形式のレポートも 「axe-auto-reporter」 と全く同じフォーマットになります。
Web UI を作るにあたっては、普段から使い慣れている Astro.js と Tailwind CSS を採用しています。ホスト先は Vercel を利用し、axe-core、および Puppeteer を使用したアクセシビリティチェックとレポート生成機能をカスタムエンドポイントとして実装、フロント側からチェック対象の URL を受け取って、Vercel Functions として実行します。
Vercel Functions は、デフォルトで 1 回あたりの実行時間が決まっています （Pro アカウントだと 15 秒 / 下記参照）。
axe-core、および Puppeteer を使用したアクセシビリティチェックは処理としては結構重いので、DOM サイズがデカい Web サイトをチェックしようとすると、このデフォルト実行時間ではタイムアウトが発生してしまいました。そこで、設定を変更します。
Astro.js の場合は、astro.config.mjs に maxDuration の設定が書けますので、下記のようにして、最大 60 秒まで実行時間を延ばしました。
// @ts-check
import { defineConfig } from 'astro/config';
import tailwindcss from "@tailwindcss/vite";
import vercel from '@astrojs/vercel';
// https://astro.build/config
export default defineConfig({
output: 'server',
adapter: vercel({
maxDuration: 60, // ←ココ（最大実行時間を 60 秒に設定）
}),
vite: {
plugins: [
tailwindcss(),
],
},
});
それでも、馬鹿でかい DOM を持つサイトをチェックしたりするとタイムアウトするケースがありますが、まぁもうそれは諦めてくださいというスタンスで。
レートリミットを実装してみた
基本動作については問題ないのですが、このまま一般に公開すると、大した同時接続数じゃなくてもサーバリソースが足りなくなることが予想できたので、Claude 3.7 Sonnet さんにお手伝いしてもらいながらレートリミット機能を実装してみました。
とりあえず、同一の IP アドレスからのアクセシビリティチェックレポート生成を 90 秒 （この秒数は環境変数で設定） に 1 回の頻度でしか実行できないようする簡単なレートリミットを前提に、データを Vercel が標準で提供するストレージに保存しつつ実装したいんだけど...... 的なご相談をしてみたところ、Vercel KV （Redis） を使うといいよ的なところからアドバイスをいただき、コードもちゃちゃっと作ってくれちゃいました。あぁ優秀すぎて惚れそう。
念のため Vercel KV を調べてみたら、もう提供は終わってて、今だと Upstash などサードパーティ製の Redis が簡単に使えるようになってたのでそっちを使う前提で Claude 3.7 Sonnet さんに相談しながらコードを修正。環境変数でレートリミットの On / Off も付けて、ローカルで npm run dev したときはレートリミットをスキップしてテストができるようにしてみました。
いやぁ AI 様々ですよ。自力で実装してたら多分もっと時間かかってる。あと、AI さんに手伝ってもらうときは、ある程度実装が進んだところで、別チャット立ち上げて、この実装どう思う （意訳）？ って聞くと、「ここはこうした方がええよ」 みたいなアドバイス （そこ、お前がさっき書いたコードだけどな...... とは思いつつ） がくるので、それを検討してよさげなら取り入れるって感じにするとコード品質上がる。
あと、Claude 3.7 Sonnet さんが書いたコードを ChatGPT さん （o3-mini-high など） にコードレビューしてもらうってのもやってみたけど、こっちが気がついてなかった部分を指摘してくれたりするので便利。
課題
Vercel 側のサーバリソースの関係で、前述の通り、DOM サイズが馬鹿デカい Web サイトをチェックしようとすると、ヘッドレス関数の実行時間が足りずにタイムアウトします。通常の Web サイトなら恐らくほとんど大丈夫だと思うんですが、某楽天市場のトップページなんかをチェックしようとすると 60 秒以内には完了しないですね。
一応、Vercel Pro アカウントにおける、maxDuration の最大値は 300 秒なので、設定数値を上げれば何とかなるとはおもんですけども、そこまでサーバリソースを使いたくないので、チェック対象ページがデカくてタイムアウトする場合はもう諦めてください。
ちなみに、Claude 3.7 Sonnet さんに本件について相談してみたところ、「DOM サイズがデカい場合は、処理が重たいチェック項目 （コントラスト比チェックとか） を省略するようにしたらいいんじゃね？」 などという適切なアドバイスをいただきましたが、「ナイスアイデア」 と褒めつつ、今回は見送ることにしました。
