JIS X 8341-3の適合試験を試みたものの上手くいかなかった話、それをふまえた今後の取り組みの話です。Webアクセシビリティ界隈のみなさまには「そりゃそうだ」と思われるような内容だと思いますが、書き残しておきたいと思います。
JIS X 8341-3の適合試験に取り組む
先週7日、当社Webサイトをリニューアルいたしました。その一環でJIS X 8341-3:2016の適合試験をやるようにとの業務指示がありました。ビジネス上の理由と私が以前からアクセシビリティに取り組んでいるから、というのが背景でしょう。時間は十分にありましたが、手を付けてみると色々な気付きがありました。
実装チェックリストの作成に難しさを感じる
JIS X 8341-3:2016の規格書にある附属書JB 試験方法やウェブアクセシビリティ基盤委員会（以降WAICと表記）主催のセミナー「これから取り組むWebアクセシビリティ 2018 夏」の「こうすればできる！ウェブアクセシビリティ実装のポイントと実装チェックリストの作り方 」を参照し、達成方法及びその検証方法を特定できるように「実装チェックリスト」を作ることにしました。しかし作り始めてみるとこれがなかなか難しい。WAICのサイトにある「実装チェックリストの例 2012年11月版」・WCAG 2.0解説書・WCAG 2.0達成方法集をじっくり読んでいけば理解はできるのですが、ゼロから実装チェックリストが作成できるかと問われると正直なところ私には難しそうと感じました。例えば、「G182: 文字色の違いが情報を伝えるために使用される場合に、利用可能な追加の視覚的な手がかりを確保する」というのを「テキストの色の違いで情報を伝える際は、視覚的な手がかりを補足する」というシンプルな言葉でチェックリストに落とし込めただろうか？と。
今よりさらにWCAG 2.0の理解を深めれば自然と作成できるようになるのかもしれませんが、新しい実装チェックリストの例があれば参考にさせてもらいたいと感じました。（A11YJのSlackで持田さんに教えて頂いたのですが、miCheckerに同梱されているなどもするようで）
アクセシビリティサポーテッドなのかという問い
近年利用されることが多い「Webフォント」がリニューアル後のページで使われていました。そこで達成基準 1.1.1の達成方法及び失敗例を確認し、「ARIA6: オブジェクトのラベルを提供するために aria-label を使用する」を使用して達成基準を満たすことができるかと考えるのですが、果たしてこれがあらゆる環境でサポートされているのか？と疑問が湧きました。もちろん検証すれば良いだけの話なのですが、無料のNVDAはインストールしていても日本で利用者が多いとされるPC-Talkerは所有していないので検証することができません。ここで再び手が止まってしまいました。
PC-Talkerを買おうにも高価ですしスクリーンリーダー以外にも多様な環境があると思うので、実機を揃えるのは現実的でないかも。今までにもよく言われてきたように「アクセシビリティ・サポーテッド（AS）情報」や「Can I Use…のアクセシビリティ版」のさらなる充実が望まれるところでしょうか。
解説書の言葉がわからない
達成基準 3.2.1「いずれのコンポーネントも、フォーカスを受け取ったときにコンテキストの変化を引き起こさない。」のところで、「コンテキストとは何か？」という疑問を持ちました。あれこれ検索するなどしたのですが、よく見ると「コンテキスト」のところにページ内リンクがあり、しっかりと解説がなされていました。じっくりWCAG 2.0を読み、一つひとつしっかりと理解しなければならないなと痛感した出来事でした。試験の実務に関する勉強会やトレーニングもあればいいなとも感じました。
やりたいこと・やってほしいこと・やってほしくないこと
近年ページ上の要素をアニメーションさせている例はとても多いと思います。今回のリニューアル後のページにも実装されていました。ここでアニメーションを付けてかっこよくしたいメンバーと、閲覧環境・状況などによっては上手く閲覧できない懸念があってやめてほしいと考える私とのせめぎ合いが始まるのです。他にもリンクの下線はちょっとダサいという意見と、色だけでリンクを示した場合はリンクと識別できないケースがあって下線を付けたい私、とか…。
昔の私なら是が非でも「こうでなければダメ！」と押し切るのでしょうが、それをやってしまっては社内にしこりが残るだけです。どうすべきか長いこと悩んだのですが（この辺僕の悪い癖というか…）、夏に開催された「Japan Accessibility Conference digital information vol.2」での中村精親さん・秋山さんセッション動画「Webアクセシビリティのスキルがビジネスへと繋がる時代 - JAC vol.2」や、私も参加したCSS Nite LP62での木達さんのセッションの動画「【クロージング・トーク】インクルーシブネスを超えて」を視聴し、ここで一旦試験をやめることを決意し今起こっている事実を伝えました。
チェックを補助するツールの作成した
試験にあたり、アクセシビリティの検証をする「axe」や、HTMLの検証をする「Nu Html Checker」をたくさんのページで実行する必要がありました。そこで、「axe-runner（仮称）」を作成したり、site-validator-cliを改造してローカルで実行しているNu Html Checkerを用いた検証ができるようにしたりしました。
また、Puppeteerでスタッフブログの記事や制作実績の本文からimg要素を取得し、代替テキストが現在どのように設定されているのかを一覧出力して俯瞰できるようにもしました。（代替テキストが全然入っていないケースや画像ファイル名が入っているケース等が確認できる）
これらのツールはチェックの負担を軽減できるものであり、今後の取り組みに大いに役立つと考えています。
改めて、まずは小さな取り組みから
今回試験が上手くいかなかった原因を考えると、アクセシビリティを知っている人だけが頑張っても上手くいかない、また早い段階で実装チェックリストを作る事ができなかったために試験をパスできない実装が発生したこと、などが考えられます。早い段階で実装チェックリストを作るというのは、土屋さんの「JIS X8341-3 の実装チェックリストを上流工程から使う」を拝見し、その通りだと感じました。
先に話題に出したCSS Nite LP 62でのクロージング・トークにて木達さんが仰った「小さく産んで大きく育てる」という言葉の通り、情報伝達の保障の重要性を認識するとか、『Webアクセシビリティ 基本の「キ」10項目』をどの案件でも守れるようにするとか、そういったことから始めていきたいなと感じました。そのためには自分が福山のアクセシビリティおじさんとして旗振りをすれば良いのかなと。来年取り組むべき課題ですね。最近では案件でアクセシビリティを求められることもありますし、勉強会や書籍も増えましたし、以前よりは取り組みやすさがあるかなとも感じます。いきなり試験をやってもつらいだけで心が折れました。
XDの使い方、CSS/JavaScript、検索エンジンやブラウザの動向、日々研究することは多々あって大変かと思いますが、少しずつ・無理なく取り組んでいきましょう。