開閉するUIをブラウザ標準で作る、open擬似クラスが揃える最後のピース

つくば市のホームページ制作会社

ウェブサイトで何かを開いたり閉じたりする操作は、どんなサイトにもあります。ハンバーガーメニューの開閉、問い合わせ前に表示するモーダル、よくある質問のアコーディオン、小さなツールチップ。こうした開閉パーツは長らくJavaScriptのライブラリで組むのが当たり前でした。ところが2026年に入り、ブラウザ標準の機能だけで同じことができる場面がぐっと増えています。

節目になったのが、2026年5月に公開されたSafari 26.5です。ここでopen擬似クラス(:open)が実装され、ChromeやFirefoxと足並みがそろいました。地味な追加に見えますが、標準機能だけで開閉UIを組む流れを後押しする一歩です。詳しくはWebKitの公式ブログでも解説されています。

open擬似クラスが開いた状態をまとめて扱う

:openは、要素が開いている状態にスタイルを当てるための擬似クラスです。対象はdetails要素やdialog要素、それにselect要素や、日付や色を選ぶinput要素のピッカーが開いたときまで含みます。開閉する部品を、種類を問わず同じ書き方で整えられるのが利点です。矢印の向きを変える、背景色を切り替えるといった見た目の調整を、状態ごとにCSSの中で完結させられます。

これまでは[open]属性セレクタで開閉状態を拾っていました。ただしこの書き方が効くのはdetails要素とdialog要素だけで、select要素やinput要素には使えませんでした。細かな差に見えますが、開閉するあらゆる要素を一貫した書き方で扱えるようになった意味は小さくありません。要素の種類ごとに別々のセレクタを覚える負担が減り、スタイルの見通しも良くなります。詳しい対応状況はMDNで確認できます。

標準タグだけで組める開閉パーツ

開閉UIの部品は、ここ数年でブラウザ側にそろってきました。モーダルはdialog要素のshowModalで開けます。背景を暗くする処理やフォーカスの閉じ込め、Escキーで閉じる動きまで、ブラウザがはじめから面倒をみてくれます。ちょっとしたメニューや吹き出しは、HTMLにpopover属性を足すだけで開閉できます。Popover APIは2025年4月に主要ブラウザで安定して使えるようになり、いまでは前提として組み込める土台になりました。popover属性を付けた要素は、外側をクリックしたりEscキーを押したりすると自動的に閉じます。いわゆるライトディスミスの挙動を、自分で書かなくてもブラウザが用意してくれます。

よくある質問のアコーディオンは、details要素とsummary要素だけで作れます。開いたときの見た目は:openで整えれば、開閉の状態管理をJavaScriptで書く必要はありません。ポップオーバーが表示中かどうかは:popover-openでも拾えます。Safari 26.5では、どの要素がポップオーバーを開いたかを知るための仕組みも加わり、複数の開閉部品が絡む画面でも扱いやすくなりました。ボタンを押すと候補が開くドロップダウンのような部品も、こうした標準機能の組み合わせで素直に表現できます。素朴なHTMLの積み重ねで、これまで外部ライブラリに任せていた動きの多くがまかなえます。

制作現場にとっての意味

標準機能に寄せる利点は、まずコードが軽くなることです。開閉のためだけに読み込んでいた外部ライブラリを減らせば、ページの表示は速くなり、保守の手間も下がります。加えて見落としがちなのがアクセシビリティです。dialog要素やpopover属性は、キーボード操作やスクリーンリーダーへの対応がはじめから組み込まれています。自前で作った開閉UIにありがちな、フォーカスが迷子になる、Escキーで閉じないといった不具合を避けやすくなります。ブラウザ標準の挙動に乗るぶん、環境による見え方や操作感のばらつきも抑えやすくなります。

中小企業のサイトでも、問い合わせ導線のモーダルやFAQのアコーディオンなど、使いどころは多いはずです。たとえば、以前はプラグイン頼みで組んでいたFAQの開閉を、details要素と:openだけに置き換えれば、依存が減って動作も安定します。ただし現状では、古いブラウザ向けのフォールバックや、凝ったアニメーションでのCSSとの併用など、細かい調整が要る場面は残ります。それでも、開閉UIの土台をブラウザ任せにできる範囲は着実に広がっています。新しく組むときは、まず標準機能だけで足りるかを出発点に考える価値が出てきました。手が込んだ実装に進むのは、それで届かないところを見極めてからでも遅くありません。

背景に応じて文字色を自動で選ぶCSS関数、読みやすさを支える新しい仕組み

つくば市のホームページ制作会社

