freeeのアクセシビリティの現状
伊原力也氏（以下、伊原）：ちょっと意識が出てきたところで、「今どうなっているのか？」に迫っていきたいと思います。
freeeですが、サイトとアプリがいっぱいあるなかで、有名なのは会計freeeだと思うんですけど、サイトにしても、例えば公式サイトもあるし、ヘルプページもあるし、実はfreeeはコーポレートカードを出していたり、開業応援パックなどもやっています。あと、会社もコーポレートサイト、採用ブログ、開発者ブログ。オウンドメディアも2つあります。
アプリケーションも、実はバックオフィス全部ということになると、会計、申告、人事労務、開業、会社設立、マイナンバー管理。いまだに全部見きれていないんですけど、そういったものがあったり、それのモバイルアプリ版があったりするので、かなり広いんです。
「これ、全部いきなりやるの無理だよね」ということで、「まずはちょっと的を絞ってチェックしていかなきゃ」となります。大きく分けて、「Webサイトのチェックというのをまずやってみよう」となりました。
自社の公式サイトをアクセシビリティチェックするとどうなるのか
W3C（World Wide Web Consortium）が出しているEasy Checksという、「とりあえず最低限チェックするとしたらここでしょう」というドキュメントがあるので、「これを使って、みんなでチェックしてみましょう」と、ちょっとワークショップっぽいことをやっています。では、実際に公式サイトのアクセシビリティチェックをしてみました。
意外に、マークアップをちゃんとしている気配が強いんですね。例えば見出しのレベルが飛んだりとか、リンクが画像とテキストで2つに分かれていて、同じテキストになっているとか、そういう軽微なものはあるんですけど、意味不明になっているものはそんなになかった感じでした。
ただ、画像に代替テキストが入っていない、ファイル名が入っている、他の代替テキストがコピペされて入っている、というパターンが生じているのは散見されました。
もう1つは、コーポレートカラーが青というか紺なんですけど、そこからバリエーションを出そうとして明るいほうに振る。そうすると水色のテキストが出てきて、これがコントラストチェックをすると引っかかるとか。あと、フォームのエラーが、ちょっと伝わらない可能性があるとか。
そういうことがあって、実は他の公式サイト以外でも、だいたいこの傾向があるというのがわかりました。
（スクリーンを指して）例えばこれ、読み上げられない図ですね。
この〇、×が、空のi要素です。i要素ということで、もう「なるほど」という感じだと思うんですが、Webフォント、アイコンフォントを使って出しています。中の要素は空なので、それが読み上げられないことがある。そうすると、「ちょっと比較ができないよね」という話がでます。
あと、こういう画像化文字があって、そこに対して代替テキストが入っていなかった、とかです。
それから、ヘルプですね。ヘルプのキャプチャも、ヘルプの文言としてはけっこう丁寧に説明しているんですが、このキャプチャに対してaltがない。空なので、そもそも画像があること自体に気付けなかったりする、という状況があります。
そして、このエラーですね。このエラーが出ると、視覚的には赤くなって吹き出しも出てわかりやすいんですけど、ここがスクリーンリーダーでは読まれない。
どこかが間違っているんだけど、どこが間違っているのかわからない、ということが起きています。
全盲のアクセシビリティ専門家はfreeeアプリをどうとらえているのか
「じゃあ、アプリケーション側はどうなのか？」というところを見ていきたいと思います。私は、これはやっぱりユーザー側に聞こうと思いました。中根（雅文）さんという、アクセシビリティについて調べてみるとよく名前が出てくる方がいらっしゃいまして、アクセシビリティの専門家で、かつ、全盲でスクリーンリーダーを利用されていて、なんと4年前からfreeeユーザーなんです。
なので、これはこの人に聞くしかないと思い、聞いてみました。けっこう辛口の方なので、インタビュー1時間半ボコボコになったということがあったんですけど（笑）。
（会場笑）
先に良いほうから言うと、「機能は優れている。紙を取り扱うことが難しいような我々こそが、こういうfreeeを使っていきたいと思えるものである」ということなんですね。
ですが、中根さんはエスパーみたいな方で、画面が見えないのに「ここはタグだね」とか、「カルーセルだね」とか、「アコーディオンだね」と言える人なんですけど、その人がかなり試行錯誤しないと使えないというのが現状です。
それで、（現状の問題点としては）読み上げない場合がある、アイコンにラベルがない、フォームの入力項目とラベルが紐付いてなかったり、ボタンが押せなかったりする。逆に「それでどうやって切り抜けてるんだ？」という話もあるんですけど、切り抜けられないわけではない。その理由は後述します。
浮かび上がる問題点
例えばこれですね。
ホームアイコン、家のアイコンがあるんですが、ここも先ほど申し上げたように、i要素で中身が空なので、そもそも読み上げることができない。あと、このアコーディオンを開くと、ちょっと見にくいんですけれど、下矢印が付いてます。
これを触ると、マウスだとアコーディオンが出るんですが、これはいわゆるdivボタンなので押せない。
それから、ラベルなんですが、これが非常に惜しいんです。label要素でマークアップはされているんですけどfor属性がない。
かつ、その中にinput要素がなく、紐付けできていないので、例えばこのダイアログに関しては、ラベルをひと通り読んだ後にフォームコントロールを読み上げる、というような挙動になってしまっています。惜しい。
そういうのが組み合わさると、例えばここの勘定科目、ちょっと見にくいんですけど、グレーのバーになっているところは実はtr要素で、そこをマウスクリックすると下のところが開きます。
ですが、このフォームコントロールがラベルと紐付いてなくて、サジェストがWAI-ARIAに対応してないので、ここは読み上げられない。ここが読み上げられないと、このテキストを完全一致でここに書かないといけない状況になって、使うのがしんどくなってくるんです。
あとは、ここはフォーカスリングが出てますけど、こちらではアウトラインが出てなくて、見えてる人でキーボードのユーザーが使えなくなっている、という組み合わせが起きています。
私、自社のプロダクトに対してこんなに指摘をしていって、つぎに会社行くの怖いんですけど（笑）、続けます。
（会場笑）
iOS版の利便性と改善点とは
じゃあ、なんで切り抜けられてるのかというと、「iOS版が存在するから」だったんです。iOS版は、「絶対使うだろう」という機能に絞られていたり、画面内要素が絞られていたりするので、比較的全容を把握しやすい。
そして、ネイティブアプリのつくり方が適切なので、ボタンが押せないというケースがなく、概ね先には進める。ただ、似たような課題があって、たまに読み上げない、たまにラベルが関連付いてない、たまに操作しづらい、というのがあるんです。
……ちょっとお待ちください。少しハムノイズが出ますが。これ、iOSの読み上げです。
（音声読み上げソフトを起動する）
読み上げ：……取引を登録、ボタン、レシート作成、ボタン、確定申告を始めましょう、2月の収支……。
伊原：けっこう読んでくれるんですね。
読み上げ：……合計、0、0、0、0……。
伊原：でも、ここはちょっと縦読みになっちゃう。じゃあ、他の画面だとどうか。
読み上げ：……口座、タブ、取引一覧、追加、を選択中の、口座振替、未登録の明細があります。
伊原：けっこう読んでくれます。
読み上げ：……31、2011年2月、31、未登録の……、2011年2月……。
伊原：ですが、ここ、今、必ず最初にフォーカスしてしまって、この月別のスクロールが必ず2011年にいってしまうので、なにかを選ぼうとすると、すごい選ばなきゃいけないというのがあります。
読み上げ：明細を閉じる、ボタン、自動で経理、見出し、ボタン、自動で経理、見出し、ボタン……。
伊原：「？」が「ボタン」としか言われない。押してみる。
読み上げ：明細を横にスライドして、サクサク処理、取引登録、プライベート資金。タップして開始……。
伊原：音だけだと、どっちにスワイプするかわからないですね。矢印の方向を言ってなかった。
読み上げ：……カード、2017年12月30日、5,000円、株式会社八重洲タクシー、東京都……。
伊原：けっこうちゃんと読んでくれるんだけど、ちょいちょい惜しいところがありますね。
読み上げ：……アイコン、トランスファー、ボタン……。
伊原：「アイコン、トランスファー、ボタン」、アイコン名で読まれてしまうボタンもある。
読み上げ：……カード、テキストフィールド、テキストフィールド……。
伊原：ここはラベルが紐付いてないところですね。「テキストフィールド」とだけ言っている。
読み上げ：……ホーム、タブ、読み込み中……。
伊原：とはいえ、ほとんどのものに触ることができるようにはなっているんですね。
読み上げ：取引登録、ボタン、未選択、テキストフィールド、取引テンプレート……。
伊原：ここはちょっと順番が入れ替わっている。
読み上げ：勘定科目、発生日、未決済、支払日……。
伊原：これは今、縦に読んでいますね。
読み上げ：口座、任意項目、取引先、品目、部門……。
伊原：あと、この赤いボタンについては読み上げられなかった。
これもけっこう惜しいですね。とはいえ、画面の要素が縦に並んでいることと、画面に出ているものが少ないことによって、比較的使えるというか、Web版をカバーできるようになっている、という感じです。
制作者のミスは実はパターン化している
ということを1時間半ほどインタビューをして、このケースだけが全部ではないと思うんですが、私が感じた感触としては、いわゆるパレートの法則というか、こういうのがありそうだなと思っています。
よく使う機能って、そんなに多くない。その中でよく遭遇するコンポーネントも、そんなに多くない。発生する問題のパターンも、わりとわかっている。なので、逆にそこだけ使えるようにすれば、ある程度なんとかなるんじゃないか、という感じもしたんです。
というのも、（ここで挙がった問題は）実はこの会の運営をしているサイバーエージェントのあほむさんという方の「既存Webアプリケーションのアクセシビリティを向上させる時によくあるヤツと対応方針」（Webサイト）にほぼ合致するんです。
何が言いたいかというと、人はマークアップを間違える時にパターンがあるということです。ぜんぜん示し合わせてない人たちなんだけど、そういう方向に収斂していくのが見えて、これはすごい知見だなと思いました。ここに改善案が書いてあるので、ぜひ見てみてください。ちなみにiOSアプリで対応するための記事もあります。
