【ITニュース解説】Shareable, Accessible, and Non-Blocking: Three Upgrades for a Client-Side Text Repeater

Web上で動作するシンプルなツールを開発する際、ただ機能が動作するだけでなく、実際に使う人々のことを深く考えて設計することが重要となる。単に画面に出力されるだけのツールでは不十分で、使い始めることで三つの重要な課題が浮上することが多い。一つ目は、設定した内容を友人に簡単に共有したいという要望。二つ目は、スクリーンリーダーのような支援技術を使っている人でも問題なく利用できるかというアクセシビリティの課題。三つ目は、大量の処理を行った際に画面がフリーズすることなく、快適に操作できるかというパフォーマンスの課題である。これらは、フレームワークに頼らず、素のJavaScriptで解決できる場合が多い。

最初の課題は、ツールの「状態」を共有可能にすることだ。例えば、特定のフレーズを何回繰り返すか、区切り文字は何にするか、といった設定を友人に伝えたい場合、すべての設定を口頭やチャットで伝えるのは手間がかかる。この解決策として最も手軽なのが、URLのクエリ文字列にツールの設定を保存する方法だ。WebページのURLの「?」以降に続く部分がクエリ文字列と呼ばれ、ここに「p=Happy%20Birthday&n=100&s=newline」のようにキーと値のペアで設定情報を埋め込む。JavaScriptではURLSearchParamsというオブジェクトを使って、URLからこれらの値を簡単に読み取ったり、新しいクエリ文字列を作成したりできる。ツールが読み込まれた際にURLから設定を読み込み、フォームに反映させることで、ユーザーは設定済みのURLを共有するだけで、同じ状態のツールを友人に渡すことができる。また、ユーザーが設定を変更するたびにhistory.replaceStateという関数を使ってURLを更新することで、ブラウザの履歴を汚さずに常に最新の設定がURLに反映されるようにできる。ここで重要なのは、URLから読み込んだ値は常に「外部からの、信頼できない入力」として扱うことだ。例えば、繰り返し回数に非常に大きな数値が指定された場合、ブラウザがフリーズする可能性があるため、必ずclamp関数のようなもので、許容される範囲に制限（クランプ）する必要がある。さらに、URLの値を直接HTMLに挿入する際にはinnerHTMLを使うのではなく、textContentやvalueプロパティを使うべきだ。これは、悪意のあるスクリプトがURLに埋め込まれて実行される「クロスサイトスクリプティング（XSS）」というセキュリティ上の脆弱性を防ぐためである。

二つ目の課題は、スクリーンリーダーを利用する人々にとって、ツールが「アクセスしやすい」ものであるかどうかだ。テキストを繰り返すツールのように、大量のテキストを出力する場合、単にそのすべてをスクリーンリーダーに読み上げさせようとすると、ユーザーにとって非常に使いづらいものになってしまう。スクリーンリーダーがすべての行を読み上げようとすることで、かえって情報過多になり、重要な情報が伝わらなくなるためだ。これを解決するためのより良い方法は、出力されるコンテンツと、そのコンテンツに関する「お知らせ」を明確に分けることだ。具体的には、生成された大量のテキストは通常のtextarea要素に表示し、このtextareaにはlabelタグを使って適切な名前を付ける。こうすることで、スクリーンリーダーのユーザーはtextareaにフォーカスを移動し、普段使っている読み上げコマンドで、必要な部分だけを自由に読み進めることができる。一方、生成されたテキストの量や、処理が完了したことを知らせるメッセージは、role="status"属性を持つ別のp要素などの「ステータス領域」に表示する。このrole="status"は、スクリーンリーダーに「これはユーザーにとって重要な短いお知らせであり、途中で割り込まずにすぐに読み上げるべきだ」と伝える役割を持つ。このようにすることで、ユーザーは大量のテキストに邪魔されずに、ツールの状態を簡潔に把握できる。他にも、コピーボタンやダウンロードボタンにはアイコンだけでなく、具体的な操作内容を示すテキストラベルを付けることや、コピーが完了した際にはステータス領域に「クリップボードにコピーしました」と表示すること、アニメーションを使用する場合はprefers-reduced-motionという設定を尊重して動きを控えめにすることも、アクセシビリティを高める上で効果的である。

三つ目の課題は、大量の処理を行った際にWebページが「非ブロッキング」である、つまりユーザーインターフェースがフリーズしないようにすることだ。JavaScriptは通常、ブラウザのメインスレッドで動作し、このスレッドは画面の描画やユーザーからの入力受付も担当している。そのため、メインスレッドで重い処理を実行すると、その間は画面の更新が止まり、ユーザーの操作を受け付けなくなり、あたかもページがフリーズしたように感じられる。テキスト繰り返しツールの例では、String.prototype.repeatという組み込みの関数が非常に高速であるため、単にテキストを繰り返すだけであれば、ほとんどの場合メインスレッドで処理しても問題ない。しかし、各行に番号を付けたり、特定の書式で整形したり、といった少し複雑な処理が加わると、処理時間が増大し、メインスレッドをブロックする可能性が出てくる。このような場合に役立つのが「Web Worker」だ。Web Workerは、JavaScriptの処理をメインスレッドとは別のバックグラウンドスレッドで実行するための仕組みだ。これにより、重い計算処理をWorkerに任せている間も、メインスレッドは画面の描画やユーザー操作の受付を継続でき、UIの応答性を保つことができる。Web Workerは通常、別のJavaScriptファイルとして用意する必要があるが、短いコードであればBlobオブジェクトとURL.createObjectURLを使うことで、その場でWorkerを作成することも可能だ。Workerとのデータのやり取りはpostMessageとonmessageというメソッドを使って行われ、Workerに計算を依頼し、結果が返ってきたらそれを受け取って画面に表示する、という流れになる。ただし、Web Workerを使う際にはいくつかの注意点がある。セキュリティ設定（Content Security Policy）によってはWorkerの作成が制限される場合があること、Workerとメインスレッド間で大きなデータをやり取りする際には、データがコピーされるためオーバーヘッドが発生する可能性があること、そしてWeb Workerが利用できない環境のために、Workerが失敗した場合のフォールバック処理（メインスレッドで実行する代替処理）を用意しておくこと、などが挙げられる。

これらの要素を組み合わせることで、シンプルなテキスト繰り返しツールでも、ユーザー体験を劇的に向上させることができる。ページが読み込まれたらURLから設定を読み込み、ユーザーが設定を変更して実行ボタンを押したら、Web Workerでテキストを生成し、結果をアクセシビリティに配慮した方法で表示する。そして、結果が表示されたら、その時点での設定をURLに反映させておく。このように、機能がシンプルであるかどうかにかかわらず、実際に使われるツールには、共有性、アクセシビリティ、そしてパフォーマンスといった本格的なエンジニアリングの視点が求められるのだ。これらの改善は特別なライブラリやフレームワークに依存せず、標準的なJavaScriptの機能だけで実現できる。スマートフォンを使っているユーザー、スクリーンリーダーを使っているユーザー、または共有されたリンクからアクセスするユーザーも、すべて大切なユーザーであり、彼らの体験を考慮した設計は、ツールの価値を大きく高めることになる。