出来事の日付：2026年6月10日。
あるウェブ開発者によると、HTML優先で再設計した結果、オンラインで公共サービスを申し込む顧客のうち、公開直後に申請を完了した人数が倍増した。この報告で扱われているのは規制対象の独占事業者で、利用者は古いASPフォームか、より費用のかかる手作業の手続きを通じて申し込むことができた。それ以前には、置き換えを目指した2度の試みが失敗していた。
直近で採用を見送られたバージョンはReactアプリケーションで、公開から3日後、顧客からの苦情を受けて撤回された。開発者によると、このアプリはローディング状態とグローバルなJavaScript状態に大きく依存し、アクセシビリティー要件を満たしておらず、アップロードされた画像やその他のフォーム情報を、上限が5MBのブラウザーのローカルストレージに保存しようとしていた。
代替版はAstroを使用したが、JavaScriptは任意の機能強化として扱った。フォームの各段階は別々のページになっていた。有効なデータをサーバーへ送信するとブラウザーは次の段階へリダイレクトされ、無効なデータには複数層の検証が引き続き適用された。この従来型のリクエスト・レスポンス構造は、新しい住宅地で接続状態の悪い回線を通じ、古いAndroid端末を使っている可能性がある人々のために選ばれた。
小さなウェブコンポーネントが、ブラウザー標準のHTML検証を強化した。標準のポップアップメッセージを抑制し、アクセシビリティー上関連付けられた要素にエラーを表示するとともに、利用者が入力したとき、フィールドから移動したとき、またはフォームを送信したときに、エラーを消去または再評価した。開発者によると、コンポーネントは1KB未満だった。それが機能しなくても標準の検証が残り、それも機能しない場合にはバックエンドAPIがなお送信内容を検証した。
このアプリケーションはセッションデータをサーバーに保持したため、進捗状況は特定のタブや壊れやすいクライアント側ストアに依存しなかった。ある人は開始から1カ月後に戻り、申請を完了したと報告されている。この永続性は、より広い目標の一部だった。すなわち、スクリプトが失敗したとき、ネットワーク接続が切れたとき、またはブラウザーの機能が限られているときにも、利用可能な経路を維持するという目標である。
公開後、完了した申請は倍増した。事例研究によると、組織の分析チームは当初、追加された利用者について説明できなかった。JavaScriptベースのアクセス解析では、スクリプトの障害後に従来の利用体験を断念した人々が記録されていなかったためだ。この報告には、生のトラフィック数、対照を設けた比較、どの設計変更が増加をもたらしたのかという内訳は示されていない。
したがって、この結果は一つのプロジェクト報告として読むべきであり、HTML優先の構築が常に利用を倍増させる証拠ではない。この公共サービスのフォームは常時リアルタイムデータを必要としなかったため、サーバー主導のページがとりわけ適していた。より広い教訓は、プログレッシブエンハンスメントによって障害が決定的なものになりにくくなるということだ。軽量な機能強化で利用体験を改善しつつ、基盤となるフォーム、ブラウザーのコントロール、サーバー側の検証をすべての利用者が引き続き利用できる。
