情報保障に向けた取り組み ~文字起こし編~
本記事は『LITALICO Advent Calendar 2019』の15日目の記事となります！
今回はタイトルの通り、情報保障について、普段考えていることと実践について書いてみようと思います。
情報保障とWebアクセシビリティ
普段私は 株式会社LITALICO でWebエンジニア& エンジニアマネージャをしています。
LITALICOでは「障害のない社会をつくる」というビジョンを掲げながら様々な事業を展開中です。
ここで言う「障害」は、いわゆる障害者手帳の取得の有無に関わらず、もっと広義の意味での「障害」のことを指していると、少なくとも私は思っています。
それは「情報」においても同様です。
インターネットの発展によって、より多くの人を通して、時間と場所の制約なしに「情報」を提供したり、受け取ったりすることができるようになりました。
一方で、「情報」を得たくても何らかの理由で「情報」にアクセスできない人がいるのもまた事実です。
「情報」を必要としている人が「情報」にアクセシブルでない状況を、情報提供者としてできる限り排除しようと努力するのは、合理的配慮の範囲であると私は考えています。
いわゆる「情報保障」です。
情報保障とは、人間の「知る権利」を保障するもの。 いつでも、誰も情報が伝わらない状況に陥る可能性がある。 特に聴覚障害者は、音声によって提供される情報や会話を理解できないため、日常的に情報から疎外されているといえる。 そのため、一般的に「情報保障」とは、聴覚障害者に対するコミュニケーション支援を指して用いられる。
Wikipediaには、聴覚障害者に対するコミュニケーション支援を指すのが一般的との記載がありますが、聴覚障害者だけではありません。
例えば、知的障害者にとって、漢字で書かれている文章などは読むのが非常に困難な場合もあります。読めなければ、当人に「情報」は届いていませんよね。
また、これは障害者に限った話ではありません。高齢者もそうですし、これを読むみなさんも、何らかの理由でいつだって情報にアクセスできなくなる可能性があります。
「情報」の中でも、Webを通して伝える「情報」がアクセシブルであるかどうかを「Webアクセシビリティ」と言います。
Webアクセシビリティについては、以前にもQiitaで記事を書いていますので詳しくは参考にしてください。また、ネットにもたくさん情報が落ちていると思います。
ここまでで、なんとなく「情報保障」が必要な理由はご理解いただけるかなと思いますので、ここからは普段の取り組みと、実践について書いていこうと思います。
※ 「なぜ情報保障が必要なのか」をより詳しく知りたい方は、ADA（障害を持つアメリカ人法）とWebアクセシビリティに関する訴訟や、日本の差別解消法と東京都の条例について調べるといろいろとわかると思います。
情報保障への取り組み
前述のQiitaの記事を書いたあとくらいから、Webアクセシビリティの取り組みをいくつか行ってきました。
・会社の有志で、情報保障やWebアクセシビリティに関する啓蒙活動
・会社で運用するWebサービスに対して、現実的にアクセシビリティを導入していくためのレギュレーション・ガイドライン策定、コードの実装・修正
・会社で実施する外部向けイベントに対して、情報保障のお手伝い
・Webアクセシビリティ基盤委員会のWG4（翻訳ワーキンググループ）にて、W3Cの作成するWCAG 2.0関連文書の翻訳
今回は、「会社で実施する外部向けイベントに対して、情報保障のお手伝い」について普段の実践をご紹介します。
ライブ文字起こし
月イチで下記のようなイベントを行っているのですが、合理的配慮の一部として、講義をリアルタイムに文字起こしする取り組みを実践しています。
機器構成図から先にお見せします。
簡単に言うと、発話者の声を集音し、UDトークという文字起こしのできるアプリにインプットして文字にしたあと、起こした文字の修正をします。
大きく分けて、「集音機器」「投影機器」「トーク編集機器」「トーク&ユーザ管理」があります。順に見ていきます。
集音機器
発話者の声をマイク等で拾って、UDトークにインプットする部分です。
①の部分で、マイクからの音を「キャノンケーブル」というケーブルを使ってUDトークにインプットしています。（マイクのアウトプットがどの端子になっているか事前に確認しておきましょう。）また、UDトークへのインプットの際に、アナログ入力をする必要があるのですが、最新のiPadだとアナログ入力端子がありません。
USB-TypeCとイヤホンジャックの変換器も使ったりしたのですが、うまくインプットされないので、iRig2というアンプとアナログ入力を兼ねた変換器と、何世代か前のiPad（3.5 mm ヘッドフォンジャック付きのもの）を使っています。
集音機器周りのポイントは下記
・マイクの音量が低かったり、発音が不明瞭だと認識率が悪くなるので、事前に調整しておく
ちなみに複数人が話す場合は、ピンマイクで集音し、ミキサーが出る音を集音用の端末（iPad）にinputする。もしくは、iPhoneを各々が持ち、UDトーク上で発言権限を付与しておくと、発言した端末の区別から、誰が話したかまでログに残せる。
・固有名詞や人名などは、事前にUDトーク上で単語登録をしておく（辞書登録のような機能があります）
よくあるのは、実際に話すときに愛称などで呼ぶ場合、当然正しく認識できる確率は下がるので、文字起こし後の要修正確率が高まります。
・インターネット回線速度を十分に確保する
これは集音以外の部分もそうですが、アプリを介して文字起こしをしているため、ネット回線がボトルネックになり得ます。
恐らくですが、マイクで拾った音をオンライン（おそらくサーバーサイド）で文字起こしをし、それをクライアントに返しているので、若干タイムラグはありますが、ネット回線速度が十分にあればストレスはないです。
弊社は念の為、有線LANを使って実施しています。
古いiPadですと、端子がLightningケーブルだったりするので、②のようにLANケーブルとの変換器を使っています。
投影機器
集音された文字をUDトークのアプリを経由してスクリーンに投影する部分です。
集音用と投影用の端末（iPad）は同じ端末でもいいのですが、アナログ入力ができて、かつ、HDMIでプロジェクタと接続することを考えると、iPadやそれに必要な変換器が見つからなかったので、敢えて分けています。
ここで使うiPadは最新のもの（端子がUSB-typeCのもの）で問題ありません。③でLANとHDMIにつなぐため、下記のような変換器を用いています。
また、講演となると通常はスライド等をスクリーンに投影すると思いますが、字幕はそのスクリーンとは別で用意しています。
加えて、聴衆の視線移動をできるだけ少なくできるよう、講演者、資料投影用スクリーン、字幕投影用スクリーンは横一線に並ぶように配置しています。
トーク編集機器
PCやスマートフォンを使って、文字起こし後の文字を適宜修正していきます。
基本的には、PCの方が修正が速くできると思いますが、スマホからでも問題なく修正は可能です。
その際、集音同様にネット回線がボトルネックになってしまわないように、十分に速度を確保することをおすすめします。
発話者に特段ゆっくりしゃべってもらうなどしない限り、発言のタイムラインがすごい速度で流れていきます。
また、当然ですが、発言を聞きながら文字を修正していくことになるので、回線が遅いと、手元で字幕が表示されるのにタイムラグが発生してしまい、どの発言を何に修正したらいいのか全くわからなくなって焦ります（笑）
字幕の修正をPCで行う場合は、専用のアプリがあるのでこれを使って修正しましょう。
トーク&ユーザ管理
字幕は「トーク」という単位で保存されていきます。イメージとしては、LINEのトークルームのような感じでしょうか。
講演ごとに「トーク」を作成し、それを適切な権限（閲覧権限、発話権限、編集権限）ごとにQRコードやURLを発行して共有します。
このトーク管理を行うアプリが「UDコネクト」です。
こちらのアプリはiOS版でのみ提供されています。
集音用や投影用のiPad上でもトーク管理はできますが、集音や投影が始まってしまうとUDトークのアプリを閉じることができないため、「この人にトークを招待するの忘れた」「この人に編集権限をつけてトークを共有したい」となったときに困るので、端末を分けることにしています。
まとめ
以上、Webアクセシビリティと、その取り組み・実践について紹介しました。
今回はご紹介できませんでしたが、講演の後に起こした文字のデータをCSVで出力して修正し、youtubeの字幕として使ったりもしています。
この記事が、少しでも情報保障について考えるきっかけとなれば幸いです。
最後に、アクセシビリティや文字起こし、LITALICOに興味がある方はぜひお気軽にご連絡ください。
明日は @KakkiiiiKyg が「Google Analytics を導入しようとなった時にエンジニアがやるべきこと」を書いてくれます。お楽しみに！
よろしければサポートよろしくお願いします！いただいたサポートは、開発費などの個人事業の資金にさせていただきます！