アクセシビリティチェッカーA11ycのChrome拡張機能をローカルで作成してみた話

たぶんそれなりに信頼できる以上に、かなりの勢いで改良が進行していると筆者の中で最近話題のアクセシビリティチェッカー、A11yc アクセシビリティ バリデーション サービス(以下A11yc)というものがあります。

このサービスはWCAG 2.0の早見表で多分知っている人は知っているだろう、時代工房さんによって運営されています。最初に公開したときの背景説明とかはアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent Calendar 2016)あたりに多分あります(ところでa11ycとA11ycって何が違うんですかねえ…?)。まあ、ブラウザーだけで動くアクセシビリティチェッカーなので、どんなものなのかは実際に使ってみた方が早いかと。

さて、そのA11ycのChrome拡張機能ってことですが、普通にこのサービスを使うとなると、A11ycのページに飛んで、URLをペーストして送信して…というステップを踏む必要があるわけですが…ぶっちゃけ面倒くさいとなるわけです。そこで、拡張機能を作って、コンテキストメニューからA11ycでチェックさせればお手軽でしょう?と。まあ、片っ端からページをチェックしたいという人間がどれだけいるんだって話もありますけども。


以下は、Chrome拡張機能の手習いみたいなものです。というか、新規性とか全くもって皆無なので。

基本的なやり方は、Chrome の拡張機能を作ってみる : あかぎメモにある方法をほぼそのまま借りてきただけ。

manifest.json

上記ブログエントリーと、Manifest File Format - Google Chromeにある公式の説明が異なっているので、公式で必須とされているものを付け足して、次のような感じにしました。

{
    "manifest_version": 2,
    "name": "a11ycでチェック",
    "version": "0.01",

    "description": "表示中のページをA11yc アクセシビリティ バリデーション サービスでチェックします。",
    "permissions": ["contextMenus", "tabs", "http://*/*", "https://*/*"],

    "background": {
        "scripts": ["background.js"]
    }
}

まあ、こんな感じで。

background.js

background.jsは、単にURLを渡せばいいだけなので、上記ブログエントリーとい比較して思いっきりシンプルになっています。

chrome.contextMenus.create({
    title: "このページをa11ycでチェック",
    onclick: function(info, tab) {
        let url = info.pageUrl;
        chrome.tabs.create({
            url: "https://a11yc.com/validator/index.php?url=" + url
        });
    }
});

実質何も書いていないに等しいですね、はい。

Vivaldiに食わせる

この2つを作ればあとは、上記ブログエントリーに従って、Chromeと同じようにVivaldiの[ツール]→[拡張機能]から右上にある[デベロッパーモード]をオンにして、[パッケージ化されていない拡張機能を読み込む]から上記で作成した2つのファイルのあるディレクトリーを選択して、Vivaldiに食わせます。これで拡張が動くようになります。これで任意のブラウズしているURLを片っ端からチェックできるようになる、って寸法です。めでたしめでたし。

A11ycへのフィードバック方法

使い方 - A11yc アクセシビリティ バリデーション サービスにあるように、メールアドレス、TwitterGitHubとお好きな方法でじゃんじゃんフィードバックするとよいでしょう。ちなみに筆者は3つ全部の方法で送ってますが、まあ楽な方法でするのが楽ですね(何)。

まあ個人的には、いろいろ改善されていくうちに、いつの間にかmiCheckerを超えていたとか、今は歴史的なAnother HTML-lintの解説でそれなりにHTMLが勉強できたみたいに、アクセシビリティに関するあれやこれやがいつの間にか身につくようになっていた、みたいなウェブサービスになってると面白いかなーと思うので、筆者は気が向くときにフィードバックをしています。このブログの読者で何かの拍子に使ってみて、もし気づいたことがあれば、気軽にフィードバックをしてみてはいかがでしょうか(中の人はフットワークが軽いので結構フレンドリーに対応してくれると思います)。

WAICサイトのWCAG 2.0関連文書が更新と、WCAG 2.1訳の話題

ということで、WAIC WG4のみなさまお疲れ様でした。また、各種コメントをくださった方々にもこの場を借りてお礼申し上げます。

さて、過去のWAICサイト上での更新を振り返ってみますと、

どのWCAG 2.0関連文書も今年に入ってから初めての更新、達成方法集に至っては1年3ヶ月ぶりの更新と日を置いた格好になりましたが、これまでにWCAGもくもく会CA11yを通じて内外からいただいたコメントや、とりわけ当ブログで呼びかけたレビュー期間中にいただいたものについて、比較的容易に反映できる分についてはWG4で反映させました。作業量の多そうなものはまだ反映できていませんが、これについては次の更新までの課題という位置づけです。レビュー期間中のコメント以外のissueの積み上げもそれなりにあって、これらについては引き続き取り組んでいきたいと思っています。


ところでタイトルにもあげたWCAG 2.1の翻訳についてですが、GitHub上では外から見るとゆっくりに見えるでしょうが着実に前進していて、

では勧告候補の翻訳作業が収束しつつあります。お盆が明ける頃にはいよいよWCAG 2.1勧告の作業に取り組めるようになっているのではないか、と勝手な皮算用を筆者はしております。年内に形になってると嬉しいですね……!(筆者の妄想です)

WCAG 2.1の関連文書については、W3C側の作業方針があまり理解できていません…なぜかw3c/wcag21がread onlyになっていて、w3c/wcagで作業が進行しているのはまあさておき、既存のXSLTに取って代わるドキュメント生成システムが見つけられず、手書きで直接作業しているように見えるのは……それはそれとして、AGWGの議事録を流し読みした程度では、WCAG 2.1 Understanding/Techniquesがいつ発行されるのかまるで読めずにおります。一応Editor's Draftは

ということになると思いますが…Understandingはそれなりにできあがってきているように見えるもののまだツメの作業が残っていそう、Techniquesは目次からのリンクがそもそもない状況と、いずれもFPWD発行にはまだまだ時間がかかりそうではあります。