伊原： 齋木さんや村上さんはどうしてます？
齋木： VoiceOver は、クライアントさんにチェックしてもらっているのと同じくらいのタイミングで、確認したりはします。でもそのくらいかな。
村上： 私も VoiceOver でどういう風に聞こえるかをチェックする感じですね。でも私はコーディングとかはしないので、コンテンツの中のチェックとかですかね。見出しがついてるかとか、alt がついてるかとかを見ていくという感じですかね。それを検証というのかはわからないですけど。
伊原： VoiceOver というのは iOS の VoiceOver ですか？
齋木： そうですね。
西川： 僕はタブで操作できるかを気にしてますね。それが1番簡単にできるんですよ。自分も使うし。 でも、検証環境はないですね。作ってないかな。僕も今は制作をしているわけではないんですが、確認するために何かやらないといけないと思っているんですけど、これを通しておけば大丈夫みたいな検証環境は作っていないので、何かリストみたいなのがあったらやりたいです。
伊原： これもちゃんと回答すると長くなりそうです。試験をするという仕事があるくらいなので。 アクセシブルになっているかの検証は、どの観点でアクセシブルになっているかという話があるんですね。つまり、スクリーンリーダーもあると思うんですけど、キーボード操作もあるだろうし、見た目のデザイン、ビジュアルデザインとしてのアクセシビリティもあります。色のコントラストや、レイアウトもそうですよね。アクセシビリティガイドラインにはリフローとかも入っているので、それはスマホで確認しましょうとか、そういうのもあるわけです。
アクセシビリティ=スクリーンリーダー のイメージが強いと思うんですけど、それはモダリティと言うんですが、視覚とか聴覚とか、あるいは操作方法とか、いろんな方向からのチェックがそれぞれあります。 コントラストはコントラストチェックツールがありますし、そういうものでチェックしましょうということになると思います。
キーボード操作については西川さんがおっしゃってたように、まずは実際にtab キーで全部操作できる対象になっているかとか、フォーカスリングがちゃんと出るかとか、あとは実際にEnter キーや space キーで操作できるか、あとは入力欄に入力できるかとかそういうチェックがあると思います。
なので、スクリーンリーダーでないチェックもたくさんあります。
また、もちろんスクリーンリーダーのチェックもするんですが、それ以前に機械チェックできる部分も2割くらいあります。 一番わかりやすいのが、Google Chrome の DevTools に Audits タブというのがあり、アクセシビリティという項目があるんですね。それでアクセシビリティの自動チェックができます。もともと Lighthouse というパフォーマンスとかその辺も含めてウェブサイトを自動チェックしてくれるツールがあって、それがDevToolsに組み込まれたものなんです。Chromeはみんなもっていると思うので、機械チェックとしてはそれが割と簡単にできるかなと思います。Audits の概略を話している、知り合いのサイバーエージェントのあほむさん(@ahomu)という方のスライドがありますのでリンクを貼ります。
Webフロントエンドで大切なことは全てAuditsが教えてくれた
伊原： 機械チェックツールって個別に入れないといけないというイメージもあると思うんですけど、実は Chrome に入っています。
これを使うと、何点みたいなのが出て、この辺のマークアップ直したほうがいいですよとか、また CSS での background-color と color のコントラストを測って、ここのコントラスト低いですよというのを教えてくれたりする感じです。これらを直した上で、スクリーンリーダーでチェックするというのがいいかと思います。
スクリーンリーダーは代表的なのは iOS の VoiceOver だと思いますし、これはシェアも結構大きいのでわかりやすいしいいんじゃないかと思います。iOS VoiceOver は手元ですぐにできるというのがありますし、ウェブ制作者がチェックに使おうという記事を書いている方がいらっしゃいますので紹介します。
ウェブ制作者のための「はじめてのiOS VoiceOver」チュートリアル（初級編） | Rriver
伊原： あとはフロントエンドエンジニアやデザイナーの方は Mac ユーザーの方も多いと思います。Mac の VoiceOver はちゃんと使おうとするとけっこう大変なんですけど、その簡単な使い方、該当のものを読み上げる程度であれば割とすぐにできるというのを僕の同僚(@ymrl)が記事を書いていたりするので、これも紹介します。
macOS の VoiceOver で Web サイトのスクリーンリーダー対応をはじめよう - Qiita
伊原： それ以外だと、Windows10以降ではナレーターという標準で付属しているスクリーンリーダーがあったりとか、AndroidでもTalkBackというスクリーンリーダーが標準で入っています。少なくとも、iOS, Mac, Windows, Android 全部標準付属のスクリーンリーダーがあるので、それで読み上げてみるのがいいと思います。
ガイドラインに沿っているかというのももちろんあるんですけど、普通に読み上げていって、ちゃんと意味が通じるかというのが最重要だと思うんです。それがスクリーンリーダーで要素を順に読み上げていくとわかるんです。例えば画像があるけど alt がなくて、それが伝わらないとボタンが押せないということは、読み上げればだいたいわかるんですよね。
まず耳だけから聞こえる情報でそのページの情報の内容が把握できて、リンク先に行ったりとかボタンを押したりできるかどうかを確認するというのが重要だと思っていて、それをガイドライン的にどう満たしているのかというのはその次のところかなと思います。というのも、実際のところそれで使えるかっていうのが重要なので、アクセシビリティの試験をやる場合はこれは項目をどう満たしているとか、これは満たせていないとか判定するかという話になってくるんですが、それ以前に普通に使えるページになっているかどうかというのが重要なので、その要素が読み上げられるかどうかとか、リンクが機能しているかどうか、というのが確かめられればいいかなという感じです。
ガイドラインに沿っているということを試験するという業務であれば、もちろんガイドラインの意味を正確に理解して、それに沿ってちゃんとチェックしないといけないと思うんですよね。ただ、いきなりそれをやるというよりは、実際にユーザーがちゃんと使えるかどうかっている方が重要なんですよ。 アクセシビリティのガイドラインのレベルAは最低限と言っているんですが、これは実は満たすのが大変なんです。かなり大変と言っていいと思います。例えば動画に字幕がなかったらレベルA取れないので。
僕らのfreee社でも、あれをレベルAにいきなりもっていくというのはしていなくて、まずは前回笑いを誘った「虚空」と呼ばれている、span要素にして、テキストノードがなくて、なぜかボタンだし、アイコンフォントが出てるみたいなやつです。そういうのってスクリーンリーダーからは存在もわからないし、押すこともできないわけですよ。そういうものはやめようとか、キーボードでは押せないけどマウスだけで押せるものはやめようとか、そういうところからです。
やっぱり情報が全く存在していないように見える状態が1番避けないといけないことなんです。
例えばスクリーンリーダーだとテキストノードがない、spanなのに実はリンクだったりボタンだったりするものが、恐らく1番まずいです。
視覚的なものでいうと文字が薄過ぎるようなものは、たとえ反転したとしてもコントラストは上がらないんですよね。薄いものは薄いままなので。それでは「そこにものがある」ということ自体に気づけなくなっちゃうので避けないといけないですよね。
あとはキーボードのフォーカスリングが出ないというもの。あれはどこかにフォーカスが当たっているんだろうけど、全くわからなくなってしまうので、ほぼ詰むと思うんです。
だからそういう存在を知覚できないというのが恐らく1番避けなければいけなくて、まずそれを回避するようにチェックするのが重要かなと思います。
村上： ありがとうございます。わかりました。
WindowsではNDVAというスクリーンリーダーも無償で試せます