水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記

最近一週間ほどのえび日記

2019年8月11日(日曜日)

字幕職人の朝は早い……

公開: 2019年7月11日21時0分頃

2019年7月20日、JACことJapan Accessibility Conference - digital information vol.2 (japan-a11y-conf.com) が開催されました。私は実行委員、スタッフ、スポンサー担当、司会、登壇といった役割で関わりました。

なお、各セッションの内容については、セッション一覧 (japan-a11y-conf.com)をご覧ください。

個人的に最も印象に残ったのは、セッションB-5の "Ask Us Anything" の一幕。とある動画サービスで、「補聴器ユーザーの葛藤と苦悩」という番組があったのですが、なんと、そういうテーマであるにもかかわらず字幕がついておらず、補聴器ユーザーが視聴できなかったのだそうです……。

さて、そんなJACですが、一部を除いてセッションの様子は配信されておりまして、動画のアーカイブも公開しています。

JACに参加していた私はもう、字幕をつけたくて仕方ないわけです。

というわけで、動画に字幕をつけるというのが今日のお話です。

YouTube自動字幕

実は、YouTubeで動画を公開すると、自動で字幕をつけてくれます

以上。終わり。

と言いたいところなのですが、やはり自動認識の精度は完璧ではなく、かなり怪しい部分もあります。「えーっと」が「8」になっているのはまあ分かるのですが、時折、意味不明な日本語になっていることもあります。

特に、固有名詞については非常に弱いです。「伊敷さん」が「意識さん」になったり、「Sli.doで質問を」が「スライド幽霊質問を」になったり。このあたりはまあ、当然と言えば当然で、仕方のないところでしょう。

また、笑い混じりの発言にも弱く、「すみません喰い気味に(笑)」というところが「すいませんクイーン不不不不不不不不不不」となっていたりしました。

と、弱点はあるものの、全体としては結構な精度で字幕がつくので、状況によってはもう自動字幕だけで十分、ということもあるかもしれません。

字幕をつける方法あれこれ

YouTubeの動画に字幕を付ける方法はいくつかあります。詳しくは、YouTubeヘルプセンターの「自作の字幕を追加する (support.google.com)」を見ていただくと良いでしょう。

今回は何回か字幕を付ける機会があったため、試行錯誤しながらいくつかの方法を試しました。

書き起こしテキストから字幕を生成する

YouTubeには、書き起こしテキストから字幕を生成する機能があります。書き起こしテキストを貼り付けると、内容を読み取って自動的に分割し、タイミング情報を付けたうえで字幕を作成してくれます。

実はこれでわりと行けますが、意図通りに分割されないことがけっこうあります。また、日本語の記号類 (句読点、括弧など) は消えてしまうことがあります。

YouTubeには手動で字幕を編集・調整する画面もあるので、調整の量が少なければYouTube上でやってしまうのも良いでしょう。

字幕ファイルをアップロードする

もう少し本格的にやりたい場合は、字幕ファイルをアップロードすることもできます。

字幕ファイルにはいくつか形式がありますが、もっとも簡単なのは SBV という形式のものです。中身は以下のようなテキストファイルです。

29:24.000,29:28.000
今日ここ、Abema Towers(アベマタワー)っていう場所じゃないですか。

29:28.000,29:38.000
最近、Abema Primeっていう番組で、「補聴器ユーザーの葛藤と苦悩」という番組があったんですね。

字幕の表示開始と終了の時刻をカンマで区切って書き、改行して字幕のテキストを書くという上にシンプルな形式です。

字幕には改行を入れることもできます。改行を2つ連続させると字幕の終了とみなされます。

※ミスって字幕の終わりの改行を一つにしてしまうと、次の字幕の開始時刻、終了時刻、テキストまでがひとつの字幕として表示されることになります。

見ての通り簡単な形式ですので、ツールで生成することもできるでしょうし、何なら手作業で書くこともできます。

ただし、うっかり全部手作業で作ろうとすると、大変な時間を費やすことになるので注意してください。動画を再生しながら字幕の開始・終了時刻を入れていくのは、単純な作業ではありますが、時間はかかります。

字幕ファイルを生成させて調整する

合わせ技もあります。字幕をファイルとしてダウンロードすることもできるので、書き起こしから生成させたものをダウンロードし、手元で調整してから再アップロードすることも可能です。

実際のところ、これが最もお勧めです。

最大のポイントは、細かく分割すること

いろいろやってみて、最大のポイントだと思ったのが、字幕を分割することです。

字幕が長すぎると、文字を大きくしたときに、字幕が画面上を覆いつくして画面が見えなくなってしまいます。普通の感覚でワンセンテンスをそのまま一つの字幕にすると、たいてい、長すぎになります。先に挙げた.sbvファイルのサンプルはちょっと長すぎる例です。

