ツールチップという機能は、たいていホバーとセットで説明されます。用語にマウスを載せると吹き出しが出ます、と。ところがその操作は、板ガラスを指でさわる端末には存在しません。読者の手元にホバーが無い以上、「載せると出る」という説明はそこで行き止まりになる。
用語注釈マネージャーのツールチップは、スマートフォンではタップで開きます。仕様としてはこの一行で終わり。本題はその先で、開く手段があることと、読者がそこを押せると気づくことは、まったく別の問題です。用語をどの形式で見せるかを、説明の中身だけでなく端末も条件に入れて決めておくと、辞書を組んだあとの手戻りが減ります。
ホバーが無いぶんは、タップとフォーカスが引き受ける
用語に付いた印をタップすると吹き出しが開き、もう一度タップすると閉じます。吹き出しの外側をどこかタップしても閉じる。キーボードで読んでいる人なら Esc キーでも閉じられます。開いたまま画面に居座って本文を隠し続ける、という状態にはなりません。
吹き出しの中に「詳しく見る」リンクを置いている場合、そのリンクへのタップだけは開閉の対象から外してあります。開く→リンクを押す、の二段でちゃんと詳細ページへ進める。逆に言うと、スマホの読者にとって詳細URLは指2回ぶん遠い場所にあります。そこまで踏ませたい用語かどうかは、登録するときに一度考えておく価値があります。
もうひとつ、注釈の印はキーボードでフォーカスできるようにしてあります。マウスを使わない読者や支援技術からも、Tab で用語まで移動すれば説明が開く。ホバーの代わりが「タップ」だけではないことは、押さえておいて損がありません。
押せると分かる手がかりが、下線しか残らない

パソコンでは、用語の上にカーソルを持っていった時点でカーソルの形が変わります。押す前に「ここは何かある」と分かる。この合図が、タッチ端末では丸ごと消えます。カーソルが無いのだから当然で、残るのは用語に付いた点線の下線だけ。
下線は下線で、読者には「リンクかもしれない」とも読めます。押してみるまで、ページが切り替わるのか、その場で説明が出るのか判別できない。ここが端末をまたいだ瞬間に崩れる場所です。パソコンで確認しているかぎり、この崩れは見えません。
だから、タップ前提の用語をひとつの記事に並べすぎないほうがいい。印が増えるほど、読者は一つずつ「押す価値があるか」を判断させられます。判断が面倒になれば、下線はただの飾りとして読み飛ばされる。救いは、リンクの中が設定に関係なく常に注釈の対象外だというところ。ひとつの語がリンクでもあり注釈でもある、という重なりだけは起きません。
一文で終わらない説明は、吹き出しに向かない
吹き出しに出るのは、用語辞書の「短い説明」欄です。詳細説明のほうは用語集ページと構造化データページの内容を、検索エンジンなどの機械が読み取りやすい決まった形式で書いた情報。schema.orgの語彙を使い、JSON-LDで埋め込むのが一般的。詳しく見るが読む欄なので、そちらをいくら書き足しても吹き出しは太りません。
裏を返すと、短い説明を数文に伸ばせば吹き出しはそのぶん太る。狭い画面では、読んでいた本文にかぶさる面積が増えます。どのくらいかぶるかは、テーマの余白や文字サイズ、その用語が段落のどこにあるかで変わるので、ここは一律には言えません。言えるのは、画面が狭いほど「説明を読むために本文が隠れる」構図になりやすいということです。
一文で言い切れる語だけをツールチップにする。この線引きが、そのまま端末対策になります。どの欄に何を入れるかは用語辞書を1件ずつ育てるに整理してあるので、短い説明の書き方はそちらを。
操作そのものを消したいなら、注釈ボックスへ
注釈(注釈ボックス)は、用語を含む段落の末尾に補足の枠として出ます。開く操作は要りません。ホバーもタップもフォーカスも関係なく、最初から見えている。端末差がいちばん出にくい形式です。
代わりに、その説明は全員に等しく割り込みます。知っている読者にも見える。1つの記事に何個も置けば、段落と段落のあいだに枠が積み上がって、本文のリズムは確実に落ちます。
使い分けの基準は「読み飛ばされたら先が読めなくなるか」。その記事の前提になっている語なら、気づかれない可能性のあるツールチップに賭けず、注釈ボックスで最初から出しておく。読めなくても支障がない補足なら、吹き出しに畳んでおく。スマホ比率が高いメディアほど、この判断は注釈ボックス寄りに倒れます。
脚注は移動が入る。その着地はブラウザ任せにしていない

脚注は本文に連番の参照だけを置き、説明は記事末尾の一覧にまとめます。読者は参照を押して末尾へ移動し、読んでから本文へ戻る。移動が入るぶん、スマホではいちばん重い形式です。用語のたびにページを離れる設計が読者を連れ去る話は用語を別ページで解説してリンクする設計に書きましたが、同一ページ内の移動でも、往復のコストはゼロにはなりません。
そこで脚注の行き来は、ブラウザ既定の動きに任せていません。参照リンクと「本文に戻る」リンクは、対象が画面の中央あたりに来るようスクロールさせています。既定のジャンプだと対象は画面の上端に着地するので、固定ヘッダーを置いているテーマでは注がその裏へ潜り込む。テーマ側が # で始まるリンクに独自のスムーススクロールを仕込んでいることもあって、そちらに任せてもやはり上端寄せです。画面の狭い端末ほど、この着地のずれは痛い。テーマのハンドラより先に受け取って、中央寄せの側で主導権を握る形に変えました。動きを減らす設定を端末側でオンにしている読者には、アニメーションなしで移動します。
脚注が向くのは、出典・条文・参考文献のように「読まなくても本文が成立する」重い情報です。文体との相性から3形式を選ぶ考え方は脚注という選択肢が生きる文章のほうにまとめました。
端末は、形式を決めるもう一本の軸になる
表示形式は用語ごとに既定を持てます。サイト全体で一律にする必要はありません。端末を軸にすると、振り分けはだいたいこうなります。
- 一文で終わる略語・読み・言い換え → ツールチップ(タップ1回。気づかれないことは許容する)
- 読み飛ばされると先が読めなくなる前提 → 注釈ボックス(操作ゼロ。割り込みは許容する)
- 出典・条文など、確認したい人だけが見ればいい根拠 → 脚注(移動あり。戻る導線は用意されている)
説明の重さで選んでも、端末で選んでも、多くの用語は同じ形式に落ち着きます。判断が割れるのは「短いけれど読み飛ばされたくない語」。ツールチップに畳めるだけの短さがあるのに、気づかれないと困る語です。ここはスマホ側を優先して注釈ボックスに寄せるほうが、結果として読者を取りこぼしません。
スマホでツールチップが表示されない、と感じる場面の一部は、機能の不調ではなく、この振り分けを決めないまま全部を吹き出しに寄せたことの結果です。用語ごとに形式を持てる仕組みは用語注釈マネージャーの製品ページから確認できます。