ボタンや見出しの背景色を決めたあと、その上に載せる文字を黒にするか白にするかで迷った経験は、制作に関わる人なら一度はあるはずです。背景が濃ければ白、淡ければ黒と感覚で選んでいくものの、配色のパターンが増えるほど組み合わせの管理は地味に重くなります。この「背景に対して読みやすい文字色を選ぶ」という判断を、CSSだけで自動化するcontrast-color()という関数が、主要ブラウザにようやく出そろいました。

背景色から文字色を自動で決める関数

contrast-color()は、引数に渡した色に対して黒と白のどちらがより高いコントラストになるかを判定し、読みやすいほうを返す関数です。色を指定できる場所であればどこでも使えるので、文字色の指定に組み込めば背景色に応じて自動的に切り替わります。

書き方はとてもシンプルで、背景にブランド色を変数で渡しているなら、文字色は次のように一行で済みます。

background-color: var(–brand); color: contrast-color(var(–brand));

判定にはWCAGのコントラスト比の考え方が使われており、読みやすさの最低限を機械的に満たしやすくなります。Chrome 147、Firefox 146、Safari 26と三つのブラウザエンジンが2026年に対応し、安全に使える機能をまとめたBaselineでも新たに利用可能の段階に入りました。ブラウザ間の挙動をそろえるInterop 2026の対象にも含まれており、どの環境でも同じ結果になることが期待できます。

これまでの配色対応との違い

ブラウザが標準で対応する前から、読みやすい文字色を得る方法はいくつかありました。JavaScriptのライブラリで表示時にコントラスト比を計算して色を当てる、Sassの関数であらかじめ対になる色を生成しておく、あるいは単純に人の目で一つずつ黒と白を決めておく、といった具合です。

どれも動きはしますが、手間と保守の負担は残ります。表示時に計算する方法は画面が出るまでにわずかな処理を挟みますし、ビルド時に色を固定する方法は背景色を変えるたびに対の色も作り直すことになります。手作業の指定は、ライトモードとダークモードで色の組を二重に持つことになりがちです。contrast-color()はこの判断をブラウザ側に任せるため、背景色を一か所変えれば文字色もそのまま追従します。

制作現場で効く場面

恩恵が分かりやすいのは、背景色が一定しない場面です。ブランド色をボタンに使うコンポーネントなら、色だけ差し替えれば文字の見やすさは自動で保たれます。ホバーで背景を明るくする演出を入れた場合も、必要に応じて文字色が白から黒へ切り替わります。

ライトとダークの切り替えとも相性がよく、prefers-color-schemeで背景の変数だけを入れ替えれば、文字色の組を別々に書く必要がなくなります。color-mix()などで動的に作り出した色にも追従するため、配色をプログラム的に生成する設計とも噛み合います。デザインシステムのように色をトークンとして一元管理する作り方とも相性がよく、土台の色を一つ変えるだけで関連する文字色がまとめて整うため、配色の調整にかかる手数を減らせます。

地方の中小企業サイトやCMSでは、色の設定を制作者以外が触る場面も少なくありません。管理画面でテーマ色を選ぶと文字色まで適切に決まる、という作りにしておけば、運用する人がコントラスト比を意識しなくても読みにくい配色になりにくくなります。納品後の更新で配色が崩れるリスクを下げられる点は、長く運用するサイトほど効いてきます。

使う前に知っておきたい制約

便利な一方で、現時点の仕様には割り切りもあります。返すのは黒か白のどちらかだけで、中間調の背景に対しては必ずしも最適な結果にならないことがあります。判定の方式を選べる拡張的な書き方も一部ブラウザで試験的に使えるものの、Baselineの範囲ではまだ標準化されていません。

そのため、重要なボタンや本文など可読性が要になる箇所は、自動任せにせず実際の表示で確かめる姿勢は残しておきたいところです。とはいえ、配色の土台を機械的に整える層として置いておく価値は十分にあります。これまで手で管理してきたコントラストの一部を、ようやくCSSそのものに預けられるようになったという意味で、地味ながら実務に効く一歩だと言えます。

ウェブ制作現場の新しい選択肢、WordPressセキュリティからCSS機能まで制作者が知るべき動向

つくば市のホームページ制作会社

ウェブ制作の現場では、セキュリティ対策からレイアウト技術まで、複数の分野で新しい選択肢が生まれています。2026年5月のWordPressセキュリティ動向では、Burst Statistics認証回避バグや100万インストールのAvada Builder SQLインジェクション、MonsterInsightsのOAuthトークン盗取が問題となる一方、ウェブアクセシビリティ分野では分析対象100万サイトの94.8%でWCAG違反が検出され、低コントラストテキストが79.1%のページで見つかっています。CSS技術では、Subgridが2026年には全主要ブラウザで実用段階に達し、コンテナクエリと組み合わせることで従来の制約を乗り越える新しいレイアウト手法が広がりつつあります。

