登壇に​あたり発表資料を​どのように​作っているか

この記事はyamanoku Advent Calendar 2023の10日目の記事になります。

私はここ数年ありがたいことに国内のフロントエンドにまつわるカンファレンスにてCFP（Call for papers）が当選し、登壇・発表すること機会をいただけております。登壇するにあたり発表資料を作っていくわけなのですが、どのように作っているかについては特に触れられていないと思いました。

そこで今回は、今年10月に開催されたVue Fes Japan 2023での発表資料を例に、発表するまでどういった流れで行っていたのかを紹介していきます。

今後登壇や発表してみたいと考えている人たちの参考になれば幸いです。

発表資料の作り方

CFPを提出するための内容を考える

まずそもそもですがカンファレンスにCFPを提出しないことには発表する機会もいただけません。これはよくあるミスです¹。

前回のVue Fes JapanではVue.js でアクセシブルなコンポーネントをつくるためにという話をしてみました。その続編的なものとしてアクセシブルなアプリケーションを作ってみる、というお題にするのはどうかと考えてみました。

まずNuxt.jsでのアクセシビリティ観点でイケていない点を探してみることにしました。最初にNuxt.jsのGitHubリポジトリを覗いて、アクセシビリティに関するIssueを探してみました。そのなかにRoute accessibility announcerというIssueを見つけました。

Route AnnouncerはSPAのアクセシビリティを考える上で必要になる機能です。1つのindex.htmlを元に多数のページがあるように見せているだけのため、ページが切り替わった際のその情報を伝えることはできていません。そのためにRoute Announcerという機能を作って、ページが切り替わったことを伝えるようになっています。Nuxt.js本体にはその機能がないため、作ってみてはどうかというIssueでした。

そこで私はまずNuxt.jsでアプリケーションをデフォルトで作った際に画面遷移において支援技術（スクリーンリーダー）ではどういう結果になるかを実際に調べてみました。

npx nuxi@latest initよりデモアプリを作り、ページを複数作って移動するときの挙動をVoiceOverにて確認しました。たしかに遷移したときにページの状態が通知ができていないことが確認できました。

アクセシビリティにまつわる改善はいくつかありますが、今回はこの画面遷移にまつわる部分についてを取り上げてみようと思いました。クライアントサイドルーティングやアニメーションに関してのアクセシビリティ上の課題についても出しつつ、それを元にどういったことを発表していくかを考えていきます。

最終的に発表タイトルを「画面遷移から考えるNuxtアプリケーションをアクセシブルにする方法」とすることに決めて、概要としてはNuxt.jsのことを触れつつ課題を紹介して求められている期待に対して応えられるように、以下の内容になりました。

ブラウザ側で画面遷移を制御するクライアントサイドルーティングという手法はサーバーからの待ち時間を無くしスムーズにブラウジングできるようにして、画面遷移における認知負荷を減らす点で活用されています。 Nuxt 3.4 からは実験的に搭載された View Transitions API の設定でスムーズな遷移アニメーションが実現できるようになりました。
しかし、これらの手法は情報が正しく伝わるかどうかのアクセシビリティ観点から考慮が必要なものです。 本セッションでは、画面遷移時にどのように情報が伝わっているのか、Nuxt アプリケーションをよりアクセシブルにするためのアプローチを実装例を元に紹介します。

この形でVue Fes Japan 2023のCFPを提出してみました。

発表する関連する情報を収集していく

CFPが当選して発表することになったら、次は発表に関連する情報を収集していきます。とはいえすでに提出する段階でいくつか情報は得られているので、それをベースに考えていきます。私はScrapboxを使って関連する情報をまとめていきました。

画面遷移から考えるNuxtアプリケーションをアクセシブルにする方法 - yamaScrapbox

関連するIssueやPull Request、関連しそうなページや記事、実装方法を収集していきます。調べているうちにNuxt.jsのロードマップ内に「a11y」というアクセシビリティの機能開発にまつわるものも見つけ、今後取り組んでいくことがわかったのは収穫でした。

まず前段としてアクセシビリティについての説明をはさみ、単純にアプリケーションを作るだけだと生じる問題点、それをどう解決していくかの実装例を紹介していくようにしました。今回は画面遷移に関する部分だったのでNavigation APIを活用した問題点の解消も触れてみたいと思い、おまけとして取り上げるようにしました。

スライドに書き込む

次は発表スライドに書き込んでいきます。これはよくない慣習なのですが、Scrapboxに情報をまとめているだけですでにスライドは出来上がってしまったと勘違いしてしまいがちです。まとまった情報を元にちゃんと発表するためのスライドに書き込んでいきます。前回のVue Fes Japan 2022での発表資料と同様にKeynoteを使ってスライドを作成していきます。

実際に発表する内容としては文字表現として伝えるべきなのか、図として伝えるべきなのか、コードとして伝えるべきなのか、それぞれの状況によって適切な表現方法が異なってきます。

基本的には見出しのような文字情報として作成していき、必要に応じて見せ方を切り替えていきます。図だけを連続させるとそこから何を伝えたいかがスライドからは伝わりづらいため、注目させる部分を強調させたり、最低限のみの情報だけを伝えるようにしています。

コード例はCarbonを使い、コードを画像としてスライドに貼り付けています。

発表原稿を作る

スライドに書き込んだ内容をもとに発表原稿を作ります。スライドの内容だけを見て発表ができたら良いのですが、言いたかったことが抜け漏れてしまうかもしれないため、事前に発表原稿を作っています。

各スライドを元にしてざっくりと発表原稿の輪郭部分を作っていきます。この時自分の言葉で発表するにあたりどこまで把握できているかも確認するため音声入力で発表原稿を出力するようにしています。

この時もしも言葉が出てこず詰まってしまった場合はChatGPT（GPT-4モデル）の力を借ります。プロンプトに発表タイトルと概要を入力し、特定のセクションにまつわる情報を追加して、それっぽい発表原稿を作成してもらいます。もちろんこれはあくまで輪郭となる部分であり、そのまま発表原稿として使うことはありません。

その輪郭となる発表原稿を元に内容の正誤や自分が伝えたいところを整理していきます。最後は再びChatGPTで誤字脱字や言い換えの問題がないかを添削してもらい、各スライドの発表原稿を完成させていきます。

スクリーンリーダー出力結果の動画を収録する

今回の発表では実際の実装例を紹介する他に、聴者がイメージしやすいように実際に画面遷移におけるスクリーンリーダーの出力結果の様子を録画して取り入れようと思いました。

使用するスクリーンリーダーはMacOS標準のスクリーンリーダーであるVoiceOverとWindowsOSのみで動くNVDAというスクリーンリーダーを使った事例を紹介してみています。ほかデバイスの事例も含めようかと思いましたが、明確な挙動の違いを理解するのと、操作に扱い慣れていたものだったのでこの2つを選びました。

動画の収録の際し、万一デモの様子の音が聞こえない場合のためにも字幕情報が必要だと考えました。MacOSでのVoiceOverであれば読み上げてくれた音声をテキスト情報としてデフォルトで書き出してくれるのですが、NVDAの場合設定を変更しないとそれが確認できません。設定としては「スピーチビューアー」というものがあり、これを有効にすることで読み上げている音声を別ウィンドウでテキスト情報として書き出してくれます。

MacOSではスクリーンリーダーの音声をそのまま出力して録音することができなかったため、ミキサーから出力するように調整しています。この部分の具体的な手法については、ymrlさんによる記事が非常に参考になりました。

MacOSではスクリーンショットというツールで画面を収録できます。Windowsでの画面収録方法が今どうなっているかは把握していなかったのですが、現在は標準で「ゲームバー」を使うようになっていました。これを使って操作している画面を録画することができました。しかしNVDAの録画で難点だったのが操作している画面とスピーチビューアーとは別の画面録画になっており、一緒には映ってはいませんでした。

この問題を解決するためにOBS Studioを活用することにしました。具体的にはNVDA音声つきの操作画面と、スピーチビューアーでの画面をそれぞれ組み合わせて1つの動画を作成しました。OBS Studioでの出力された動画形式がmkvとなっておりKeynoteでは読み込めなかったため、コンバーターツールを使って動画形式をMP4に変換してから読み込むことができました。

発表練習をする

最後に全て揃った段階で発表練習をします。ストップウォッチを活用して時間を測ります。今回は発表時間が30分ということで、LTのものと比較すると長丁場の発表になります。発表内容はいくつかのセクションで切れそうだったので、それを元にこのセクションにはこれだけの時間を配分して喋ろう、というイメージで考えていきます。

発表する際は早口にならないように1スライドごと喋った後は一呼吸おけるように配分を考えておきます。発表原稿も実際に喋ってみると違和感のある言い回しだったりするときもあるのでその都度内容を修正していきます。もし発表時間がオーバーしそうだったり、逆に余裕がありそうな場合は、スライド自体を減らすか増やすかの修正もしていきます。

発表練習において文章をきちんと理解できているかも確認できます。頭の中で文章を把握しているつもりでも、口でそれを伝える際に噛んでしまったりうまく言葉が発せられなかったりすることはあります。何度も喋っていくうちに言い方や伝え方も工夫できるようなゆとりが生まれてきます。

何度も練習を試してみて30分内に収まりそうなのが分かったら、発表資料の完成です。

HTML版ページを作成する

次に発表資料を共有・公開するためにHTML版のページを作成します。通常であればSpeakerDeckなどのスライド共有サービスを使うことが多いですが、それだけではスライド内に提示されたリンク先に飛べなかったり、コードをコピーすることもできず、動画も再生できないことからHTML版のページを作成することにしました。HTMLで提供することでよりアクセシブルになることもポイントです。そして完成したのが以下のページです。

画面遷移から考えるNuxtアプリケーションをアクセシブルにする方法

ちなみにSpeakerDeck版もそれはそれで作っていたりもします。

こうしたHTML版のページを作成するにあたり、ページテンプレートとしてyamanoku/document-page-templateというものを作成しています。フロントエンドビルダーに11tyを使っています。

発表原稿をもとにしてタイトル部分を見出し化して発表資料を文章にして作成していきます。文書はマークダウン形式で記述していき、動画は<video>要素にして埋め込んでいます。

Vue Fes Japan 2023は日本のイベントとはいえ、海外からのスピーカーや一般参加者もいるため、日本語ページとは別に英語ページも作成しています。私は英語話者ではないためあまり堪能ではないのですが、英語ページはDeepLや生成AIを活用して文書の言い換えてもらい、再翻訳したときに違和感のない言葉になっていないかを確認して作成しています。

実際に会場でどう見えるか・聞こえるかをチェックする

今回私の発表内容ではスクリーンリーダーの内容を知ってもらうために音声つき動画を配信するため、実際に収録した動画がどう見えるのか・聞こえるのかをチェックをしてもらいました。Vue Fes Japan 2023では登壇者向けに前日で会場でのチェックができるのを受け付けていたため、そちらをやってみることにしました（もし案内が無かったとしても直接ご依頼していたと思います）。

発表場所である中野セントラルパークに出向きチェックしに行きました。画面がどう見えるのかも確認しつつ、スタッフの方々に音声出力の調整をしていただいて音の問題ないことが判明したのでこれで発表準備に際して必要だったことは完了しました。

Vue Fes Japanスタッフの皆さん、その節はありがとうございました！

今回の発表における反省点

今回は私の発表資料の作り方の流れを紹介しました。何度か発表する機会はもらいつつも、まだまだ発表資料の作り方や内容については勉強中です。現時点での見せ方もまだまだ改善の余地はあると思います。

発表においてどこまでを伝えるべきか、どこまでを伝えなくても良いのか、を考えるのは難しい部分です。今回の発表内容については、アクセシビリティにまつわる課題を解決するための実装例を紹介することに重点を置いていましたが、そもそもアクセシビリティについてを知っているかどうかは聴衆によっては異なるため、そのあたりの雰囲気を知っておくことも必要だったかもしれません（目の前の人たちから即座に反応をもらい把握する点はオフライン登壇ではやりやすいはず）。

アクセシビリティの改善という点においてはNuxt.jsにてアクセシビリティ改善をしている人や企業、実際の障害当事者の声（今回であればスクリーンリーダーを活用するユーザー）をインタビューして聞いてみたり、改善されていった結果のユーザーの声はどうなったのかも含めていくと、より内容の理解に繋がると信じています²。

ちなみに今回の発表内容は当日弊社から発表するメンバー間で共有はしていたのですが、私の発表内容について（主にアクセシビリティに関して）造詣が深い人からのフィードバックをいただけてはなかったので、発表内容としての出来については不安は残っています。ウェブアクセシビリティにまつわるDiscordチャンネルもあるので、そちらで発表内容のレビューを依頼してみてもよかったかもしれません。

来年以降どういった場で発表していこうかについてはまだ考えていませんが、機会があれば今回の反省点を踏まえてより伝わりやすい内容に改善していきたいと思っています。