YouTubeに書き起こしテキストを食わせて字幕を生成する場合は、長いと判断されると勝手に分割されます。ただしその場合、意図した場所で分割されないことが多いです。事前に細かく分割してから食わせましょう。

書き起こしテキストにも .sbv ファイルと同様のルールが適用されるのか、改行を2つ入れておくと、その分割位置を尊重してくれます。改行1つだと無視されて、勝手に違う場所で分割されてしまいます。また、長すぎると判断されるとさらに勝手に分割されることがあります。

一つの字幕はできれば10文字程度、最大でも10文字×2行くらいだと思ってください。細かすぎでは? と思うかもしれませんが、入れてみるとこんなものでちょうど良いはずです。あらかじめ、かなり細かく分割しておくことがポイントです。

まとめ:
  • JACの動画に字幕をつけてみた
  • 字幕をつける方法はいくつかある
  • 手動でタイミングを調整するのは大変
  • 書き起こしテキストからYouTubeで生成させて、ダウンロードして調整するとGood
  • テキストはあらかじめかなり細かく分割しておくと良い

関連する話題: アクセシビリティ

2019年7月7日(日曜日)

タブUIのキーボード操作はユーザーに理解できるのか?

公開: 2019年7月7日22時5分頃

先日このような記事を公開しました。

いわゆるタブUIがキーボード操作できなかったので対応させたという話なのですが、結論としてはtabロールをつけない判断をしたということです。

WAI-ARIAのtabロールを使うと、WAI-ARIA対応するスクリーンリーダーに対して「タブ」という通知をすることができます。また、スクリプトで制御すれば、タブ切り替えのキーボード操作に対応させることも可能です。その対応をした場合どうなるのか、記事には以下のように書きました。

スクリーンリーダーでも「タブ」として操作可能にする

OSが提供するタブの機能をWebで再現する。基本的には望ましい対応だが、タブ操作に慣れていないユーザーは逆に混乱する可能性もある。また、さまざまな実装を行う技術が必要で、一定のコストがかかる。

以上、なぜ「タブ」はスクリーンリーダーで読めない? タブをアクセシブルにする より

「タブ操作に慣れていないユーザーは逆に混乱する可能性もある」と書きましたが、これについて少し補足しておきます

ここで想定しているタブのキーボード操作は、「コーディングWebアクセシビリティ: WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション (www.amazon.co.jp)」で紹介されているものです。具体的には、以下のような記述になっています。

  • 左右の矢印キーを使って隣接するタブを切り替える(フォーカスを移す)。これは対応するタブパネルを表示するアクションでもあります。
  • アクティブな(aria-selectedな)タブと対応するtabpanelとの間を、Tabキーで切り換え、Shift + Tabキーで戻れるようにする。

以上、コーディングWebアクセシビリティ 5-4 タブを1つください! より

tabキーでタブにフォーカスしたら、タブの切り替えは左右の矢印キーで行います。その後、さらにtabキーを押すと、現在選択しているタブに対応するタブパネルに移動します。

これは、WindowsなどのOSが提供するタブUIのキーボード操作と対応しています。タブをタブとしてふるまわせる場合、OSのタブの動作と合わせるのは合理的ですし、合わせるほうが良いはずです。

しかしこの操作、一般的なWebのユーザーに使いこなせるのでしょうか。Webコンテンツの大半はtabキーでフォーカス移動、Enterキーで決定するだけで使えるようになっています。左右カーソルキーを使うのは、入力フォームくらいで、コンテンツ閲覧時にはほとんど使わない操作です。Webコンテンツ内でタブが出てきたとき、左右キーで切り替え操作をするものだと自然に気づいてもらえるものでしょうか。

※もっと言うと、最近は、OSの中でタブUIを見かけること自体が減ってきているようにも思います。

こういったことを考えた結果、タブをタブとしてふるまわせないほうが良いのではないか、と判断したのでした。

とはいえ、実際にユーザーが使えるかどうか試してみたわけではないので、もしかすると普通に使えるのかもしれません。機会があれば、ユーザーテストをして判断してみたいところではあります。

まとめ:
  • タブをタブとしてふるまわせることは難しくない
  • タブとしてふるまわせるなら、OSのタブの操作と合わせるべき
  • しかしその操作はWebコンテンツではあまり一般的な操作ではないように思える
  • なので、今回はあえてタブではないふるまいにした
  • タブ操作がユーザーに伝わるのかどうかユーザーテストをしてみたい

関連する話題: アクセシビリティ

最近の日記

関わった本など