WordPressセキュリティ:3つの深刻な脆弱性と対策の現状

2026年5月に発見された重要な脆弱性のうち、最も深刻なのがBurst Statistics プラグインの認証回避問題(CVE-2026-8181、CVSSスコア9.8)で、20万サイト以上が影響を受けました。この脆弱性は4月23日にコードが出荷されてから5月12日にパッチが公開されるまで19日間の短期間で、WordfenceのPRISMプラットフォームが15日目に発見したという点が注目されます。

Avada Builderでは100万インストールを超える人気プラグインで任意ファイル読み取りとSQLインジェクションの脆弱性が見つかり、パスワードハッシュなどの機密データ流出のリスクが生じました。特にSQLインジェクションの悪用にはWooCommerceが一度インストールされてから無効化された環境が条件となり、WooCommerceを一度も使ったことがないサイトはこの攻撃の対象外となっています。

月間90件を超える脆弱性開示に対して手動での追跡管理は現実的ではなく、MonsterInsightsの脆弱性によってGoogle広告トークンが漏洩し予算が消耗する事例のように、忘れられたサイトで問題が発生するケースが指摘されています。

ウェブアクセシビリティ:法的要件の厳格化と現実的課題

WebAIM Million 2025レポートによると、上位100万サイトの95.9%が基本的なWCAG 2.2標準を満たしておらず、実質的にアクセシブルと言えるのは100サイト中わずか4サイトという状況です。ただし1ページあたりの平均エラー数は56.8から51に減少しており、進歩は緩やかながら進んでいることがわかります。

法的要件では、DOJ規則によってWCAG 2.1レベルAAが技術標準として設定され、5万人以上を対象とする政府機関は2026年4月24日、小規模政府機関は2027年4月26日がコンプライアンス期限となっています。欧州アクセシビリティ法は2025年6月にEU全加盟国で義務化され、もはや政府ウェブサイトに限定されず、銀行アプリやeコマースプラットフォーム、電子書籍、社内ツールまで対象となりました。

最も多い問題は低コントラストテキスト(79.1%のページで平均29.6箇所)で、代替テキスト不備は55.5%のページに影響し、そのうち44%がリンク画像に関わる問題で、スクリーンリーダーユーザーのナビゲーションを完全に阻害しています。

CSS新機能:コンテナクエリとSubgridの実用化

コンテナクエリはGrid以来最も重要なCSS レイアウト機能の追加で、コンポーネントがビューポートではなく親コンテナのサイズに応じて動作することで、どんな文脈にも適応する真に再利用可能なコンポーネントを可能にします。同一のカードコンポーネントが配置場所(サイドバー、メインコンテンツ、フルワイドヒーロー)に応じて縦型・横型レイアウトを自動切り替えでき、JavaScriptやコンテキスト専用CSSクラスが不要になります。

Subgridは2019年Firefox、2022年Safari、2023年9月Chrome 117で実装が完了し、2026年には機能検出なしで主流ユーザーに対して直接利用できる安定した技術となりました。従来のline-clamp: 1による1行制限やmin-height: 4remでの固定高さ指定といったハック的手法を削除でき、Subgridがコンテンツクリッピングや任意のピクセル値への固定なしに整列問題を解決します。

色彩処理では、2026年にはバリエーション毎の16進コードリストを維持する必要がなくなり、CSS Color Level 5の相対色構文を使って、fromキーワードでベースブランド色から任意のバリエーション(明度・彩度・透明度)をCSS内で直接生成できるようになっています。

制作環境の変化:AI影響下での品質管理

WebAIM 2026年版調査では上位100万ホームページの95.9%でWCAG違反が検出され、前年94.8%から悪化し、1ページあたりの平均エラー数も56.1件と12ヶ月で10.1%増加しています。この後退の構造的要因として、ページ複雑性の前年比22.5%増加とARIA使用量の27%増加(多くが不適切な実装)が挙げられています。

2026年にはAIがウェブサイト作成の主要エンジンとなり、レイアウト生成、コンポーネント組み立て、コンテンツ制作、デプロイ加速を人間チームでは追従できないペースで実行しています。ユーザーがブラウザで実際に体験するものはソースコード意図と大きく異なることが多く、現代のウェブサイトはCMSプラットフォーム、AI生成コンテンツ、サードパーティツール、パーソナライゼーションレイヤーなど多数のソースから組み立てられています。

2026年の実質的な変化はAIのワークフロー効率への貢献であり、スマートツールと知識豊富な人間レビューアーの組み合わせがスピードと一貫性を向上させる一方、AIに全てを任せる組織は従来より高速に重要なバリアを見落とし続けることになります。