コラム15:アクセシビリティ対応…ツールが全然機能しないやんけ…

こんにちは。です。明けましておめでとうございます。本年もどうぞよろしくお願いいたします。

( ^ω^)うぃー

今年もみんな、ゆるくやっていきましょー

( ^ω^)うほーい

ちなみに管理人は2月3日が誕生日です。覚えておくように。

( ^ω^)

( ^ω^)

( ^ω^ )

( ^ω^)ぅす

さて本日は、、、がアクセシビリティの仕事を通して得た情報を皆さんに共有したいと思います!

先に結論を書くとこんな感じです。

結論
アクセシビリティ対応ってツール使ってもあまり意味ないよね

( ^ω^)・・・・!?

ほな解説するで⊂二二二( ^ω^)二⊃

※いや!そんなの常識やんけ!っていう人は退屈だと思います( ^ω^ )すまんな

目次

つまりどういうことだってばよ?!

アクセシビリティの対応をするとき、ページの問題箇所を洗い出してくれる以下のようなツールの使用が推奨されるのですが

例えば、ページのソースチェックだと
Lighthouse
miChecker
A11yc

とくにLighthouseやmiCheckerがよく推奨されますよね。されるのよ。知らない人ごめんなさい。

Lighthouseは問題箇所を洗い出した上でそのページの品質をスコアで表示してくれる。miCheckerは問題の内容と程度に応じて重要度に分けて問題箇所を洗い出してくれるツールです。

( ^ω^)便利やんけ

そう!めっちゃ便利!便利なのですが……

ツール使ってみると…うーん?

実際にツールを使ってみたので、その効果を見てほしいです。例えば、

2018年3月20日にアクセシビリティの試験を実施、その結果、適合レベルAAを達成した日立の製品・サービスページを先ほど紹介した各ツールで検証してみたところ。以下の結果になりました。(2023年1月12日時点)

検証結果
・Lighthouse=82点。エラー2箇所。結果のキャプチャ
・miChecker=問題あり6箇所。結果のキャプチャ
・A11yc=問題箇所Aが2個。AAが1個。結果のキャプチャ

( ^ω^)な…んだと?

これ誤解してほしくはないのですが、日立さんのページは素晴らしくて、さすがの品質なのですよ。

で、皆さんに意識して見てほしいのは各ツールで検証結果がバラバラだという点です。この記事で解説したい部分はここです。これが非常にやっかい。ツールに欠陥があるんです。というか限界があるんです。

ツールによって検証結果はバラバラ、そして明らかな問題も見落とす

アクセシビリティ対応を行う上で様々なツールが存在します。しかし、どのツールも(管理人が知る範囲で)機能面で限界がありました。僕が感じた限界は

感じた限界
・ツールによって検証結果がバラバラなので併用することが推奨されますが、併用しすぎると対応が煩雑になる。
・肉眼で明らかに問題だとわかるレベルでもツールによっては問題として引っかからないことが多々ある。

( ^ω^)なるほど

これ結構カオスなのですが試験の精度を上げるためにツールを併用してしまうと、かえって精度と品質落とす可能性があるんです(‘ω’)アワワワ

※これがカオスです。Aというツールで問題にならなかった。しかし、併用しているBというツールでは問題扱いだった。その問題箇所を直した。Bの問題は無くなったがその対応でソースをいじったためAのツールで再度試験を実施したところ新たな問題が出てきた。

しかし、ツールの限界は仕方ないのよね

ただ、ツールで検証できる範囲には限界があるのよね。だから仕方ないと言えば仕方ないんですよ。

( ^ω^)ほう?

例えば、アクセシビリティ対応には1.1.1 非テキストコンテンツの達成基準という達成しないといけない項目があるんですが、簡単に言うと「読み上げツールを使用したときに全盲の方もコンテンツが理解できるように画像にはaltを設定しましょう」という取り組みなのですが、この「理解できるように」って抽象的ですよね。

( ^ω^)たしかに

さらに、矛盾したように感じるかもしれないのですが、必ずしもaltを設定すること自体は推奨していないんですよ。

( ^ω^)ふぁ?

あくまで「読み上げた際への配慮」なので、へたに設定しまくってしまうと文脈がぐちゃぐちゃになってしまうのでアイコンとか装飾を目的とした画像には設定しないのが一般的な方法だったりします。その場合はalt=””という感じ。

でもツールってそういう配慮に対する判断って出来ないので、配慮してあえてaltを空っぽにしているのに、ツールで検証した結果エラー扱いになったりするんですよね。←ココ大事

何を信じればええんや工藤。試験方法教えろや

個人的に推奨する方法は

まずはmiCheckerでブラウザチェック、問題箇所を洗い出す。

次にカラーコントラストアナライザーで画像など文字を置いている色のコントラスト比をチェック、スクリーンリーダーのNVDAを使用し問題箇所を整理して対応。

(ここでもしもクライアントが対応方針書みたいなドキュメントがあれば用意していたら最初にそれも踏まえて試験する)※対応方法はデジタル庁のウェブアクセシビリティ導入ガイドブックを参考にする。

対応を終えたら再度各検証ツールで試験を実施。もちろん必ず目視によるチェックも行う。とくに自動で動く(再生)されるコンテンツ(カルーセルや動画など)には必ず再生停止ボタンが必要になるがツールはドジっ子なのでよく見落とす

と、手間かかるのですがこのくらいやったら最低限の品質が担保できるんじゃないかなと信じています。

企業によっては最初から視覚や聴覚に障害がある方に試験を手伝ってもらっているところもあるので、そういう方法が取れるのならそれがベストだと思います。

最後に

どうでしたか?ちょっと小難しい話で面白くはなかったですかね。許せサスケ。

デジタル庁のウェブアクセシビリティ導入ガイドブックでもツールで機械的に確認できるのは達成基準の2割から3割程度って記載しているので、その通りなんだと思います。(2023年1月12日時点の記述)

アクセシビリティってそもそも何やねんって人がおりましたらコチラをお読みください(`・ω・´)b

あわせて読みたい
コラム4:ウェブアクセシビリティって知ってる? こんには僕です。最近「Webディレクター」という肩書でTwitterやっている人の中で1番フォロワー数が多い人が誰なのか調べてみたところ、どうやらひろゆきさんの奥様だっ...

また、皆さん2023年も一緒に楽しく勉強したり、成長していきましょう。

少なくともこの記事を読んでくれただけでレベルが1アップしたと思うので明日から会社で「1アップした」って真顔で自慢してみてください。ほなまた。

3カラム専門のデザイン集作ったのでちょっと立ち寄ってみて

  • URLをコピーしました!

コラムを書いた野郎

のんびりWeb業界の人たちと仲良く勉強したり仕事したりしてます。

目次