ページの右下でスクロールに追従してくる、あの矢印アイコンのボタン。多くのサイトで見かける定番UIですが、デジタル庁デザインシステム（DADS）のコンポーネント一覧には、これが「非推奨」として掲載されています。
長年当たり前のように使われてきたパーツが、なぜ公式デザインシステムでは推奨されないのか。そして、工夫すれば「使えるボタン」に戻せるのか。やさしく整理してみます。
まず、公式には何と書かれているか
DADSの該当ページには、次のように明記されています。
「このコンポーネントはアクセシビリティまたはユーザビリティの観点等から、現在は使用が推奨されません」
「やむを得ず使用する場合は、不利益があるユーザーの存在を踏まえたうえで注意深く使用してください」
注目したいのは、「禁止」ではなく「非推奨」という表現になっている点です。実際、Figmaのデザインデータ、React版のソースコード、Storybookのサンプルは、いずれも「提供中（非推奨）」というステータスで公開が続いています。つまりDADSは、このコンポーネントを歴史的な遺物として切り捨てたわけではなく、「標準採用はしないが、必要な場面での使用までは止めない」という、やや慎重な中間的な立場を取っていると読めます。
何が問題とされているのか
公式ページ自体は理由を簡潔にしか書いていませんが、一般的に指摘されている問題点を整理すると、次のような論点に集約されます。
アイコンだけでは伝わらない。 ボタンが矢印アイコンのみで構成され、適切なラベルが付いていないと、スクリーンリーダー利用者には何のボタンかまったく伝わりません（WCAG 1.1.1 非テキストコンテンツ）。
常に画面に居座ることの弊害。 画面下部に固定表示され続けるため、拡大表示時や画面の狭いスマートフォンでは背景のコンテンツに重なって隠してしまうことがあります。z-indexの管理が甘いと、チャットウィジェットやCookie通知など他のUIと衝突することも起こります。また、常時視界に入り続けること自体が、コンテンツを読んでいる最中の「情報のノイズ」になり、集中を妨げるという指摘もあります(COGA基準)。
クリックした瞬間の負担。 クリック後にスムーズスクロールでページ最上部までアニメーション移動する実装が一般的ですが、これは前庭機能に障害のあるユーザーにとって、めまいや吐き気を引き起こしうる動きです（WCAG 2.3.3 インタラクションによるアニメーション）。
キーボード操作との相性の悪さ。 フォーカスリングが背景色と同化して見えなくなったり、クリック後にフォーカスがどこにあるのか分からなくなったりする実装も少なくありません。
そもそも、もう用意されている。 Windowsの Home キー、Macの Command+↑、iOSのステータスバータップなど、OSやブラウザ側にすでに「ページ先頭へ戻る」機能が備わっています。独自実装のボタンは、この標準機能と役割が重複するうえ、ネイティブ機能ほどの信頼性や一貫性を持たせるのが難しい、という構造的な弱さを抱えています。
対策すれば「使えるボタン」に戻せるのか
ここが今回いちばん考えたかったところです。結論としては、部分的には可能だが、万能の解決策には戻れない、というのが実情に近いと思います。
技術的な対策自体ははっきりしています。aria-label="ページの先頭へ戻る" のような明示的なアクセシブルネームを付けること、prefers-reduced-motion を尊重してアニメーションを無効化またはユーザー設定に委ねること、他のUI要素と重ならない位置に配置すること、フッターに十分な余白を確保して固定要素の干渉を防ぐこと、クリック後にフォーカスをページ先頭の見出しなど意味のある要素へ明示的に移動させること。スマートフォンではOSのジェスチャーで十分代替できることが多いため、モバイルでは非表示にするという選択肢も有効です。ここまで丁寧に実装すれば、WCAG違反に近い問題の大半は技術的に解消できます。
それでもなお残る弱さが3つあります。1つ目は、固定要素である以上、将来的に他のUIが追加されるたびに重なりのリスクを継続的に管理し続けなければならないこと。2つ目は、「トップへ戻る」という機能そのものが、OSネイティブの手段とほぼ完全に重複していて、あえて自前実装する必然性が薄いこと。3つ目は、ユーザーが本当に求めているのは「画面最上部にジャンプすること」ではなく、多くの場合「もう一度目次やナビゲーションを見ること」であり、単純なトップへ戻るボタンでは、たどり着いた先でまた自分でナビゲーションまでスクロールし直す必要がある、という点です。
一方で見過ごせない反論もあります。肢体不自由なユーザーにとっては、スクロール操作そのものが身体的な負担になるため、「戻る」手段が用意されていること自体に価値がある、という指摘です。つまりDADSの非推奨化は、「この機能はもう不要」という話ではなく、「実装形態としての単純な固定ボタンが、多くのケースで問題を生みやすい」という話に近いのだと思います。
よくある誤解を整理する
「非推奨=絶対に使ってはいけない」？ ── いいえ。DADSも「やむを得ず使用する場合は」という条件付きで使用を認めており、禁止ではなく「安易な標準採用への警鐘」です。
「代替手段は存在しない」？ ── いいえ。長いページであれば、目次コンポーネントやセクションアンカー、パンくずリストの整備で「戻りたい」というニーズ自体を減らせます。これはボタンの実装を頑張るより根本的な解決になりえます。
「アクセシビリティ対応すれば無条件で復活できる」？ ── 半分正解、半分誤りです。個別の技術的問題は解消できても、OSネイティブ機能との機能重複や、固定要素特有の保守負荷は残り続けます。
まとめ──「標準装備」から「条件付きの選択肢」へ
トップへ戻るボタンが非推奨とされた背景には、アクセシビリティ上の具体的な欠陥だけでなく、「そもそもOSがすでに同じ機能を提供している」「ユーザーの本当のニーズは別のところにある」という、もう一段深い設計思想があるように見えます。
対策を積めば、限定的な条件下──長大な1ページ構成のドキュメントで、目次やパンくずでは代替しきれず、フォーカス移動・reduced-motion対応・非重なり配置をきちんと実装し、モバイルでは非表示にする、といった条件下──では、有用性を取り戻すことは十分可能です。ただし、それを「どのページにも置いておく定番パーツ」として扱うのは、もう時代に合わなくなりつつあるのかもしれません。むしろページ設計の側で目次やセクションアンカーを整備し、ユーザーが「戻る」必要性そのものを減らすことこそが、根本的な解決策なのだと思います。
本記事は、デジタル庁デザインシステムβ版（DADS）「スクロールトップボタン」コンポーネントページ（v2.17.1時点）、およびZenn記事「『ページのトップへ戻るボタン』はなぜ非推奨か」（masahiko888氏）の公開情報をもとに、一般向けに整理したものです。実装のアクセシビリティ対応については、各プロジェクトの状況に応じて専門家の確認をおすすめします。
