フォームコントロールに物理エンジンを付けるということ — Jelly UI が再び呼び起こした楽しさとアクセシビリティの古い振り子
フォームコントロールに物理エンジンを付けるということ — Jelly UI が再び呼び起こした楽しさとアクセシビリティの古い振り子
フォームコントロールに物理エンジンを付けることは、失われた UI の楽しさを取り戻す営みなのか、それともアクセシビリティ・パフォーマンス・使いやすさを代償に支払うもう一つの流行りのギミックなのか。
導入 — 301 点が二つに割れた場所
2026 年 7 月 21 日 (KST)、Hacker News のトップページに Jelly UI という名のプロジェクトが上がった。タイトルは 「Jelly UI: Soft-body physics for native HTML form controls」 だった。301 点を集め、125 件のコメントが付いた。紹介文は短い。Jelly UI は 「dependency-free Web Components library for soft, tactile product interfaces」 — 依存性なしの、柔らかく触覚的なインターフェースのための Web Components ライブラリである。40 個のカスタム要素、ゼロ依存、スクリプトタグ一つ。タグラインはその性格をそのまま表す。「It’s okay to be a little jelly」 。
核心となる発想はこうだ。チェックボックス、トグルスイッチ、スライダーといった実際のフォームコントロールにソフトボディ (soft-body) 物理シミュレーションをまとわせる。チェックボックスを押せばゼリーのように揺れ、トグルを倒せば慣性で揺れ動き、スライダーのつまみはポインターをバネのように遅れて追う。ここに dark mode、RTL (right-to-left) 対応、WCAG AA カラートークンが標準で組み込まれていると紹介は述べる。すなわちこのライブラリは単なる目の保養デモではなく、アクセシビリティのトークンを明示的に自らの名札に掲げたプロダクション志向のコンポーネントセットを標榜する。
注目すべきはプロジェクトそのものではなく、それが生んだ反応の形である。125 件のコメントはほぼ正確に二つに割れた。一方は 「失われた楽しさ」 を取り戻したと歓迎し、もう一方はアクセシビリティ・パフォーマンス・使いやすさを代償にしたギミックだと批判した。この分裂は偶然ではない。それはフロントエンドと UX が十年周期で繰り返してきた一つの緊張 — 楽しさ (delight) とスキューモーフィズム (skeuomorphism) 対アクセシビリティ・パフォーマンス・使いやすさ — の最新の発現である。本稿は Jelly UI という具体的な事物をレンズとして、その振り子がどこまで来て、どのようなトレードオフがその下に敷かれているのかを見る。
現象 — Jelly UI とは何であり、なぜ話題なのか
Jelly UI の技術的な実体は Web Components である。カスタム要素と Shadow DOM で 40 個のコンポーネントをカプセル化し、API リファレンスは 「すべての attribute、property、method、event、slot、shadow part、CSS custom property、そして keyboard map」 を文書化すると述べる。このリストが重要なのは、それがこのプロジェクトの野心を露わにするからだ。shadow part と CSS custom property を公開するとはスタイルのカスタマイズを支援するという意味であり、keyboard map と standard events を明示するとはキーボードアクセシビリティとネイティブイベント契約を守ろうとしているという意味である。紹介文が 「native forms、keyboard access、standard events」 を前面に出すのは、このライブラリがネイティブフォームコントロールを置き換えるのではなく包むことを志向するという合図だ。
しかし話題の中心はその上に載った物理である。ソフトボディシミュレーションはフレームごとに各要素の頂点 (vertex) 位置をバネ-質量モデルで再計算しなければならない。静的な CSS transition ではゼリーの揺れを出せないからだ。この点がスレッドの第一の戦線だった。ユーザー jlukic はパフォーマンス問題を正面から指摘した。「このライブラリは 8ms ごとに RAF (requestAnimationFrame) アニメーションループを回し、ページ上のアクティブなコンポーネントごとに毎フレーム再計算する」 。8ms という数字は毎秒約 120 フレームを狙うという意味であり、それはメインスレッドを常時占有するという意味である。
これに対する反論も即座に出た。ユーザー Rohansi は計測で応じた。ウィジェットを数個レンダリングすること自体は大きな資源を使わず、実際に CPU を食っているのはページ上部のアニメーション SVG ヘッダーだというのだ。彼の計測ではヘッダーがあるとき約 35ms、ないとき約 6.6ms だった。彼はウィジェットは状態変化やアニメーション中にのみリペイントされるべきで、常時リペイントされてはならないと付け加えた。すなわちパフォーマンス問題の相当部分はライブラリの構造的欠陥というより、デモページの演出過剰かもしれないという反論である。この応酬そのものが Jelly UI を興味深い事例にする。問題は物理そのものではなく、物理をどこにどれだけ常時オンにしておくかである。
擁護の声も明確だった。ユーザー memjay はこう書いた。「触って遊んでみたら驚くほど楽しい (surprisingly delightful)。我々は UI に少し楽しさを入れるべきだ」 。制作者 baldvinmar 本人の弁はより直接的だ。「時に我々は純粋に作る喜びのために作る。実用性はボーナスだ (Practicality is a bonus)」 。この二つの発言はこのプロジェクトの正当化の論理を圧縮する。すべてのインターフェースがコンバージョン指標で正当化される必要はなく、職人的な楽しさと遊びそのものに価値があるというものだ。この論理は真剣に扱われる資格がある。問題はその楽しさの代償を誰が、どこで支払うのかである。
深層 — 振り子、そして三つのトレードオフ
Jelly UI を理解するには、それが置かれた振り子運動をまず見なければならない。2013 年に iOS 7 がスキューモーフィズムを取り払いフラットデザインへ転換して以降、そして Microsoft の Metro と Google の Material Design がその流れを固めて以降、UI は長らく 「削ぎ落とす」 方向へ動いた。その振り子が逆に振れた最初の兆候が 2019 ~ 2020 年のニューモーフィズム (neumorphism、soft UI) だった。柔らかな二重の影で要素を背景からわずかに押し上げるこのスタイルは Dribbble を席巻したが、急速に冷めた。理由はアクセシビリティである。ニューモーフィズムの美学は要素と背景を同じ色に置くことから生まれるが、その結果テキストのコントラストが WCAG AA の最低基準である 4.5:1 を下回り、要素の境界の影は約 1.4:1 にとどまり WCAG 2.2 の非テキストコントラスト基準 (1.4.11、3:1) を通過できなかった。楽しさをアクセシビリティの代償で買ったのだ。そしてその請求書が届くと 2021 年に流行は沈静化した。
Jelly UI はこの振り子の最新の上昇局面 — 触覚性と物理性への回帰 — の上に立っている。そして興味深いことに、ニューモーフィズムの教訓を色の軸では学習した。WCAG AA カラートークンを標準で組み込むと明示したことがその証拠だ。しかし同じ緊張を別の軸 — モーション — で再び開く。三つのトレードオフがその下にある。
第一に、アクセシビリティとモーション感受性。 物理アニメーションは前庭系 (vestibular) 障害を持つユーザーにとって実質的な危害となりうる。WCAG 2.3.3 (Animation from Interactions、AAA) は、相互作用によって引き起こされるモーションアニメーションを、それが機能に必須でない限り無効化できるべきだと要求する。前庭系障害の反応には、注意散漫、めまい、頭痛、吐き気が含まれる。この要求を実装する標準的な道具が CSS メディアクエリ prefers-reduced-motion であり、それは macOS のシステム設定 > アクセシビリティ > 視差効果を減らす、といった OS 設定に連動する。スレッドでこの問題はすぐに露わになった。ユーザー bigbuppo は断固としてこう書いた。「あのデモは私を吐き気に (makes me nauseous) させる。ボタンがあんなことをすべきではない」 。ユーザー altairprime はトグルスイッチに 「本能的な不気味の谷の反応 (visceral uncanny valley reaction)」 を感じたと報告した。
ここに微妙だが決定的な落とし穴がある。他のユーザーたち (momojo、TurkTurkleton) は、OS の 「視差効果を減らす」 をオンにした状態でデモを開くとアニメーションが消え、このデモがそもそも何をするものなのか分からなくなると指摘した。すなわち Jelly UI の物理は単なる装飾ではなく、アフォーダンス (affordance) そのものでもある。揺れが 「押された」 というフィードバックを兼ねる瞬間、prefers-reduced-motion を尊重してモーションを切ることは、そのまま状態信号を切ることになる。アクセシビリティを正しく支援するとは 「モーションを切る」 で終わらず、「モーションがなくても同じ情報を伝える代替表現」 を併せて設計するということを意味する。制作者はこのフィードバックを受けて再生オーバーライドのオプションを追加したと述べた。これは正しい方向だが、そもそも楽しさがアフォーダンスと結合したとき、アクセシビリティの代償がいかに微妙になるかを示している。
第二に、パフォーマンスと入力遅延。 フォームコントロールの本質的な任務は、入力状態を遅延なく忠実に反映することである。ところがソフトボディ物理はその忠実性を意図的に損なう。スライダーのつまみがポインターをバネのように遅れて追うのがその例だ。ユーザー socalgal2 は問うた。「スライダーがポインターより遅れるのが、いったいなぜ良い設計なのか」 。ユーザー JoshTriplett はスライダーをドラッグするときコントロールがカーソル位置よりかなり遅れて反応時間が悪くなると報告した。これは好みの問題ではなく情報の忠実度の問題である。値を精密に合わせなければならないコントロールで、つまみの物理的遅延はそのまま操作誤差になる。ここに常時 RAF ループのコストが重なる。メインスレッドが毎フレーム物理を計算すれば、スクロールや他の入力の応答性が落ちる。ユーザー weego は Chrome/MacBook Pro で効果が微妙であるにもかかわらずページスクロールが悪化しアニメーションの FPS が低下したと報告した。安価なアニメーション (compositor で処理される transform/opacity) と高価なアニメーション (レイアウトを誘発するもの) の区別がここで実務的に分かれる。ゼリーの揺れは安価な側にとどまりにくい。
第三に、ネイティブ対カスタムコントロール。 ARIA の第一の規則は 「ネイティブ要素でできるならカスタムで作るな」 である。理由は歴史的に明白だ。div でチェックボックスを作り直すと、キーボードナビゲーション、フォーカス管理、スクリーンリーダーのセマンティクス、フォーム送信への参加といったネイティブの 「見えない正しさ」 をすべて再実装しなければならず、たいていその過程で何かを取りこぼす。Jelly UI の真剣な答えは form-associated custom elements と ElementInternals を活用し、カスタム要素が実際の form に参加しキーボードアクセスを維持するようにすることだ。これが 「native-preserving」 を標榜する根拠である。しかし標榜と実際は分かれた。ユーザー chrismorgan は詳細なレビューで、コンポーネントが依然として JavaScript を要求し (真のネイティブではなく) アクティベーションの挙動が不正確だと指摘し、checkbox、OTP、range、switch、textarea、alert、pagination、tabs、dialog、menu 全般にわたる問題を列挙した。とりわけ OTP 入力に対しては強く反対した。「いかなる場合も OTP に単一文字入力の連続を使うな。その挙動は実に厄介だ」 。彼は monospace でスタイリングした一つの統合入力を勧めた。ユーザー itishappy はこれらのコンポーネントが、標準 UI 要素を膨大な反復の末に再実装していた Flash 時代の開発者の苦闘を思い起こさせると書いた。ネイティブを近く再び包むほど、ネイティブがタダで与えていた正しさをより多く再び稼がねばならないという緊張がここにある。
展望・実務的示唆 — 楽しさはいつ元を取るのか
この三つのトレードオフを総合すると、判断の軸は 「物理かアクセシビリティか」 という二分法ではなく、頻度 (frequency) と重大性 (criticality) である。マーケティングのランディングページやゲームのメニューのように相互作用が稀で失敗の代償が低い場所では、ゼリーの揺れは純粋な利得だ。反対に銀行アプリの OTP 入力や毎日使う業務フォームのように相互作用が頻繁で精密さが要求される場所では、同じ物理は負債になる。Jelly UI が自らの名札にアクセシビリティのトークンを掲げたのは後者の市場を狙うという合図だが、スレッドの批判の大半は正確にその後者の文脈から出た。
実務の解法は振り子を一方の端に固定することではなく、プログレッシブエンハンスメント (progressive enhancement) として配置することだ。物理はコントロールの上にオプトインで載る層であるべきで、その層がなくてもコントロールは正しく速く動作しなければならない。prefers-reduced-motion を例外ではなく基準線に置く設計 — すなわちモーションのない状態が完全なデフォルトであり、物理はその上の選択的な贅沢である設計 — がそれである。モーション予算 (motion budget) という概念がここで有用だ。ページが許容できる常時アニメーションの総量を予算のように管理し、物理を相互作用の瞬間にだけ短く支出する。8ms の常時ループではなく、状態変化時の短いバネの減衰で。
制作者の対応はこの点で健全なパターンを示している。スレッドでスクロールジャッキング (scroll-jacking) への批判 — ユーザー wpm は 「スクロールジャッキングはトラックパッドに対して、ドライバーの柄をバンジーコードでねじって回すことがドライバーを使うことに対する関係と同じだ。直接的で即座のフィードバックを断ち切る」 と書いた — が出ると、制作者は 「指摘はもっともだ。スクロールジャッキングは削除した (scroll-jacking has been removed)」 と答えた。出荷し、敵対的なレビューを受け、利得よりコストの大きい部分で退却すること。これが振り子の上昇局面で個々のプロジェクトが取りうる最善の姿勢である。
もう一つ挙げておくべきは新奇性の減衰である。ユーザー ch_sm はこのプロジェクトを 「React のための Compiz」 と呼んだ。2000 年代半ばの Linux デスクトップを揺れる窓 (wobbly windows) で魅了したあの Compiz である。その比喩は正確でまた予言的だ。Compiz の揺れる窓は最初こそ誰もを楽しませたが、結局ほとんど誰もがそれをオフにした。ユーザー xutopia がモーション過剰の UI について、ゲームですら新奇性が消えた後は障りになると述べたのと同じ軌跡だ。楽しさがアフォーダンスと分離可能な純粋な装飾であるとき、その寿命は新奇性の寿命と等しい。毎日使う道具において新奇性は数日を越えない。
結論 — 優雅に消えることができるか
リードの問いに戻ろう。フォームコントロールに物理エンジンを付けることは、楽しさを取り戻す営みなのか、ギミックなのか。答えは二分法が偽だということである。しかしその下のトレードオフは実在し、何より非対称的だ。楽しさは実在し正当である。純粋に作る喜びのために作るという制作者の弁は真剣に擁護されうるし、すべてのインターフェースがコンバージョンに還元される必要はない。しかしその楽しさの代償は最も脆弱なユーザーと最も弱い機器の上に落ちる。前庭系障害を持つユーザー、低スペック機器のユーザー、スライダーで精密な値を合わせなければならないユーザーがその請求書を受け取る。この非対称性が 301 点を二つに割った本当の理由だ。
したがって正しいフレーミングは 「物理対アクセシビリティ」 ではなく 「エンハンスメントとしての物理、基準線としての正しさ」 である。Jelly UI の価値はライブラリそのものよりも、それが掲げた鏡にある。301 点の分裂は、産業が十年ごとに振る同じ振り子 — スキューモーフィズムからフラットへ、フラットからニューモーフィズムへ、そして再び物理性へ — を再審する場である。ニューモーフィズムが色のコントラストで学んだ教訓を Jelly UI は色で学習したが、同じ教訓をモーションで再び試されている。本当の問いは楽しさを入れるか否かではない。その楽しさが消えたとき、何の問題もなく優雅に消えられるか — それが楽しさとアクセシビリティを和解させる唯一の条件である。
出典: